The computers running the primary and mirror servers should be configured with similar hardware (processor, disk, memory, and so on). At any given time, the database server running on either computer can be acting as the primary server for the database being mirrored. The mirror server utilization is typically low, depending on update activity on the primary and the load generated by any read-only connections to the mirror server.

The performance of transactions that update the database depends on the size of the transaction and the frequency of commits. Increasing either the size of the transactions or the frequency of the commits causes the primary server to interact more with the mirror server, creating more opportunities for the primary server to be delayed and for the user to notice the delays.

The performance of queries against the primary server is usually not affected by mirroring. If your application does more reads than updates and auditing is not enabled, you are unlikely to experience a change in the performance of the primary server. But, if database auditing is enabled, you may experience a change in performance because auditing writes additional information to the transaction log.

The performance of your client applications can be affected by the network connection between the servers in the mirroring system, especially when the servers are located in different geographic locations. A slow network connection between the servers can degrade the performance of your client applications.

A mirroring system running in either asynchronous or asyncfullpage mode requires the primary server to wait in fewer cases than when running in synchronous mode. But, even in asynchronous or asyncfullpage mode, some of the messages sent from the primary server to the mirror server wait for an acknowledgement from the mirror, potentially introducing delays. In addition, there is a small amount of overhead in sending packets to the mirror. Asynchronous and asyncfullpage modes are not recommended because transactions can be lost.

Incomplete transactions must be rolled back when the mirror server takes ownership of the database, and the longer a transaction is, the longer it takes to roll the transaction back. The recovery speed for failover is affected by the number of clients and the length of their transactions that must be rolled back. If recovery speed is a concern, you can design your application to use short transactions whenever possible.