Dust out few tasks to gain transactional replication performance in SQL 2005
Coming to the basics of Transactional Replication, that starts with a simple snapshot of publication database data. Similar to the name the process is carried upon the fashion of transactions and subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time). So the consistency within the transactions is guaranteed and you cannot take any risks by changing the database recovery model.
So coming to the performance bit, the first and foremost option is to keep your transactions simple & small to gain upper level performance. Bascially for the first initialization its better to go with the backup than using the agent jobs, the advantage of SQL Server 2005 allows any backup taken after the creation of a transactional publication to be restored at the Subscriber instead of using a snapshot to initialize the subscription. This way you can reduce the overload of large data volume to yield benefits, that means majority of your issue is addressed.
Another feasibility within SQL 2005 is using peer-to-peer replication, I would like to refer the article written by my peer Dinesh Asanka. On the high level the comparison with the standard transactional replication that assumes read-only Subscribers and is hierarchical in structure, in the peer-to-peer transactional replication all nodes are peers and changes can be made at all nodes. Also I have been suggested to refer to -ReadBatchSize @ log reader agent & -CommitBatchSize @ distribution agent parameters, so I refer to look at BOL for similar information.
While I was having discussion with fellow MVPs it has been suggested to use Replication Management Objects (RMO) to configure & manage this replication process. As it sounds most of it is extracted from SQL-DMO that has limited in supporting replication. I would suggest to review the content under updated BOL for SQL Server 2005. As referred before short & simple are far better than rushing all at one time, the default configuration of SQL Server sends changes from the Publisher to Subscriber as INSERT, UPDATE, and DELETE
statements you should keep transactions as short as possible to help the Distribution Agent to
transfer transactions through the network. Not only with performance using such fashion you are avoiding locking & blocking issues too. So in case of performing huge inserts or modifications to data then consider to use stored procedures, that will contain all these statements, and replicate to subscriber only the execution of this stored procedure.
Say if your shop is heavily accessed on day to day basis try to seperate the replicated servers from the main server such as dedicated environment to avoid shared resources, at our end we have such major gain that reduces Publisher loading, but it increases overall network traffic which not a big problem having dedicated lines.
Further I would like to refer the 2 articles on Technet on the subject, that talks much deeper on what I have referred above:
http://technet.microsoft.com/en-us/library/ms151762.aspx
http://technet.microsoft.com/en-us/library/ms345124.aspx
http://blogs.technet.com/lzhang/archive/2006/05/12/428178.aspx