Lately, I have been getting some questions on scalability of EGL Rich UI, and especially how well the architecture supports many asynchronous services being called at the same time.
So, I decided to write a sample with a service looking like this:
Then I call that service however many times the end user likes:
The end result for 30 tries looks like this:
It finishes the whole calling sequence instantly. I'd say within 0.5 seconds or close to that. It is extremely hard to see the browser draw the results. It actually feels like it finishes drawing before I raised my index finger off the mouse button
To increase the stakes, I tried a more interesting number of service calls. So I entered 1,000 calls, fully expecting either my browser or Tomcat to give up and die:
However, 1,000 calls are still comfortably handled in around 2 seconds. Note that both the browser and Tomcat run on the same Thinkpad T60. Actual network delays will produce different results when repeating this on a service deployed on a production server.
As you can see the answers come back in a "random" order. This is to be expected. The first letter in "Ajax" stands for "a"synchronous, and that is actually how the messages are sent out, handled, and received again by the browser.
Finally, I tested the above little sample with 10,000 concurrent service calls, to see when the ship would sink.
This final experiment took a while longer, and Chrome kept asking me if I wanted to kill the runaway script while it was sending out those 10,000 Ajax calls
Eventually the whole thing finished. Making 10,000 calls this way took about 1 minute to send out all those requests, and then about 2 minutes to receive all the incoming results. Clearly, my algorithm exposed some non-linear performance.
Therefore, I rewrote my sample just a little bit, to send the same messages in 10 separate batches and not to print out every single message that came back. This removed an obvious bottleneck in the browser, and likely gave the browser's garbage collector the chance to catch up.
With the 10 batches, it took only 24 seconds on average to make 10,000 calls. Looking at the performance chart I could see that a lot more was happening in parallel now also, as both CPUs in my dual-core machine were running at 100% now.
For the tests with 100,000 and 1,000,000 calls I used 100 and 1,000 batches respectively.
Here are the end results in a chart:
As you can see above, you can expect to be able to make a million services calls in 2,400 seconds. This comes down to over 400 calls per second between a dedicated server and a browser. You hopefully agree that 2.4ms is a really good response time for a web service.
Transaction rates will go down when the distance between the browser and the server is larger. They will go up when edge caching and real production hardware is used, instead of a laptop. In other words, your mileage will vary.
In "real" world scenarios, my experience is that web service calls take anywhere between 40ms and 2 seconds to make the round trip.
Hopefully this experiment and its outcomes gives you some confidence about the scalability of EGL Rich UI. Being able to make 400 service calls per second is more than enough for any application I personally can imagine.
The developerWorks Connections Platform is now in read-only mode and content is only available for viewing. No new wiki pages, posts, or messages may be added. Please see our FAQ for more information. The developerWorks Connections platform will officially shut down on March 31, 2020 and content will no longer be available. More details available on our FAQ. (Read in Japanese.)