kilim web server

[seth/nqzero]

i have a kilim-based application that i've wrapped with a
(synchronous) tomcat servlet. it works great, but tomcat ends up being
a bottleneck - i've got very cheap kilim "threads" being called by the
expensive tomcat threads

one option is to move to asynchronous servlets. i've read some good
and some bad about them, and haven't seen a good answer on the max
number of concurrent connections that can be achieved and i haven't
dug in deep enough to understand what resources are allocated
per-connection

the other option is a kilim based server.
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-769.pdf describes KWS.
is this code (and the MOB tester) publicly available ? i've looked at
kilim.http and the servers in /examples and i'm guessing that there's
enough there that i could hack something together. my use of servlet
is pretty limited - i need a session id and getParameter. i'm not
currently using websockets but might want to in the future

anyone have any experience with kilim based "servlets" ? or
suggestions on an existing server that i might be able to port to
kilim ?

[Jason Koch]

Hi Seth

Have you tried using the NIO connector with Tomcat?

http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

Thanks

Jason

--
You received this message because you are subscribed to the Google Groups "kilimthreads" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kilimthreads...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[seth/nqzero]

@jason - my understanding is that the nio connector won't block on
keep-alive, but still needs a thread per request. from the page you
linked:

> Each incoming request requires a thread for the duration of that request

my kilim based processing might take several seconds per request, and
i'd like to be able to handle 1000+ of concurrent requests. so i don't
think the thread-per-request model is going to work for me

[Jason Koch]

I see, just re-reading, the issue is not the threading model used in the connector, but the fact that you need the servlet container to provide the request/response correlation after Kilim has done processing. Apologies for the hasty response - I assumed you were offloading the work from the servlet to some background kilim threads to work on.

I did find this - http://www.kotek.net/blog/writing_fast_nio_webserver - but it doesn't seem to be well maintained (the link to more info gives a 404).

It's not the answer you want of course, but 1000+ concurrent requests shouldn't be a big stretch for a new-ish kernel - depending on your jitter requirements (not as efficient of course).

Thanks

Jason

[seth/nqzero]

thanks jason. i didn't realize that 1000 threads wasn't unreasonable -
guess i'll have to set up a stress test and try it. though still would
be sweet to find a kilim-friendly solution. i'm also going to try
tomcat async and jetty

[Sriram Srinivasan]

the other option is a kilim based server.
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-769.pdf describes KWS.
is this code (and the MOB tester) publicly available ?

The MOB tester is quite bitrotted, and not documented at all, so it'll take a fair bit of effort to package up. There are a number of http testers around anyway. As for the KWS, all the essential bits are already in kilim.http. If all you're using Tomcat for is request and response handling (and not say, https or cookies), then kilim http is more than sufficient and really really fast. The HTTP parser is Ragel-based, and is lazy (in that it goes through all the unimportant headers without creating a map), and the kilim/ NIO combination is something I'm rather kicked about.  The SimpleHttpServer example in the examples directory shows off all the bits. 

In essence: 

1. Define a task, MyServlet, say inheriting from HttpSession.  

2. Create/register with new HTTPServer:

     new HttpServer(listenPort, MyServlet.class);

3. A task instance of MyServlet class is created for every new incoming client connection,

    and can hang around as long as it wants. 

4. MyServlet.execute() looks like this:

     public void execute() throws Pausable {

            HttpRequest req = new HttpRequest();

            super.readRequest(req); // fill up the request

            HttpResponse resp = new HttpResponse();

            .. call req methods, and resp.WriteTo methods.

            super.sendResponse(resp) 

     }

You can have a long-lasting connection by wrapping the whole thing in an infinite loop. 

That said, there's no reason to fear threads. Take a look at Paul Tyma's presentation.  He argues that threads are simpler and faster than the standard way of doing NIO. Very true. 

But the Kilim way of doing NIO is much much faster than his approach, for reasons described in my thesis. 

[seth/nqzero]

thanks for the reply sriram

The MOB tester is quite bitrotted, and not documented at all, so it'll take a fair bit of effort to package up. There are a number of http testers around anyway

the blog posts comparing tornado and node.js all seem to use multiple httperf processes - a kilim based client might be lighter and allow for better simulated loads (and maybe comet ?). so if the code is unencumbered and it's just a matter of polishing the rot i'd be willing to try

As for the KWS, all the essential bits are already in kilim.http. If all you're using Tomcat for is request and response handling (and not say, https or cookies), then kilim http is more than sufficient and really really fast

unfortunately i do need cookies to store a session id, but maybe i can parse that myself. i've mocked something up, but need to remove some vestigial framework stuff. i'll report back if i get some tomcat vs kws numbers

That said, there's no reason to fear threads

my understanding is that a java thread uses about 1M for stack. i'm targeting lowendbox/vps setups so hoping to keep that footprint down. since i'm already using kilim for the backend, KWS seems like the perfect solution