Simulating Latency with Greasemonkey

Julien Couvreur has another approach to simulating network latency in AJAX apps – XmlHttpRequest – Add Latency. Certainly a neat solution in terms of lines of code 😉 Some random thoughts, perhaps to give Julien ideas.

When considering AJAX Proxy had half thought of Greasemonkey although figured an HTTP proxy is a more “honest” solution. Re-thinking, will probably work just as well with Greasemonkey.

Some specific things I wanted to be able to simulate with AJAX Proxy, with reference to Julien’s approach;

  • Latency swings both ways. A delay could occur in the direction from client to server, sending a request. A delay could also occur from server to client, as the response is delivered. OK – that’s not exactly how the HTTP protocol works but from an application point of view, it makes a useful simplification.
    For example consider an AJAX chat application – there might be an operation on the server called “save message” which stores a single chat message sent in a request by a client. The response from the server to this operation is simply an “OK” or “Failed”. So what’s interesting is really any delay in the client to server direction. If the latency is varying over time (which it might), it could be possible that “Message A” and “Message B”, sent by the client, are received in order “Message B” then “Message A” by the server. The server needs to check the messages are stored in the right sequence (which implies the client is providing some kind of sequence information)
    Meanwhile another server operation, “get new messages”, is polled by the client to obtain new messages after a certain time or sequence ID – varying delay in either the server to client direction or vice versa causes new messages to be received by the client in the wrong order; the client also needs to check the order of what it receives.
    At the moment Julien’s solution is only delaying messages in the client to server direction – the delay he uses is inserted before the request is actually sent. Think it also needs to be possible to have a delay inserted after the response was received from the server but before the corresponding callback function is executed ( that’s going to dramtically increase the lines of code required though).
  • Latency may vary over time. Julien uses a consistent delay, which will highlight painful end-user experiences but as the above point illustrates, it’s more subtle than that. On a typical network would get “spikes” and similar that mean things like for half a second response times are really bad but then recover. Depending on what you’re doing with AJAX this may mean you need to implementing “queueing” or sequencing – the Starbucks factor.
  • Latency is not predictable. Basically the same point as above but would be nice if Julien’s solution supported “randomness” as another mode of testing.
  • Sometimes it just fails. And a request might fail to get to the server or a response might fail to get back to the client – complete network failure somewhere down the line. From what I’ve seen with AJAX Proxy, when completely dropping requests and responses, the current browser XMLHttpRequest implementations do little, if anything, to report this to the caller (or callback). And from testing a few online AJAX demo’s (I’m avoiding naming names here but I’m sometimes sorely tempted) this will mean data loss for some apps.

Think it should be possible to simulate all of those conditions with Greasemonkey, although it’s a fair amount of work. Wish Julien good luck with it.

At some point will give AJAX Proxy a decent CLI startup interface (rather than having to hack the code) and package it with py2exe but right now, no time.

Another angle someone should look at is fiddler, which is basically AJAX Proxy but a lot better (Windows only though). Check out this forum post – should be possible to implement all of the above with JScript and fiddler.

Question: Is all this really a problem? We all care about accessibility, right? Well this is accessibility in the literal sense. You need to leave localhost realise this is a real problem – take a holiday to South Africa then try accessing your AJAX app over in the States. Failing that, make a friend of a South African – you may learn some new swear words.

3 Responses to Simulating Latency with Greasemonkey
  1. online proxy server
    December 10, 2007 | 1:00 pm

    online proxy server…

  2. Nico Veenman
    July 10, 2006 | 6:49 am

    Another interesting and very easy way to do latency testing if you use .net webservices is to implement a soapextension.

    In the ProcessMessage method of the extension during the AfterSerialize Stage you just add a:
    System.Threading.Thread.Sleep(new Random().Next(10000));

    And voila! Each request will take between 0 and 10 seconds longer than ‘normal’ on localhost.

    Ofcourse this is not a 100% best way to test latency, but it is at least testing what happens if the server->client communication takes longer.

  3. tsert
    March 25, 2006 | 5:38 am