Performance testing of web application built over long-polling architecture

Check new series of the articles. Review and user experience on test management systems. Functionality and usability.

-------------------

It's not a rocket science how to perform load testing of regular web application. Basically you need to measure the time between you send the request to the server and the time the server responds. Much harder is to test so called long-polling architecture where it becomes not reasonable to measure respond-request time as the respond time depends on actually two points:

1. If the server has anything to say to your client it responds immediately
2. If not, it waits for the threashold and responds breaking the connection which is restored immediately so a kind of persistant channel occurs.

But wait. Does that mean we have no chance to consider the performance metrics to measure? Not actually.

See the model of long polling communication I've prepared for you. The strong horizontal line here means the layer responsible for long-polling communication between the client (uasually your web-browser) and the server.

(1) Client sends regular request to configure the server to know which information the client wants to recieve from the server.
(2) Client sends the request asking if the server has requested data to publish. This request should be configured to have appropriate awaiting interval (bigger than a Threshold)
(3) Server keeps the request while it has not data to publish. If the data is not ready in Threashold interval the server responds with corresponding message.
(4) Client gets the response and recreates the request (all those client requests compose a kind of persistent data channel).
(5) Once the data is ready the server respondes (6) to all the clients subscribed for it.

So what we need to know is how fast the client gets published data. To find that out we should measure the interval between (5) and (6).

But wait once again. The number of clients subscribed for certain data may be actually pretty big. Should we somehow consider this fact when measure the performance. Yep - we should. When the data is ready the server iterates though a pool of the subscribers and responds the corresponding requests. This means in such the case there will be a client which will get the respond later than others ones. Here we can consider two metrics of our application performance. They are:

1. Time interval between the data gets ready on the server and the fact of getting it by the first client
2. Time interval between the first and the last client gets the data

P.S. - Performance testing of long-polling architecture is not easy stuff. To perform it effectively you sould be absolutely sure you can control the data readiness and synchronize it with client requests.