On Thu, Oct 11, 2012 at 3:11 AM, Kazu Yamamoto wrote:

Hi,

...

warp relies on network-conduit which uses maxListenQueue. I will fix this anyway.

acme-http specifies (max 1024 maxListenQueue) to the listen queue. I like this approach. So, I fixed network-conduit in the same way.

https://github.com/kazu-yamamoto/conduit/commit/5b1f9f05405abb11a8bc0893c0cd...

P.S.

I will fix documentation only for the network package.

--Kazu

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Thanks for the pull request, it's on Hackage as network-conduit 0.6.1.1. Michael

Hi Jeremy, First of all, thank you for implementing acme-http. It much helps me when I am improving the performance of warp.

Awesome! That is exactly what acme-http is for! I am definitely interested in figuring out ways to improve acme-http so that it can be a better reference for 'best practices' when it comes to high performance HTTP servers. So, if you discover techniques that can be applied to acme-http I am very interested in hearing about them. Especially when it comes to the 'black magic' parts. acme-http makes no attempts to decode the request body.. because making a faster multipart/form-data decoder is relatively straight-forward. With acme-http I want to explore the more mysterious bottlenecks -- things like maxListenQueue, TCP_NODELAY, etc.

One question and one suggestion. Question: you set NoDelay to the listen socket. What is the intention? Do connected sockets inherit this flag? Regardless of inheritance, I'm not sure this option improves the performance of HTTP servers. It is the option for interactive applications such as ssh. Suggestion: allocating ByteString is a heavy job. If you can reuse the ByteString of recv() for multiple HTTP requests in an HTTP connection, the performance would be improved much. --Kazu

On Tue, Oct 16, 2012 at 6:20 PM, Jeremy Shaw wrote:

On Thu, Oct 11, 2012 at 12:31 AM, Kazu Yamamoto wrote:

...

Hi Jeremy,

...

One question and one suggestion.

Question: you set NoDelay to the listen socket. What is the intention? Do connected sockets inherit this flag? Regardless of inheritance, I'm not sure this option improves the performance of HTTP servers. It is the option for interactive applications such as ssh.

I am pretty sure I just copied that flag from snap. Yay for cargo culting! It tests show that it doesn't help anything then we can remove it. Or at least add a comment that is doesn't appear to help anything..

The NoDelay flag disables Nagle's algorithm ( http://en.wikipedia.org/wiki/Nagle's_algorithm). If you write() to a socket fewer bytes than the TCP maximum segment size (usually 1460 for ethernet), by default the kernel will delay the physical write for some time in the hopes that more data will be coming. (The idea is to reduce packet header overhead for interactive applications like telnet). Obviously this is bad for throughput, and you should always turn it off in server applications that do their own buffering. On my linux machine, this flag *is* inherited by accepted file descriptors from the listening socket. You can test for yourself: https://gist.github.com/3900556 G -- Gregory Collins