Wow. I can't begin to imagine what this kind of capacity would cost to roll out using today's web technologies (most people might [be] surprised at how few concurrent requests it takes to slashdot a site).The more I look at scalability and performance, the more convinced I become that it has to be viewed as a "system" problem - in other words there are many factors that need to be considered and balanced to achieve optimum results.
[Bill de hÓra - scale this]
This was reinforced a couple of weeks ago when I was assisting with some performance and scalability benchmark testing, in a test lab which had the fastest TCP networking infrastructure I have ever seen! It was surprised how much difference just that one single aspect made to the throughput figures we saw. Without any tuning of the server setup, we got throughput equivalent to 2.5 BILLION transactions per day for a simple Web Service running in CapeConnect Server v4.0! Wow!! This took everyone so much by surprise that we ended up repeating all the tests from scratch just to check our numbers. And all this without the CPU meters going over 5% utilization, so it looks like we could have got this even higher with some system and server tuning which we did not have time for.
Based on the previous numbers I've seen, it was clear that the super-network in use was having a significant effect on the numbers here, as there was no change to either the application / infrastructure architecture or server config.
Clearly balancing all parts of the system configuration is important for achieving optimal throughput for all software system, not just Web Services.
All content is
Copyright (c) 2008 Jorgen Thelin. All rights reserved.
The opinions expressed here represent my own views
and not necessarily those of my current, prior or future employer(s).
Content is provided "as-is", without any representations or warrenties of any kind.
Contents of the Weblog Feed are
licensed under a
Creative Commons License.