SSL session cache lifetime vs session ticket lifetime

[kyprizel]

will be "log_alloc_failures" better?


On Mon, Mar 24, 2014 at 4:10 PM, kyprizel <kyprizel at gmail.com> wrote:

> Any suggestions to the name?
>
>
>
> On Mon, Mar 24, 2014 at 3:56 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
>
>> Hello!
>>
>> On Mon, Mar 24, 2014 at 02:59:57PM +0400, kyprizel wrote:
>>
>> > something like this?
>>
>> Yes, something like.  But initialized and with a better name.
>>
>> >
>> >
>> > On Tue, Mar 18, 2014 at 8:00 PM, Maxim Dounin <mdounin at mdounin.ru>
>> wrote:
>> >
>> > > Hello!
>> > >
>> > > On Tue, Mar 18, 2014 at 03:42:33PM +0400, kyprizel wrote:
>> > >
>> > > > What will be the best way to do it?
>> > >
>> > > Probably a flag in ngx_slab_pool_t will be good enough.
>> > >
>> > > >
>> > > >
>> > > > On Tue, Mar 18, 2014 at 3:33 PM, Maxim Dounin <mdounin at mdounin.ru>
>> > > wrote:
>> > > >
>> > > > > Hello!
>> > > > >
>> > > > > On Tue, Mar 18, 2014 at 03:26:10PM +0400, kyprizel wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > > currently SSL session lifetime and SSL ticket lifetime are
>> equal in
>> > > > > nginx.
>> > > > > >
>> > > > > > If we use session tickets with big enough lifetime (12hrs), we
>> get a
>> > > lot
>> > > > > of
>> > > > > > error log messages while allocating new sessions in shared
>> memory:
>> > > > > >
>> > > > > > 2014/03/18 13:36:08 [crit] 18730#0: ngx_slab_alloc() failed: no
>> > > memory in
>> > > > > > SSL session shared cache "SSL"
>> > > > > >
>> > > > > > We don't want to increase session cache size b/c working with
>> it is a
>> > > > > > blocking operation and I believe it doesn't work good enought
>> in our
>> > > > > > network scheme.
>> > > > >
>> > > > > Just a side note: I don't think that size matters from performance
>> > > > > point of view.  The only real downside is memory used.
>> > > > >
>> > > > > > As I can see - those messages are generated by
>> ngx_slab_alloc_pages()
>> > > > > even
>> > > > > > if session was added to the cache after expiration of some old
>> ones.
>> > > > > >
>> > > > > > So, what do you think if we add one more config parameter to
>> split
>> > > > > session
>> > > > > > cache and session ticket lifetimes?
>> > > > >
>> > > > > May be better approach will be to just avoid such messages?
>> > > > >
>> > > > > --
>> > > > > Maxim Dounin
>> > > > > http://nginx.org/
>> > > > >
>> > > > > _______________________________________________
>> > > > > nginx mailing list
>> > > > > nginx at nginx.org
>> > > > > http://mailman.nginx.org/mailman/listinfo/nginx
>> > > > >
>> > >
>> > > > _______________________________________________
>> > > > nginx mailing list
>> > > > nginx at nginx.org
>> > > > http://mailman.nginx.org/mailman/listinfo/nginx
>> > >
>> > >
>> > > --
>> > > Maxim Dounin
>> > > http://nginx.org/
>> > >
>> > > _______________________________________________
>> > > nginx mailing list
>> > > nginx at nginx.org
>> > > http://mailman.nginx.org/mailman/listinfo/nginx
>> > >
>>
>>
>> > _______________________________________________
>> > nginx mailing list
>> > nginx at nginx.org
>> > http://mailman.nginx.org/mailman/listinfo/nginx
>>
>>
>> --
>> Maxim Dounin
>> http://nginx.org/
>>
>> _______________________________________________
>> nginx mailing list
>> nginx at nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140326/850861ca/attachment-0001.html>