Load testing is probably one of the most important aspects of a thorough Q/A strategy yet often appears to be an afterthought. Today’s web applications have become critically interdependent on third party services, such as IP geolocation. If the geolocation integration requires the IP lookup and subsequent execution of business logic to complete synchronously before returning content to the user, it is important to ensure the service is operating at acceptable thresholds.
This article assumes that you have a basic understanding of load testing. For a good primer on load testing check out some articles from the Neustar community support site.
Load testing a geolocation integration should be approached in much the same way as any other load testing initiative. Unless the goal is to test to break, define what constitutes a successful test. This may be metrics like: total volume page views per hour, response time expectations, or acceptable error rates. These key performance indicators will help you determine “what” to test and how much load to apply. The recommendation is to first focus on the customer experience.
With Neustar IP Intelligence there are three delivery formats: a data file via FTP, a local HTTP server, or web services (RESTful) based. There is no reason to load test the FTP server. Tuning a GeoDirectory Server (GDS) server to 20K+ queries per second (QPS) is not common and the web services delivery will likely not be the HTTP based bottleneck. However, there is no substitute for a locally hosted solution. If you really need to optimize, import into Oracle (or a non-relational model) and interface with C++. Regardless of the implementation, first test the single most important customer experience use case; in e-commerce this would be the checkout process.
Load Testing Example
Let’s assume an e-commerce provider uses geolocation for content customization, e.g. display surfboards in California or hockey sticks in Canada. Potentially the geo lookup is also used for fraud detection during checkout, but we will assume the payment processor provides that. Simple is generally better when starting with load testing. Build one single browser automation test script that walks through the checkout process via a couple of thousand concurrent, highly active sessions and you will likely discover at least one new peculiarity about the application.
Suppose the test results showed the initial page response time needed to be improved by optimizing the custom inventory being displayed. This custom query is comprised of an IP lookup request to the GDS server, parsing the XML response and using location specific properties to query the database of products. The geolocation server can be tested internally using a tool like Apache ab. Another option would be to instrument the application stack, using a tool like AppDynamics, to isolate response times of the geolocation lookups versus the response times of the SQL queries.
Load testing often happens last minute, so focus on the customer experience first and solve the mission critical errors. Fine tuning is a process and once the application has been put into production, consider monitoring of these critical scenarios on an ongoing basis. Within Neustar Web Performance Management the same Selenium based test scripts can be used for both monitoring and load testing. All additional pages can be supplemented with Real User Measurement (RUM) tags and correlated via intelligent alerting actions.