Performance
Network Considerations
There are none. What I mean by that is you must place FE servers in the same domain as their BE counterparts. As we saw in the protocol traces, the FE must also be able to find your internal DNS Server, Active Directory Domain Controller, and a Global Catalog for your domain. The FE server uses these tools, and RPC in many cases, to find and talk to the BE servers.
Also, a FE server does not care where you came from. Its sole intention is to proxy your requests. It will not make a determination of your LAN, access speeds or anything else. The FE server will look in AD to find the source you are requesting and proxy the request to that server on your behalf. Essentially, there are no load-balancing characteristics nor can the server provide your mail if your mail server is unavailable.
Here is my one-sentence summary:
If you are creating WebDAV applications and need to prompt users for authentication information and have no specific performance SLAs (for example, folks entering from the Internet), and expect tens of thousands of people to use this application then FE/BE is what you want!”
Internet Access Example:
This model is exceptional for a company who wishes to use OWA as the default mail access, especially if this access will be available from the Internet. In this configuration, there are no Exchange stores directly exposed to the Internet. Moreover, the first firewall needs only to open port 80 to allow users to connect to the FE server. You will however, need to open quite a few ports between the FE and BE servers to allow for DNS, LDAP, and quite possibly RPC traffic. This should be pretty easy with a direct IP map that allows the FE greater access to your network.
Server Performance
So, what exactly does an FE server offload from the BE servers:
- Authentication As I mentioned earlier, FE servers only support basic authentication. If you are using SSL, the FE will handle this as well. SSL adds a tremendous amount of overhead on transactions. In most cases, it doubles or more than doubles the processor usage on the server and the amount of data that is sent over the wire.
- Controls Your custom applications will use a set of tools or controls for the client. The FE server acts as an IIS server and provides the controls you specify to the HTTP client.
How much load is actually taken from the BE server? Here is a short performance snapshot
The peak on the left was generated when a client entered http://server2/exchange directly to access mail. The peak on the right was generated when the client entered http://server1/exchange and accessed data on Server2 through the FE server. As you can see the load on the server is slightly lower when accessed this way. Based on this data, routing clients through an FE does not dramatically reduce the load on the BE servers. The bottleneck will continue to be on the BE servers (in most cases.) The overall recommendation is one FE to four BEs. This should provide good balance.
As a general rule, add BE servers as you would normally to overcome capacity issues on the mail-servers. Add FE servers to provide redundancy to the browser clients (think of it as an IIS server farm.)
I recommend that you perform more thorough tests when identifying potential volume on your servers.
For a more detailed analysis of server capacity under heavy loads visit: http://www.microsoft.com/exchange/techinfo/be_scalability.htm and
http://www.microsoft.com/exchange/techinfo/E2K_FEScalability.htm
|
