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