This is always an interesting topic and its something I looked at a few years ago. Always thinking about performance I decided to revisit this topic. While most of the latest browsers allow for six simultaneous connections, previous versions only support two and this can be limiting when dealing with millions of tiles. Back then I was investigating how I could work around the browser limiting simultaneous connections that it makes to a single HTTP server. My post explaining this concept and how I got this working can be found here: http://se7en.co.nz/cms/…
Since many Web browsers do not allow more than two requests to a given domain at the same time, some users map multiple subdomains to the same server. This often improves performance for client applications that make many requests to the same server. Currently, ArcGIS Server and the ArcGIS Silverlight/WPF API do not support multiple subdomains for the same service. However, you can enhance the ArcGIS Silverlight/WPF API to take advantage of a tiled map service hosted on multiple subdomains.
While the REST endpoint doesn’t support multiple subdomains, some of the individual API’s do. In this case the ArcGIS API for Microsoft Silverlight/WPF. This is actually quite an easy thing to implement and Morten has written up a good post that shows you how to do this: http://blogs.esri.com/Dev/…
What effect does this have on your application? Lets look at a simple application that I created using the ArcGIS API for Microsoft Silverlight/WPF.
Since this application is hosted on s3.demos.eaglegis.co.nz my browser will makes connections to this URL to pull the tiles from the server. If you are using Internet Explorer 8 or Firefox 3 your browser can make six simultaneous connections to s3.demos.eaglegis.co.nz. If you are using any of the older browsers you can make two simultaneous connections. As you can imagine this can be limiting and slow.
Implementing support for multiple subdomains using the ArcGIS API for MIcrosoft Silverlight/WPF we can see quite a difference.
What we see now is that when your browser pulls tiles from the server it will use either:
cache1.s3.demos.eaglegis.co.nz
cache2.s3.demos.eaglegis.co.nz
cache3.s3.demos.eaglegis.co.nz
This will allow for greater throughput and work around the connection limits.
It would be nice for this to be on the REST API itself as a setting but works really well and its worth having a look at for your application since we cannot assume visitors to your website are using the latest browser versions.