Re: [2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance
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=revision=date=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=revision=date=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+-+File+Auth-pw=pass=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
Set-Cookie:
DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1
Set-Cookie:
DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=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
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=revision=date=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+-+File+Auth-pw=pass=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1 Set-Cookie: DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1 Set-Cookie: DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=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
[2.4.39] [mod_auth_form] [mod_session_crypto] Cookie management performance
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+-+File+Auth-pw=pass=1557494869445278;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1 Set-Cookie: DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=1557494870169716;Max-Age=14400;path=/vincent;HttpOnly;Secure;Version=1 Set-Cookie: DMS-tags-session=DMS-TAG+-+File+Auth-user=login+-+File+Auth-pw=pass=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 Require all granted SetHandler form-login-handler AuthFormLoginRequiredLocation "https://cfe-dms-qualif.mydomain.com/vincent/login.html; AuthFormLoginSuccessLocation "https://cfe-dms-qualif.mydomain.com/vincent/index.html; AuthFormProvider file AuthType form Session On SessionMaxAge 14400 SessionCookieName DMS-tags-session path=/vincent;HttpOnly;Secure;Version=1 AuthUserFile /usr/local/apache2/passwd AuthName "DMS-TAG - File Auth" Require valid-user Require all granted SetHandler form-logout-handler AuthFormLogoutLocation "https://cfe-dms-qualif.mydomain.com/vincent/logout.html; Session On SessionMaxAge 1 SessionCookieName DMS-tags-session path=/vincent;HttpOnly;Secure;Version=1 AuthType form AuthFormProvider file AuthFormLoginRequiredLocation "https://cfe-dms-qualif.mydomain.com/vincent/dologout; Session On SessionMaxAge 14400 SessionCookieName DMS-tags-session path=/vincent;HttpOnly;Secure;Version=1 AuthName "DMS-TAG - File Auth" AuthUserFile /usr/local/apache2/passwd Satisfy all Require valid-user Require all denied Require all granted
