0

In certain conditions, a CMS brings my server on its knees (0% CPU left while the server load is never above 20% usually, officially from mysqld, tons of wait and tml in mysql, mysql's slow log exploding with tmp allocations, etc). This is a well-known case for this CMS, based on the combination of these events :

  • hundreds of visitors browsing the site at the same time
  • database counting hundreds of thousands of items
  • php wrapper : SuPHP (fcgid)

The discussion forums of this CMS (called Piwigo) know of the issue, but the only answer that is given is "switch to NginX with Php-fpm". Let's multiply by 100 the number of images and of visitors, if it's NginX instead of Apache+SuPHP, the issue is still absent.

Problem is, I can't switch a whole server to NginX with a snap of my fingers, it's not just about my own websites and - no shame in admitting it - I have no competences yet with NginX. I must keep production websites online, up and running, so my server must stay using Apache.

With that in mind, please, do you see a way out of this issue ? Some way of "cheating" and allowing suPHP to rock again in this precise situation ? If it's at the cost of swallowing 10+ GB of RAM, hey, sure, why not, my server uses only a third of its 32 GB of RAM, and even with the rest for caching the disk usage is calm. If it's at the cost of doubling the CPU charge, haha, once again, sure, that would be OK.

If you have suggestions, I'm all ears, really !

Details about my server : Debian Wheezy, Apache2, PHP Version 5.4.4-14+deb7u14, Php running as SuPHP (fcgid), Mysql 5.5.38 and, honestly, a monstruously powerful dedicated server, AMD Opteron 4334, 32 GB fast RAM, two SSDs Raid-1 disks for / and two Raid-1 Sata disks for /home. Panel : webmin + virtualmin. The panel allows to switch a virtual domain ( = 1 website, with its own user) to Php-CGI or Mod-PHP. Mysql configuration is non-guilty (countless mysql-tuner, tuning-primer), already gradually configured to allow sucking up tons of RAM and caching as if there were no tomorrow.

If you have suggestions for a solution that won't need NginX, I'll be most grateful ! :)

EcchiOli
  • 1
  • 1
  • 2
    Exactly where is the bottleneck and how did you determine this? – Michael Hampton Oct 11 '14 at 23:49
  • mysql-tuner can tune your *config* but there are plenty of other pitfalls that it won't find. Do you have a slow query log? Does it log queries not using indexes? I suspect the database is where your problem lies but you should still measure this and not rely on guesses. – Ladadadada Oct 12 '14 at 06:00
  • To answer : a Piwigo dev has publicly commented, every time they could work on third party servers with the combination of huge traffic, thousands of images registered (not stored, their characteristics registered) in DB, and Apache+SuPHP, the server was slow and getting on its knees (zero CPU free) when you did anything additional (like uploading). And then, TADAA MAGIC, installing NginX+FPM brought the server charge back to practically nothing. – EcchiOli Oct 13 '14 at 05:43
  • Forgetting : of course there are indexes, done well, and the DB's fine. First things to check ;) Really, it's a situation where all configs with the same shared chars have the issue and it entirely disappeared with the move to Nginx+FPM. – EcchiOli Oct 13 '14 at 06:09

1 Answers1

0

Do a google search for piwigo crashes and you'll get several results like: http://piwigo.org/forum/viewtopic.php?id=24748 http://piwigo.org/forum/viewtopic.php?id=22348

So unfortunately you are not alone with these performance problems with piwigo. It seems that piwigo has some great things going for it but performance/robustness maybe is not one of them, at least not yet? I am contemplating testing out zen photo, coppermine, and others etc because it seems piwigo isn't optimized for either big photos or lots of users viewing or uploading photos. Perhaps the developers know of this issue and maybe this is why there is no feature to let users upload images, except through some secondary "plugin" called the community plugin. But without this plugin only the administrator can upload photos. Obviously many sites will want users to be able to upload images so its strange for them not to offer this feature 'built-in' to the core of piwigo, unless maybe they know of the performance problems and that it wouldn't be able to handle such usage.

So my answer to your question is sadly that piwigo is not a good choice for what you are tying to use it for, seems its not ready yet for sites with tons of users/views or lots of image uploads and since most galleries all use GD or image magick, they might all suffer from the same issue when it comes to that unless somehow its implemented differently to avoid server overload.

If anyone has found a good piwigo replacement that has similar features but better performance I'd like to know, I plan on doing some research/testing towards that goal when I have some time.

htfree
  • 463
  • 4
  • 9
  • 21