[erlang-questions] ssl_connection process hibernation option

[Kaiduan Xie]

Ingela,

This is a great news, Ingela. When can we have this improvement?

Best regards,

/Kaiduan

On Fri, Feb 4, 2011 at 10:51 AM, Ingela Andin <ingela.andin@REDACTED> wrote:
> Hi!
>
> We already put some effort into cleaning the state of the gen_fsm
> processes holding the connection,
> but some form of hibernation could be interesting too we will take
> this into consideration.
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
> 2011/2/4 Jeroen Koops <koops.j@REDACTED>:
>> I would very much appreciate this too.
>>
>> As a test, I inserted a proxy-module between the gen_fsm and ssl_connection
>> callback, that changes all responses from the ssl_connection callback to
>> include the 'hibernate' option (it's not a hack -- it's AOP!) and the
>> savings are dramatic: before the change an SSL connection used around 350
>> kB, after the change only around 600 bytes. If a system is maintaining
>> thousands of SSL connections, this really adds up.
>>
>> If we could somehow get hibernation built in to the ssl application, that
>> would be great.
>>
>> On Fri, Feb 4, 2011 at 9:57 AM, Ferenc Holzhauser <
>> ferenc.holzhauser@REDACTED> wrote:
>>
>>> Hi,
>>>
>>> I'm using R14B01 new SSL to set up a lot of (not very active) client
>>> connections.
>>>
>>> I have noticed that ssl_connection processes use a lot of memory between
>>> GC's.
>>> A forced GC makes them small again until the next piece of received data.
>>>
>>> This adds up to a significant memory usage (around 350-400 kB/session on a
>>> x64 system in my case) limiting the number of possible sessions.
>>>
>>> An option to hibernate this gen_fsm would decrease the average memory usage
>>> in this scenario.
>>>
>>> Would it be possible to introduce this option?
>>>
>>> Thanks in advance,
>>> Ferenc
>>>
>>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>