Thanks for the tip Jamie! Setting NODELAY on the *client* resolved the problem; setting it on the server (both sockets) didn't make a difference. I'll see if I can figure out more about how this was going wrong - I did check the network traffic and the delay was at the server. But now I have a good setup to work with further. I did have your code from github, but from a while back, not long after you posted 0.2.2 to Hackage. I tinkered it a fair amount - stuff like where queues and worker threads are used, there are lots of options with that, especially given that thread creation is cheap so one doesn't necessarily need to use thread pools like in some other languages. Now I can play with those variations without distraction from long pauses. And I'll grab your latest from github and try that out. Thanks! Alex On Mon, Oct 8, 2012 at 6:41 PM, Jamie Turner wrote:

...

I'm seeing long pauses in a server based on the 'scalable-server' package from Hackage, version 0.2.2 [1]. It normally performs very well, about 100-150 micro-secs client latency over the loopback interface, but a fair number of requests are much slower, 38-40 milli-secs, making the mean latency and throughput quite bad.

Hi Alex--author of scalable-server here.

38ms sounds like Nagle's algorithm. (http://en.wikipedia.org/wiki/Nagle's_algorithm) In short, the socket is waiting on sending a small amount of data to see if the application wants to send more data. If so, the kernel can repack the data together so that it all can be switched in one TCP packet.

You need to set NoDelay (TCP_NODELAY) if you want to disable this behavior; scalable-server doesn't currently have a flag to configure this, but I'm open to pull requests!

(Also, are you using hackage scalable-server, or the "new" scalable server based on conduit on github? I'd recommend switching to the github version if not. A few key bugs exist in the older implementation.)

- Jamie