Performance Testing: “Armed And Dangerous”

by Alex Yakima and Sergey Sydorenko

Alex: I didn’t actually choose the title for this post just for the fun of it. And not after the great video game of its time made by Planet Moon Studios. It’s been proved in trenches: when you practice something repetitively and have efficient tools for that, whatever that task be, it’s gonna get you where you wanted to be with it eventually. And probably performance testing as a is one of those best examples when you (as a team) should demonstrate discipline in performing proper software testing and then tune the system properly based on that. And do that regularly, every iteration… or fail. But it’s not always obvious, so not all software development teams would do that. And that’s a huge mistake…

Sergey: This time I want talk about the web application load and stress testing tool that we used in product development projects for our clients – NeoLoad .

Alex:
We were using this tool to test two different web apps: search engine that we’ve made and the ecommerce web site that we developed from the scratch to meet very specific client needs. For the latter, the entire whole thing was one big personalized offers engine built upon a number of affiliate networks product sets. These were actually two absolutely different apps, search system had way simpler use-case scenarios and the ecommerce site had pretty complex ones with lot’s of ramifications and many of them were vital from the business perspective. Although as it turned out it was way more difficult to improve search-time performance for the search engine that mess with the ecommerce site…

Sergey:
How your app performs? How it is possible to test this sort of web applications? Does it support Ajax? Is there a load balancer on the front end? Is it possible to test application remotely on the client environment? All these questions and much more we put first during the process of selection of the performance test tool. Finally we choose NeoLoad, because:
• It lets you to test all Web infrastructures, including AJAX, SOAP, Flex, Oracle Forms, Silverlight, .NET, J2EE, PHP, ASP and many more.
• It is easy to test web applications remotely
• It has powerful reporting mechanism

In this post I will plunge in a little bit of detail on performance testing of web applications on the remote environment.

We used Neoload to test web applications at Luxoft servers. Such approach was really good to define memory leaks, performance bottlenecks and application stability during development cycle, but it was not enough for production. You may ask “Why?” The answer is simple, hardware configurations of staging servers and the production servers were different (this did historically happen) and as a result page response time may vary from server to server.
Decision was to test application on the production environment. The best way to test web page response time (but not the ISP channel performance ☺, especially when overseas) is to install the test web “client” as close to the target app as possible. Ideally in the same LAN with the very web application. For such purposes Neoload has LoadGenerator which can be installed at Linux/Unix, Windows, Solaris , 32 bit and 64 bit platforms without any problem. To get it work we need to:
  1. setupLoadGenerator at Production environment
  2. setup internet connection between NeoLoad and LoadGenerator, it can be direct connection via internet, SSH tunnel or VPN/SSL connection.
  3. finally run our test scenarios.
These pair Neoload and LoadGenerator works in such way:
  1. NeoLoad send test scenario to LoadGenerator
  2. LoadGenerator run it at Production server
  3. LoadGenerator send back test results
Alex: I think I just want to add that across development iterations and releases performance testing and monitoring has to be mature systematically applied discipline. On these both projects I think every iteration demo would include short or sometimes not so short report on performance measurement results. Specifically with the search engine project guys used to joke that we don’t perform software development for a product, we just move from one bottleneck to another. And that’s fairly true for many systems. This kind of projects helps you develop performance testing rather as a culture, not so much of a formal duty.

Comments

Not to be published