SSL session cache lifetime vs session ticket lifetime

[kyprizel]

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/20140324/98bcb0a1/attachment.html>