Response Time of sleeping gwan server script

Question

I want to figure out how gwan responds if a script takes longer than 1 second to finish.

To do so, I used the sleep() function in the hello.c example:

#include "gwan.h"  
#include <unistd.h>  

int main(int argc, char **argv)  
{  
    sleep(5);
    static char msg[] = "Hello, ANSI C!";  
    xbuf_ncat(get_reply(argv), msg, sizeof(msg) - 1);  
    return 200; // return an HTTP code (200:'OK')
}

The response time I got from Chrome was >= 5 seconds, as expected.

Then, I have run a Weighttp concurrency test, and here is the response time I got from Chrome in ms (millisecond).
Is this a caching issue? Where the 5 second sleep time has gone? Thanks.

Answer 1

Your sleep(5); test is pointless (at best) and, as expected, G-WAN timeouts the blocking script to avoid blocking the server because of a buggy script.

If the blocking servlet is used under concurrency, lik eyou did later, then, instead of pointlessly timing-out every execution (this would take time), G-WAN flags this servlet as buggy and no longer executes it.

This blocking issue would not exist with a more interesting test: see how G-WAN can serve a 10-second system PING without ever blocking.

If you have a script that needs 5 seconds to do its job then you SHOULD NOT wait for 5 seconds. Blocking the server thread is the least intelligent thing to do.

If you do that with another server, and say, use a single-threaded program like Nginx, this will just prevent new connections from being processed: your server will be dead.

G-WAN does better because (a) it uses several threads and (b) because it has dedicated aynchronous interfaces, see below.

For replies that span over a long period of time G-WAN offers:

1. a Comet API (see the comet.c example)
2. a streaming API (see the stream1/2/3.c examples)
3. a transparent asynchronous interface to avoid blocking I/O.

So, if you want to see how G-WAN processes real-life slow scripts, then write some realistic code.