SSL session cache lifetime vs session ticket lifetime

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.

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?

Thanks.

Regards,
kyprizel.

Hello!

On Tue, Mar 18, 2014 at 03:26:10PM +0400, kyprizel wrote:

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 D.
http://nginx.org/

What will be the best way to do it?

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.

nginx.

network scheme.
cache and session ticket lifetimes?
http://mailman.nginx.org/mailman/listinfo/nginx


nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx


Maxim D.
http://nginx.org/

something like this?

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.

Probably a flag in ngx_slab_pool_t will be good enough.

Hi,
SSL session shared cache “SSL”
if session was added to the cache after expiration of some old ones.


Maxim D.
http://nginx.org/


nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx


nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx


Maxim D.
http://nginx.org/

will be “log_alloc_failures” better?

Any suggestions to the name?

Hello!

On Wed, Mar 26, 2014 at 01:34:19PM +0400, kyprizel wrote:

will be “log_alloc_failures” better?

I think something like “log_nomem” will be good enough.
Patch:

HG changeset patch

User Maxim D. [email protected]

Date 1395937285 -14400

Thu Mar 27 20:21:25 2014 +0400

Node ID 2cc8b9fc7efbf6a98ce29f3f860782a1ebd7e6cf

Parent 734f0babfc133c2dc532f2794deadcf9d90245f7

Core: slab log_nomem flag.

The flag allows to suppress “ngx_slab_alloc() failed: no memory”
messages
from a slab allocator, e.g., if an LRU expiration is used by a consumer
and allocation failures aren’t fatal.

The flag is now set in the SSL session cache code, and in the limit_req
module.

diff --git a/src/core/ngx_slab.c b/src/core/ngx_slab.c
— a/src/core/ngx_slab.c
+++ b/src/core/ngx_slab.c
@@ -129,6 +129,7 @@ ngx_slab_init(ngx_slab_pool_t *pool)
pool->pages->slab = pages;
}

  • pool->log_nomem = 1;
    pool->log_ctx = &pool->zero;
    pool->zero = ‘\0’;
    }
    @@ -658,7 +659,10 @@ ngx_slab_alloc_pages(ngx_slab_pool_t *po
    }
    }
  • ngx_slab_error(pool, NGX_LOG_CRIT, “ngx_slab_alloc() failed: no
    memory”);
  • if (pool->log_nomem) {

  •    ngx_slab_error(pool, NGX_LOG_CRIT,
    
  •                   "ngx_slab_alloc() failed: no memory");
    
  • }

    return NULL;
    }
    diff --git a/src/core/ngx_slab.h b/src/core/ngx_slab.h
    — a/src/core/ngx_slab.h
    +++ b/src/core/ngx_slab.h
    @@ -39,6 +39,8 @@ typedef struct {
    u_char *log_ctx;
    u_char zero;

  • unsigned log_nomem:1;

  • void *data;
    void *addr;
    } ngx_slab_pool_t;
    diff --git a/src/event/ngx_event_openssl.c
    b/src/event/ngx_event_openssl.c
    — a/src/event/ngx_event_openssl.c
    +++ b/src/event/ngx_event_openssl.c
    @@ -1834,6 +1834,8 @@ ngx_ssl_session_cache_init(ngx_shm_zone_
    ngx_sprintf(shpool->log_ctx, " in SSL session shared cache
    “%V”%Z",
    &shm_zone->shm.name);

  • shpool->log_nomem = 0;

  • return NGX_OK;
    }

