Understand that before Zenphoto can know what is being loaded it needs to do some processing. So, therefore, it does load class plugins and will need to instantiate albums (for instance) before knowing what cached page to use.
These queries are unavoidable.
We of course cannot know what your theme obvious might also be doing. But if, as acrylian notes, it is making references after the page load (lazy processing) then those references are not cached and will be repeated each time.
If you cannot change your theme and your server is having trouble with the traffic then you will need to get a higher capacity server.
Thanks sbillard!
About the lazy processing, the js call to lazy load was there by mistake. I don't use it. As I said, I haven't modified any core structure from the default plugin (that I used to customise the obvious template).
I understand that some core call should be made to the MySQL. My point is to try to understand if those kinds of queries - dozens every second - are a normal behaviour for a full cached page.
In optimal conditions, the kind of queries you see in my log are normal? For instance, if the index.html (homepage) is fully cached, there will be queries going on to the mysql?
The option of showing "random images", in theory, increase the query rate to the DB?
I'm not having problems with my server... I'm just curious about the large amount of queries and try to understand if there are any way to avoid them.
Thanks for your patience!
If you have dozens of requests for pages a second then you should expect dozens of queries to support that. It is really not possible to answer your questions with the information we currently have been provided.
Does the site behave differently if you use the stock default theme? Be sure that when you are observing your are [b]NOT[/b] logged in since there is no caching of pages requested by the administrator.
Look also at your server access logs. What is the request rate there for pages?
And, finally, if you are not having problems with your server what is the issue? SQL processing time is small relative to HTML rendering time. The HTML cache is (as maybe the name implies) intended to reduce the processing for HTML rendering. SQL queries should be a concern only if they are overloading your SQL server or limiting your site throughput.
Hello sbillard,
Thanks for your patience and reply. one of the main problems was my interpretation of cache. In my mind, a burned cache on a filesystem doesn't need of sql activity. I realize now that are much more things going on through ZP core.
For the record, after entering the ttl cache value in static_html_cache that was empty, and setting the thumbnails not to random, seems to helped a lot in decreasing the amount of sql activity.
The fact that my gallery instance is getting substantially more access, and the fact that i'm seduced by the simplicity of ZP, motivated me to proactively try to understand some behaviours in the core and pay more attention to that.
Now I'm having other weird problems that I'll describe in another topic, so we can close this one
thanks once more
THe html cache of course is meant to reduce server and db load but still as sbillard explained ZP needs to do some to know what is cached and if what to get. The only way to avoid that is to use a plain static html website as in the old days.
You might also look at server side cache settings, most server have something like Xcache, eAccelerator or the like. Those even might be running as your site seems quite fast to me. Maybe ask your host if you are concerned.
Hi Guys,
As I said, I'm pretty happy with the ZP performance. To be honest, being an ex-php-gallery user, I'm amazed by the simplicity and performance.
Just to share with you a bit more information... yesterday I have another usage peak with a viral effect on facebook and hundreds of simultaneous accesses. Check the graphs below on my dedicated server to ZP:
BW: http://galeria.obviousmag.org/tmp/bw.png
CONNs: http://galeria.obviousmag.org/tmp/con.png
SQL: http://galeria.obviousmag.org/tmp/sql.png
As you can see in the SQL graph, yesterday 12h, I've implemented the following tweaks:
- cached the queries on the sql server (is was turned off, shame on me);
- changed all albums to show the last thumb and not a random one;
- inserted a ttl value in the static_html_cache plugin;
besides that, even with the traffic peak showed above, ZP performed great
Following your recommendation, I've downloaded a fresh copy of ZP 1.4.5.7. Using the default theme and functions, I've implemented a new markup for my layout, making sure that I'm not using old methods. I'm going to put it in production next weekend.
Thanks