Hello Roberto, It's a pretty interesting idea, indeed. Good stuff!
I can see pros and cons though. Pros, as you have exposed, are mainly related to performance - that's good. Now, I can also think about a few issues that I'd like us to address: - Since the server wouldn't know what happens with the connection, it won't be able to build a reasonable entry in the log file: it won't have any data about the response length, HTTP error code, or even about when the connection is closed. - The usage graphs would be rendered useless. Again, since the server transfers the connection on uWSGI so early, it has no way to know what happened, so the collection of data about traffic and timeout connections would become inconsistent. - The output of the back-end cannot be encoded, chunked or cached by the server either. Nor headers could be rewritten, for instance. So, even if the idea is good, I believe we ought to work out these issues before recommending to use this new mechanism. Cheers! On 25/02/2011, at 11:57, Roberto De Ioris wrote: > Hi all, the attached patch (against current svn trunk) add a very specific > feature > to the uWSGI handler. I do not know if it so "specific" that it cannot be > included, so i will try to > explain its usage (requesting for comment/opinion) > > Unix sockets have a specific (and amazing) feature that allows you to pass a > file descriptor (a socket in our case) > to another process: > > The client 0 send a connection request to server 1 > > server 1 accept the request and open a new socket with client 0 > > client 0 send a http request to server 1 > > server 1 receive the request and connect to a source (a uWSGI server) > > server 2 (the uWSGI server) accept the connection and open a new socket > (server1 <-> server2) > > server 1 send the uwsgi header to server 2 and pass the socket of client 0 > > server 2 attach this socket and from now on it directly communicate with the > client 0 > > In my company we are using this feature for 2 kind of apps. > > The first one is a icecast compatible server written on uWSGI api. > > Cherokee receive the standard http header from the icecast producer, pass the > encoded vars to the uWSGI server, > then uWSGI start communicating directly with the client (that will start > sending audio data) > > The second one is a WebSocket implementation. > > The client (google chrome) send the http websockets header to Cherokee. > Cherokee pass it to uWSGI and than uWSGI start websockets communication with > google chrome. > > Another (probably less specific) feature, is boosting the performance of app > response, as the > uWSGI->cherokee->client path is substituted with uWSGI->client > > > It currently works reliabily in our projects, but closing the socket soon > after the write() will clobber a bit > Cherokee logging system (and probably some other internal, but for now we > have no crash :) ) so, i imagine > that we should add a condition to Cherokee when the connection to source does > not expect a response. > > Thanks a lot for every kind of response. > > -- > Roberto De Ioris > http://unbit.it > > <cherokee_uwsgi_pass_fd.patch> > _______________________________________________ > Cherokee mailing list > [email protected] > http://lists.octality.com/listinfo/cherokee -- Octality http://www.octality.com/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
