I’d been running piwik 1.5.1 for a while, only tracking one site, and tried upgrading to 1.6. After upgrading, it was glacially slow, so I downgraded again. Not discouraged, I set up a parallel, empty installation of 1.6 on my server, pointing to a different DB on the same DB server. Also glacially slow. I also set up a third parallel installation of 1.7b - also glacially slow.
The “slowness” is in loading any page of the site - for example, the dashboard. Every query result takes forever to load, even though every query is empty. 1.5.1, running on the same servers, though it has a little data, is snappy. There are no Apache errors.
So:
My 1.6 and 1.7 instances are empty, but running the queries is still abysmally slow.
The 1.5.1 instance is not caching its data, but rather running live queries.
All three instances have the same permissions set.
No errors in the Apache logs
MySQL 5, running on a separate server. Same server for all 3 instances.
Has anyone else seen this sudden performance drop from 1.5.1 to 1.6? Is there some php setting or something we need to do?
It is possible I did something funky with the 1.5.1 setup that made it especially speedy, but I think in fact the only difference among these sites is the codebase.
What’s your web host? there are specific webhosts that have issue such as OVH.
It would most likely be a php config or another obscure setting… Very hard to say.
If you are techical I would recommend to profile the code using xdebug. Otherwise not sure what could cause the problem? Maybe try to setup DB based sessions? Installation - Analytics Platform - Matomo
I am hosting on a server I run. I can try db-based sessions. I can try xdebug. I can report back with these results, though I’m hoping other people will still chime in with ideas.
I feel like the problem must hinge on some difference between 1.5.1 and later versions, so I was hoping something would occur to someone who was more familiar with the changes. To be doubly sure, I installed a parallel instance of 1.5.1 with blank config next to the existing 1.5.1 instance, the 1.6 instance, and the 1.7b9 instance - yes, 1.5.1 is still fast.
OK, so like the OVH users, switching from file-based sessions to db-based sessions fixed the speed issue in both 1.6 and 1.7b9. Is this is change from 1.5.1 to 1.6, though? Do you have any insight on what could make it so much slower?
The host I’m running piwik on is a VM, and piwik’s application data is stored on a NFS-mounted NetApp, so I/O is a little slow, but not terrible - r/w speed is consistently about 100 MB/s. But I don’t know what wacky php things might affect this.
Hey Matt, the obvious change that jumps out at me from the 1.6 changelog is “#2602 Piwik_Session: restore support for file-based sessions” - so for whatever reason, file-based sessions are slow in some cases. Do you know if the file-based sessions use flock or other file-locking? I know from other contexts that file locking may be slow/fraught/etc on NFS-mounted storage.
OK, thanks for confirming vipsoft. I think this might be worth adding explicitly to the release notes, and/or to upgrade and installation documentation. There is already a link on the release notes to “how to switch to db sessions”, but it’s not obvious why you would need/want to.
I would also argue that it might make more sense to keep DB-sessions the default, since when they’re the bottleneck, people get obvious errors - the max mysql connection errors are caught by php and show up in the apache error log most of the time, right? But the file-based session management issue is just silently and mysteriously slow. I think in a commercial hosting environment, it may not even be obvious to a user when their storage is NFS-mounted as opposed to “local”, so it would be doubly difficult for them to troubleshoot this sort of problem.
Basically, if most users are fine with either file- or DB-based sessions, but a minority need file and a minority need DB, I’d argue that the default should be the one that is noisily/obviously problematic.
The flip side of the argument is that the web server+php has already been configured and tuned to mitigate such problems.
Fyi Dbtable sessions was the default for a time. However, we have overwhelming emperical evidence that strongly supports having file-based sessions as the default.
Hey vipsoft, thanks for your reply. I think the most important thing is just making it more obvious, even if it’s in documentation only, that NFS-mounted storage causes this massive slowdown. One of the FAQs is about piwik slowness, for instance - it could include a new paragraph that in versions 1.6 and later you may want to try DB sessions instead, particularly if you’re using NFS-mounted storage.
I don’t understand your first paragraph: “the flip side… is that the web server has already been configured… to mitigate such problems”? Do you mean “could have been” or “should be”? (Agreed, but it has to be clear what the necessary configurations are.) Or are you referring to OVH specifically? As noted, I’m not on OVH; I think there are a lot of people who may be running off shared storage for a variety of reasons, and this slowness issue was totally opaque at first even to an experienced and knowledgeable person like Matt, who responded above.
Hey Matt, that’s awesome, thanks. It looks like the update is not published out to the public site yet - I’m still just seeing the old two paragraphs on “auto archiving” and “high traffic websites” even after refreshing, etc.