Most Read This Week
London 2013: The New Battlefield for Testing?
Both single-user performance and multi-user performance tests are required
By: Hervé Servy
Dec. 2, 2013 06:00 AM
I was at the Velocity Conference in London last week. Of course, fish & chips is still a must eat, a double-decker is far more than a bus, and pea shooting is, as always, so... British!
But away from these classic London cultural elements, at Velocity I heard more and more about performance. I saw many tracks related to rendering, browser optimization, even the neuronal impact of slowness; etc. But it was always about one user at a time... only. Not so much as a word was uttered about challenges with multiple users or back-end and infrastructure related tests.
Does it mean back-end load testing is over and I'm the only one who is not aware of it? Did an international committee sign a declaration to the end of problems on the server? Did the server problems melt in the sun behind the clouds? Am I to believe that your user experience with one user will be the same with 10 or 1 million users?
When sharing my concerns with others, I rapidly discovered two groups. The first group is for the single-user performance. The second is for the multi-user performance. Is it a new war in the making? Should we assemble our armies of keyboards and be prepared for the next battle? I would like to be the peacekeeper. So let's forget Waterloo and Trafalgar, at least for a few minutes...
To be perfectly honest, I work for a performance testing company, Neotys, which focuses on multi-user performance testing, but I do recognize that single-user performance testing is critical too.
Let me explain this middle ground to you.
"I want it all. I want it now."
As a consumer, I don't care about what is causing the problem. As a consumer, I just want to consume. Any time, any place. Like Freddy Mercury (UK singer) quoted, "I want it all. I want it now." That's the promise of "mobility" isn't it?
I'm sure you have all been in similar situations to these:
Your users are not experiencing your app in a vacuum. You cannot avoid end-to-end load testing. Both front end and back end are interacting. Both single-user performance and multi-user performance tests are required. The conjunction of the two situations must be optimized in concert.
"Revolution! All right, all right" The Beatles are back?
But I have to admit that this year I began to see the first projects using technologies that are drastically changing the principles of the network dialog between a browser and a server. I see our first SPDY projects. Does it change the server capacity? It just changes everything! Have a look at the measures I performed and documented in this article.
Also, I see our first WebSocket applications based on the Kaazing stack. I would never have imagined seeing a direct socket connection between a browser and a server. It does change all the principles of network allocation resources. For the server, it is the end of polling requests and definitively the end of the stateless principle (and resource saving) of http. Your server will have to handle this.
I studied relational algebra and then its son, SQL. I spent hours normalizing tables or mapping objects to tables. I'm almost certain you did it too. This year, I saw a very big project in EMEA... without a relational database... and it was not a mainframe sequential file ;>. Everything was a NoSQL file/base/stack called MongoDB. How could it work? It seems to work well - surprisingly well to a relational mindset guy like me. All the assumptions we have about number of users, number of tables, ratio of index, tables in memory, etc., have to be re-analyzed. Everything is new. There's not an index to add when things get slow.
Don't think that these technologies, which have wonderful packages and are quite easy to integrate, have no impact on the server. They do. On top of this, the most critical issue is that no one has a lot of experience with them and you will have to produce your own assessments.
How will your 15 minutes be? Andy is excited...
Even the US President can have a website that is having problems (even with the support of the NSA supercomputers to handle the load... joke).
Certainly, you may not be running a business the size of the US Department of Health and Human Services, but that is the reason why the US government will survive this website crash. Victoria's Secret survived after their website crashed during the Super Bowl. But your company, which spent all its energy on a new application, or a new version of the website, won't. Your $1M or $10M company can get killed by such an incident.
Andy Warhol stated, "In the future everyone will be world famous for 15 minutes." Be sure that this 15 minutes isn't cut short after 1 minute with a 503 code.
To be sure that yours will be fine, you must test. Single-user performance and multi-user performance. The battle to shine for these 15 minutes is the only one that is worthwhile. Don't you think?
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads