[99s-extend] Cowboy HTTPS connection memory usage

rambocoder erlang at rambocoder.com
Fri Dec 21 20:25:10 CET 2012


Long story short, I solved the problem by adding {max_connections, 50000}
to cowboy:start_https because it default to 1024 at
https://github.com/extend/ranch/blob/master/src/ranch_listener_sup.erl#L30

However, before I figured out that setting, I did run eprof and these are
the function calls it was spending most of it's time on


FUNCTION                                    CALLS      %   TIME  [uS /
CALLS]
--------                                    -----    ---   ----
 [----------]
dict:get_slot/2                               174   1.73   1658  [
 9.53]
dict:on_bucket/3                              171   1.77   1701  [
 9.95]
erlang:setelement/3                           684   3.23   3098  [
 4.53]
dict:store_bkt_val/3                          600   5.24   5028  [
 8.38]

Then I ran etop and it showed that ranch_acceptor:maybe_wait had the most
reductions were, so I looked at the code in that
https://github.com/extend/ranch/blob/master/src/ranch_acceptor.erl#L72 and
realized that like a newb I did not set the maximum connections for the
listener :)

Problem solved. Looks like I won't need to put HAProxy in front of Cowboy
after all.

Thank you,

rambocoder

On Fri, Dec 21, 2012 at 11:51 AM, Loïc Hoguin <essen at ninenines.eu> wrote:

> Can you try enabling eprof to see where the VM spends its time?
>
>
> On 12/21/2012 05:49 PM, rambocoder wrote:
>
>> In my preliminary testing, I used Jmeter this morning since it's an
>> easy GUI load testing app and this is what I am seeing:
>>
>> With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true],
>> when I establish 1K concurrent connections via HTTPS, each connection
>> takes up about 68K of memory.
>>
>> Unfortunately, after about 1050-1200 connections, on my test server the
>> Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers,
>> while up to that point the scheduler's load was oscillating up and down.
>> Using the Observer, there is only 1 ssl_connection_sup  in the ssl
>> application, having to deal with 1000+ gen_fsm workers, so that might be
>> the bottleneck. Since the ulimit on my server is 50000 I don't think I
>> am hitting any type of file handler's limit.
>>
>> Loïc and the group, am I missing some setting that is causing the
>> scheduler to go to 100% CPU and the run que in observer to be 99?
>>
>> Sincerely,
>>
>> rambocoder
>>
>>
>>
>> On Fri, Dec 21, 2012 at 6:45 AM, Loïc Hoguin <essen at ninenines.eu
>> <mailto:essen at ninenines.eu>> wrote:
>>
>>     On 12/21/2012 04:34 AM, rambocoder wrote:
>>
>>         Does anybody know either from benchmarks or real world data what
>>         is the
>>         average memory footprint of each concurrent HTTPS connection to
>>         cowboy?
>>
>>
>>     I don't have anything, sorry. I'm guessing it consumes a lot more
>>     than TCP though.
>>
>>
>>         SSL app in Erlang reuses SSL session-ids so I am not sure if the
>>         Apache
>>         Bench I test with reuses the session id or it does not.
>>
>>
>>     I wouldn't know, but I wouldn't trust Apache Bench doing the right
>>     thing. Any other benchmark tool usually works better in my experience.
>>
>>
>>         BTW, what makes an erlang api "documented" vs "undocumented". For
>>         example ssl:session_info/1 function here (
>>         https://github.com/erlang/otp/**__blob/maint/lib/ssl/src/ssl._**
>> _erl#L411<https://github.com/erlang/otp/__blob/maint/lib/ssl/src/ssl.__erl#L411>
>>
>>         <https://github.com/erlang/**otp/blob/maint/lib/ssl/src/**
>> ssl.erl#L411<https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411>
>> >
>>         ) has
>>         a spec and a short doc, but session_info is not described
>>         http://www.erlang.org/doc/man/**__ssl.html<http://www.erlang.org/doc/man/__ssl.html>
>>
>>         <http://www.erlang.org/doc/**man/ssl.html<http://www.erlang.org/doc/man/ssl.html>>
>> .ssl:session_info/1 is
>>         a useful
>>         function to be able to track if the load generator is reusing
>>         the SSL
>>         session_id or it is generating new one, because that would make
>>         all the
>>         difference during measurement due to Erlang caching SSL sessions
>>         by default.
>>
>>
>>     The documentation is separate (they're not using edoc). It's perhaps
>>     not deemed useful enough for documenting it. I wouldn't worry about
>>     using it for measurements though.
>>
>>     Try asking Ingela on the ML about it, perhaps they just forgot to
>>     document it.
>>
>>     --
>>     Loďc Hoguin
>>     Erlang Cowboy
>>     Nine Nines
>>     http://ninenines.eu
>>
>>
>>
>>
>> ______________________________**_________________
>> Extend mailing list
>> Extend at lists.ninenines.eu
>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
>>
>>
>
> --
> Loïc Hoguin
>
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20121221/945f636e/attachment.html>


More information about the Extend mailing list