> > What would be the consequences of increasing the value to say 256 or > even higher than 1024? > > One could argue that the handler is broken as it is splitting the > message into lots of very small messages (length less than 210), but > as a stopgap measure, I would like to, for the time being increase the > number of outstanding messages and see how that impacts the > performance of mongrel2. > > --Jeff For the time being, I am reverting back to using 1.7.5 because I am not sure how I should handling file downloads in my handler.
My setup is one mongrel2 process and one handler process with 1 thread. Both are running on the same VM that has one processor core. Unfortunately, when running mongrel2 1.8.0 and streaming one 100+ MB file it is very easy (happens almost all the time) with one mongrel2 and one handler chunking the files into 64k pieces to run over the deliverRing with 128 slots (default is 16 slots). Note that the files are created on demand, and generally no two are the same. Without something like X-sendfile, this "ring" makes it difficult to stream files from a webpage as someone can generally make some case where the "ring" is too small. I don't have the time to investigate the issues at this time, but is anyone using mongrel2 1.8.0 in production? How do you get around a similar issue of having multiple outstanding requests with multiple handlers that send a relatively large number of messages (relative to DELIVER_OUTSTANDING_MSG)? In other words, mongrel2 is supposed to scale very well, but with multiple users making lightning fast requests (or a handler that sends lots of small messages per request), it appears quite easy for a connection to have more than 16 outstanding messages. --Jeff
