Hello,

I have a Zenphoto website at www.france-in-photos.com with about 2000 images (700 unpublished), 177 albums and a number of tags.
It is hosted on a VPS server (CentOS 6.5/Plesk 12) under Nginx and Apache.
The server has 2 Vcore and a total of 2 Gb of Ram
There is a total of 7 websites hosted on it, but none of them has significant trafic.

Memory and processor use for the last month.
http://www.france-in-photos.com/processor-ram-use.png

I recently realized that my Zenphoto site was slow to load, mainly because of a high time to first byte.
I have tested it with WebPageTest using a server close to my home.

My Zenphoto site homepage has a time to first byte of 3 seconds
Testing an html page on the website gives a time to first byte of 200 milliseconds

I have tried to remove some of the features on my theme (such as the tag cloud), refresh the database, raised the PHP memory limit to 512 Mb. None of these get the time to first byte under 2 seconds.

How can I improve performance?

Hard to tell exactly. Do you use the html_static_cache plugin? What slows down mostly is the image generation but that of course only on the first visit (unless you have setup your theme to use the cacheManager plugin to precache all possible sizes).

The front pages seems indeed a bit slow. According to Safari the slowest parts are external scripts and font loading: http://zenphoto.maltem.de/test3/scripts.jpg.html

Also the boostrap.css is 120k big. One drawback of such complete frameworks that it carries a lot stuff you probably don't need.

Yes, I do use the static_html_cache plugin.
I also tried to precalculate image caches thanks to the cache manager, but will investigate if it worked properly with my custom theme.

The bootstrap CSS does take a while to load. Gzip is not enabled on my server and it may speed up things for this kind of file.

Here is a waterfall view of a test I just did with WebPageTest. The time to first byte is rather extreme at 10s. I generally get 3s.
http://www.france-in-photos.com/waterfall.png

You can see that the major delay is due to calculations that take place BEFORE the page starts to render.

My question is about the calculations that take place at that time: tag cloud, latest images and menus (on the homepage). How does a large number of images and tags increase this? And is my server large enough to handle this?

I wondered if the server had been hacked and was being used to calculate other things, but did not find anything. I stopped the email service, just in case. I stopped some of the smaller websites running on it, but it did not change anything.

I would be interested to see examples of other websites running Zenphoto to see how they fare on that respect.

If you use big images (high resolutions) as originals the image generation may of course eat up your RAM. That is noted here: http://www.zenphoto.org/news/problems-with-albums-and-images

We of course cannot tell about your custom theme or your server. But note if you don't run your own self managed server raising the memory limit may be reported false. On shared host you are most certainly not allowed to do that at all.

Of course the more you have of albums/images the more work needs to be done to do things. Tags are in their own tables and if counted those are used.

You find other sites on our showcase for example but of course there are a lot of old installs there.
Since it is mostly the front page try to disable the image_album_statistics plugin to see if that makes any difference.

To compare here are the stats of our own site:
932 images (185 un-published)
109 albums (40 un-published)
187 Pages (1 un-published)
569 News articles (6 un-published)
36 Categories
Albums folder size: 141.02 mB
Image cache size: 322.57 mB

Memory limit is 192 MB but note that we run our own costly server. And we don't use the html cache currently.

Edit: Please check that the static_html_cache plugin is really working correctly, e.g. that cache files are created in /cache_html/ at all. Your source code should have a line like `<!-- Cached content of Thu, 18 Dec 2014 11:24:20 served by static_html_cache in 0.0012 seconds plus 0.3424 seconds unavoidable Zenphoto overhead. -->` if it is working but it haven't. That could be a permissions issue and such can slow down naturally. Review your server error logs.

You also have a JS error from a script that might be add up, too.

Thanks for all those hints.

I use rather small images (650 px wide), so I don't think it is the problem.

A friend of mine is checking the VPS as the issue is probably there. Performance dropped noticeably on the 15th of December without any important change on the website.

Ok, let us know if you find anything out.

After a series of changes, we have been able to reduce the time to first byte significantly.

We started with a TTFB of 3s
- removed the dual Nginx/Apache setup of Plesk
- Changed PHP execution in Plesk from FastCGI to Apache module
- other server settings including Linux updates

This brought us to under 2s of TTFB

- Stopped useless services that are automatically started by Plesk (SMTP)
- erased about 160000 session files written in zp-data/PHP_Sessions
- changed Plesk settings that prevented Zenphoto to write session data outside of the install directory
- We then stopped 2 of the 8 websites running on the server
- I removed about 15 unpublished directories and 500 unpublished images

The TTFB is now under 1 second.

It would be nice to bring it to 0,5s, but I think I would either have to change the design (by removing calculation heavy modules such as the tag cloud) or double the VPS memory.

There is very little traffic right now, so it may degrade again with a higher traffic.

The first page now shows `<!-- Zenphoto script processing end:0.9517 seconds -->` which is quite good I think. I still wonder if the static_html_cache is working correctly on your site as if it should be listed there as well (I see the plugin is active).

Of course both the tag cloud and the latest images do some stuff to actually be able to display what they do. The latest images stuff does do some check so it does not display things from unpublished or protected albums (the tag could in 1.4.6 does not).

I think the cache works as the cache_html directory has files in it.

I guess the next step to get better performance would be to upgrade the server.
I'll see if it needs it in the future, when traffic starts again after the holidays.

Ok, good. We can of course not exclude that there might be room for improvement in some places. We gladly try to solve such if pointed to and if possible. But at some point a server upgrade could be the best choice.