@@ -1986,7 +1988,7 @@ failed:
ngx_shmtx_unlock(&shpool->mutex);

 ngx_log_error(NGX_LOG_ALERT, c->log, 0,
  •              "could not add new SSL session to the session 
    

cache");

  •              "could not allocate new session%s", shpool->log_ctx);
    

    return 0;
    }
    diff --git a/src/http/modules/ngx_http_limit_req_module.c
    b/src/http/modules/ngx_http_limit_req_module.c
    — a/src/http/modules/ngx_http_limit_req_module.c
    +++ b/src/http/modules/ngx_http_limit_req_module.c
    @@ -451,6 +451,8 @@ ngx_http_limit_req_lookup(ngx_http_limit

       node = ngx_slab_alloc_locked(ctx->shpool, size);
       if (node == NULL) {
    
  •        ngx_log_error(NGX_LOG_ALERT, ngx_cycle->log, 0,
    
  •                      "could not allocate node%s", 
    

ctx->shpool->log_ctx);
return NGX_ERROR;
}
}
@@ -674,6 +676,8 @@ ngx_http_limit_req_init_zone(ngx_shm_zon
ngx_sprintf(ctx->shpool->log_ctx, " in limit_req zone “%V”%Z",
&shm_zone->shm.name);

  • ctx->shpool->log_nomem = 0;
  • return NGX_OK;
    }


Maxim D.
http://nginx.org/

Hello!

On Fri, Mar 28, 2014 at 01:33:28PM +0400, kyprizel wrote:

Will this patch be applied to mainline?

Most likely it will, but testing and review are appreciated, as
usual.

@@ -129,6 +129,7 @@ ngx_slab_init(ngx_slab_pool_t *pool)

— a/src/core/ngx_slab.h
diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c

b/src/http/modules/ngx_http_limit_req_module.c
}


Maxim D.
http://nginx.org/


nginx mailing list
[email protected]
http://mailman.nginx.org/mailman/listinfo/nginx


nginx mailing list
[email protected]domain.invalid
http://mailman.nginx.org/mailman/listinfo/nginx


Maxim D.
http://nginx.org/

Will this patch be applied to mainline?

On Thursday 27 March 2014 20:23:15 Maxim D. wrote:

User Maxim D. [email protected]

The flag is now set in the SSL session cache code, and in the limit_req
pool->log_ctx = &pool->zero;
pool->zero = ‘\0’;
}

Just a quick nitpicking.

I’d suggest to put this log_nomem assignment in the last line as to
follow
order of elements in the structure definition.

wbr, Valentin V. Bartenev

[…]

 void             *addr;

} ngx_slab_pool_t;
[…]

Hello!

On Fri, Mar 28, 2014 at 11:38:53PM +0400, Valentin V. Bartenev wrote:

HG changeset patch

  • pool->log_nomem = 1;
    pool->log_ctx = &pool->zero;
    pool->zero = ‘\0’;
    }

Just a quick nitpicking.

I’d suggest to put this log_nomem assignment in the last line as to follow
order of elements in the structure definition.

IMHO, it looks silly this way, and that’s why it was placed just
before the log_ctx assignment.

Note well that the order of elements in the structure is more
about memory efficiency, and following the order isn’t something
required.


Maxim D.
http://nginx.org/

Hello,

From http://tools.ietf.org/html/rfc5077#section-3.4, I think Session
Tickets
and Session ID do not work for one connection at the same time. If the
client supports Tickets, then Session ID (or the session cache) will not
work.

Am I right? In my test, the 2 callbacks ngx_ssl_new_session() and
ngx_ssl_get_cached_session() are not called if ticket is used.

So if we assume that most browsers support Tickets now, the session
cache
does not work at most time, why does the ngx_slab_alloc() fails in your
post?

If I am right, should I just disable session cache, and set tickets life
time big enough?
Maybe SSL_CTX_set_timeout() should be moved to the beginning of
ngx_ssl_session_cache() then.

Thanks
Wu


View this message in context:
http://nginx.2469901.n2.nabble.com/SSL-session-cache-lifetime-vs-session-ticket-lifetime-tp7588963p7590693.html
Sent from the nginx mailing list archive at Nabble.com.

Hey,

Maybe SSL_CTX_set_timeout() should be moved to the beginning of
ngx_ssl_session_cache() then.

http://hg.nginx.org/nginx/rev/767aa37f12de

Best regards,
Piotr S.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs