You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marion & Christophe JAILLET <ch...@wanadoo.fr> on 2019/05/10 15:23:57 UTC
Re: [2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management
performance
Hi,
have you checked the work in trunk related to
"SessionExpiryUpdateInterval"? [1]
If you have the opportunity to compile and test the trunk version and
report if it corresponds to your use case, it would be great.
If you want to have a look at the code itself, see [2].
Just my 2c,
CJ
[1]:
https://httpd.apache.org/docs/trunk/mod/mod_session.html#sessionexpiryupdateinterval
[2]:
http://svn.apache.org/viewvc?diff_format=h&view=revision&sortby=date&revision=1709121
Le 10/05/2019 à 12:26, Vincent Deffontaines a écrit :
> Greetings,
>
> The root observation that makes me open this subject is the following :
> Using mod_auth_form + encrypted cookies to manage a web application
> authentication gets httpd's auth cookie to be reset by the server at
> each and every authenticated request. On a website with a number of
> users x a number of requests, this gets quite a number of HMAC crypto
> cookie cyphering operations, which I guess could be reduced.
>
> In order to debug this, I started running the attached configuration
> (it's pretty much just the most reduced setup to use the module
> combination, nothing fancy).
> This setup does not enforce cookie encryption. When cookie are
> encrypted, I obviously just can notice they differ from a request to
> another. When they are not encrypted, I understand why.
>
> Here are a few successive (ordered) cookies sent by the server with
> this configuration, including the dummy login and password I'm using
> for illustrating this matter :
>
> Set-Cookie:
> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>
> Set-Cookie:
> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>
> Set-Cookie:
> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870865331;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>
> The most interesting part is that, no matter how close in time these
> requests can be, the "expiry=%ld" part will change, because it is an
> epoch timestamp with a precision up to the microsecond.
>
> I guess nothing here is wrong, regarding RFC2109. But it appeared odd
> to me, as opposed to the way most web sessions are dealt with : while
> our cookie lifetime definetely matches the MaxAge produced in
> configuration, it is nevertheless reset by the server at each request.
>
> This is of no performance consequence in this debug setup, but I
> believe the load can be affected as soon as one sets a
> SessionCryptoPassphrase ).
>
> For what it's worth, I have benched the difference on my (non-summy)
> application, by reloading the main page (which implies quite some
> applicative processing on the server, too, and loads 119 hits to
> generate the page).
> When sessions are encrypted, for 10 refreshes of the page, I measure
> an average of 6.5s load time (min : 5.49s, max : 7.55s)
> With non encrypted sessions, for 10 refreshes of the page, I measure
> an average of 5.9s load time (min : 4.87s, max : 7.13s)
>
> My conclusion from this small bench is that the performance hit from
> encrypting each cookie is not insignifiant. It can be measured and
> extracted.
>
> One suggestion could be the following : trying to get the cookie not
> to be recomputed by chunks of time, maybe recompute it every
> (SessionMaxAge/3) ; maybe expose a directive to manage this delay ?
>
>
> Additionnally, when setting SessionMaxAge to 0, the cookie expiry does
> not change anymore. But the Set-Cookie is still set with every
> request, which hints the server still computes the cookie encryption
> for each response generation.
>
> I'd like to read your ideas about these possible optimizations.
>
> Cheers,
>
> Vincent
>
Re: [2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance
Posted by Vincent Deffontaines <vi...@gryzor.com>.
Hi,
Thanks for pointing this option in trunk.
I did compile trunk and tried to use it with the option on my
application. It raised other problems that I cannot really isolate
(unexpected 500s with mod_wsgi which are absolutely off-topic).
So I applied the diffs from
http://svn.apache.org/viewvc?diff_format=h&view=revision&sortby=date&revision=1709121
into 2.4.39, and it does work like a charm : this patch fixes exactly
the problem that I was describing in this thread.
The patch applies without conflict.
Can this patch be considered for a backport into 2.4 ?
Thanks,
Vincent
Le 2019-05-10 17:23, Marion & Christophe JAILLET a écrit :
> Hi,
>
> have you checked the work in trunk related to
> "SessionExpiryUpdateInterval"? [1]
>
> If you have the opportunity to compile and test the trunk version and
> report if it corresponds to your use case, it would be great.
>
> If you want to have a look at the code itself, see [2].
>
> Just my 2c,---
> httpd/httpd/trunk/modules/session/mod_session_dbd.c 2015/10/16
> 22:27:47 1709120
+++ httpd/httpd/trunk/modules/session/mod_session_dbd.c 2015/10/16
22:36:17 1709121
@@ -245,6 +245,9 @@
/* put the session in the notes so we don't have to parse it again
*/
apr_table_setn(m->notes, note, (char *)zz);
+ /* don't cache pages with a session */
+ apr_table_addn(r->headers_out, "Cache-Control", "no-cache,
private");
+
return OK;
}
@@ -409,9 +412,6 @@
if (conf->name_set || conf->name2_set) {
char *oldkey = NULL, *newkey = NULL;
- /* don't cache pages with a session */
- apr_table_addn(r->headers_out, "Cache-Control", "no-cache");
-
/* if the session is new or changed, make a new session ID */
if (z->uuid) {
oldkey = apr_pcalloc(r->pool, APR_UUID_FORMATTED_LENGTH +
1);
@@ -458,7 +458,7 @@
else if (conf->peruser) {
/* don't cache pages with a session */
- apr_table_addn(r->headers_out, "Cache-Control", "no-cache");
+ apr_table_addn(r->headers_out, "Cache-Control", "no-cache,
private");
if (r->user) {
ret = dbd_save(r, r->user, r->user, z->encoded, z->expiry);
>
> CJ
>
> [1]:
> https://httpd.apache.org/docs/trunk/mod/mod_session.html#sessionexpiryupdateinterval
> [2]:
> http://svn.apache.org/viewvc?diff_format=h&view=revision&sortby=date&revision=1709121
>
> Le 10/05/2019 à 12:26, Vincent Deffontaines a écrit :
>> Greetings,
>>
>> The root observation that makes me open this subject is the following
>> :
>> Using mod_auth_form + encrypted cookies to manage a web application
>> authentication gets httpd's auth cookie to be reset by the server at
>> each and every authenticated request. On a website with a number of
>> users x a number of requests, this gets quite a number of HMAC crypto
>> cookie cyphering operations, which I guess could be reduced.
>>
>> In order to debug this, I started running the attached configuration
>> (it's pretty much just the most reduced setup to use the module
>> combination, nothing fancy).
>> This setup does not enforce cookie encryption. When cookie are
>> encrypted, I obviously just can notice they differ from a request to
>> another. When they are not encrypted, I understand why.
>>
>> Here are a few successive (ordered) cookies sent by the server with
>> this configuration, including the dummy login and password I'm using
>> for illustrating this matter :
>>
>> Set-Cookie:
>> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>>
>> Set-Cookie:
>> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>>
>> Set-Cookie:
>> DMS-tags-session=DMS-TAG+-+File+Auth-user=login&DMS-TAG+-+File+Auth-pw=pass&expiry=1557494870865331;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
>>
>> The most interesting part is that, no matter how close in time these
>> requests can be, the "expiry=%ld" part will change, because it is an
>> epoch timestamp with a precision up to the microsecond.
>>
>> I guess nothing here is wrong, regarding RFC2109. But it appeared odd
>> to me, as opposed to the way most web sessions are dealt with : while
>> our cookie lifetime definetely matches the MaxAge produced in
>> configuration, it is nevertheless reset by the server at each request.
>>
>> This is of no performance consequence in this debug setup, but I
>> believe the load can be affected as soon as one sets a
>> SessionCryptoPassphrase ).
>>
>> For what it's worth, I have benched the difference on my (non-summy)
>> application, by reloading the main page (which implies quite some
>> applicative processing on the server, too, and loads 119 hits to
>> generate the page).
>> When sessions are encrypted, for 10 refreshes of the page, I measure
>> an average of 6.5s load time (min : 5.49s, max : 7.55s)
>> With non encrypted sessions, for 10 refreshes of the page, I measure
>> an average of 5.9s load time (min : 4.87s, max : 7.13s)
>>
>> My conclusion from this small bench is that the performance hit from
>> encrypting each cookie is not insignifiant. It can be measured and
>> extracted.
>>
>> One suggestion could be the following : trying to get the cookie not
>> to be recomputed by chunks of time, maybe recompute it every
>> (SessionMaxAge/3) ; maybe expose a directive to manage this delay ?
>>
>>
>> Additionnally, when setting SessionMaxAge to 0, the cookie expiry does
>> not change anymore. But the Set-Cookie is still set with every
>> request, which hints the server still computes the cookie encryption
>> for each response generation.
>>
>> I'd like to read your ideas about these possible optimizations.
>>
>> Cheers,
>>
>> Vincent
>>
--
What is it you need, that makes your heart beat ?
Do you really know, cause it doesn't show.
New Order - Round & round