[pmwiki-users] Performance problems with passwords

Petko Yotov 5ko at 5ko.fr
Fri Oct 21 03:15:26 CDT 2016

I have made a change in subversion that will allow you to skip the 
checking for the "nopass" password with the next version.

To test it, get the latest pmwiki.php from the subversion repository or 
from the zip export:


then replace the current one on your server.

In your config.php, add this line:

   $AllowPassword = false;

Then run curl and check the numbers.

If I understand correctly, one could set to 'nopass' 
$DefaultPasswords['admin'] or $DefaultPasswords['upload'] to allow 
anyone to edit everywhere or to upload. But this is probably unneeded on 
the vast majority of the websites running on PmWiki.

For stats close to the real life usage, you might enable cookies in 
curl, like most real users will have cookies allowed. The session data 
for authentication is stored, and the key is send to a browser cookie.

You can enable if-modified-since browser caching for browsers that have 
already visited the same page, set in config.php something like:

   $EnableIMSCaching = 1;

Moreover, you can enable various caching features, search the 
documentation for $PageCacheDir and $PageListCacheDir.

If you require super-fast response times for first-time visitors or 
readers, and do not set read passwords, check the recipe FastCache:



Change log     :  http://www.pmwiki.org/wiki/PmWiki/ChangeLog
Release notes  :  http://www.pmwiki.org/wiki/PmWiki/ReleaseNotes
If you upgrade :  http://www.pmwiki.org/wiki/PmWiki/Upgrades

On 2016-10-20 00:51, Tyler Spivey wrote:
> Hi,
> I'm trying to understand how I can speed up PMWiki.
> I found an easily-reproduceable test case involving passwords. Using
> one slows down my page quite a bit, even in the most common case,
> someone reading the wiki without authenticating.
> First, I extracted pmwiki and copied the sample config to config.php.
> Then I ran
> php -S 0:8001
> To start the development server.
> Then:
> curl localhost:8001/pmwiki.php
> We can ignore the first one, I think it's just a redirect while PmWiki
> sets up wiki.d.
> time curl -s localhost:8001/pmwiki.php >/dev/null
> Running that 3 times, we get around 58ms. Not too bad.
> Now I want an admin and edit password:
> $DefaultPasswords['admin'] = pmcrypt('secret');
> $DefaultPasswords['edit'] = pmcrypt('secret');
> With this, the lowest I've seen my page go is 405ms. Understandable,
> since I'm calling pmcrypt() for each page load.
> password_hash() and thus pmcrypt() is expensive. We can reduce this
> slightly by pre-encrypting them, which I did, and edited the relevant
> lines to precompute pmcrypt('secret').
> Encrypted password =
> $2y$10$3fQco9ikY9t5EEGPizr5jeHOmpnr0H5QtOkLSABZRSK1jD3.m01Wi
> Even with that, the best I can get is 223ms, far from the 58 I 
> originally had.
> It's trying to compare "nopass" with both of my encrypted passwords,
> adding 80 or so ms per call.
> Can anything be done to optimize this?
> PHP Version => 7.0.8-0ubuntu0.16.04.3
> Operating system: Ubuntu 16.04.1

More information about the pmwiki-users mailing list