[erlang-questions] [ANN] misultin v0.7

Loïc Hoguin essen@REDACTED
Sun Apr 10 20:18:42 CEST 2011


On 04/10/2011 08:08 PM, Bob Ippolito wrote:
> On Sun, Apr 10, 2011 at 10:56 AM, Loïc Hoguin <essen@REDACTED> wrote:
>> On 04/10/2011 07:35 PM, Max Lapshin wrote:
>>>>
>>>> I disagree. Mochiweb is slower because of design issues, not because it
>>>> has more functionality. Most of the functionality in mochiweb that
>>>
>>> You are speaking about stability and use blocking, unstable technique
>>> of listening and reading sockets:
>>>
>>> https://github.com/extend/cowboy/blob/master/src/cowboy_acceptor.erl#L34
>>>
>>>
>>> I advise to read this:
>>>
>>> http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles
>>
>> An acceptor process only accepts, it can be killed and restarted
>> without any fear of losing anything, which is why their supervisor
>> uses brutal_kill in the child spec. The listened socket is controlled
>> by a different process which makes killing acceptors a complete
>> non-issue.
>>
>> Nothing in your link indicates that blocking is unstable. I have an
>> application that's been up and running for many months that hasn't had
>> any issue with blocking. No crash has occured on this part of the code
>> or in the VM so far, and it's not running heartbeat either.
>>
>> Note that all the erlang http servers I've looked at so far use blocking.
> 
> mochiweb does accept in multiple processes in order to minimize
> latency. After doing this I found that our worst case times got
> better, but we were only able to observe this effect in production and
> did not try too hard to reproduce it with a synthetic benchmark.

Agree. In my tests I found that 100 acceptors give the best performance,
but that's probably dependent on the hardware.

-- 
Loïc Hoguin
Dev:Extend



More information about the erlang-questions mailing list