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
