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 <jamie@bu.mp> 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