2 months have passed since the last minor update on Piwigo 15. Here comes version 15.4.0 and it contains bug fixes and improvements. Small sample:
* the page of the photo was never indexed by search engines with theme Bootstrap Darkroom
* incorrect checksum was assigned to synchronized photos
* huge speed improvement for many photos/albums + frequent user_cache reset + many simultaneous anonymous visitors
* improved colors in administration dark mode
Background image by Monstera Production on Pexels
Piwigo 15.4.0 release note
Offline
Awesome! Thanks!
Offline
I really like the speed increase!!
Offline
I choose a layout with automatic sorting of photos in the album. However, it does not automatically sort as the photos are uploaded. I have to go into the album and adjust it manually. When will this be resolved?
Offline
Thanks for the update! Works well, and it is indeed faster! :-)
Offline
Great. Thank you!
Offline
Radjin wrote:
It does seem much faster, especially when dragging a pile of photos into the upload box.
This is quite unexpected. The speed improvement is really when you add photos one by one (triggering a user cache reset on each added photo) + many simultaneous visitors.
Other than that, I would really like to know where 15.4.0 is faster than 15.3.0
Offline
Exellent update.
The load on the server database is greatly reduced!
Ubuntu 24.04.2 LTS (GNU/Linux 6.8.0-53-generic x86_64)
10.11.8-MariaDB-0ubuntu0.24.04.1
Congratulations!
Last edited by mfgpi (2025-02-25 00:24:21)
Offline
I'm very happy so many of you feel the reduced load (or speed increase). I didn't expect it would impact many installations because it should be only when you "user cache" is reset often + user cache is long to rebuild + many simultaneous users try to rebuild the cache at the same time.
So I'm curious. For those who feel the difference with Piwigo 15.4.0, do you have many anonymous visitors? Do you often reset user cache (uploading a single photo resets this cache) ? Do you see this kind of lines in your _data/logs/*.txt (when you search "user_cache"):
[2025-02-24 19:28:30] [INFO] [getuserdata][exec_code=fd7a][user_id=6] needs user_cache to be rebuilt
[2025-02-24 19:28:30] [INFO] [generate_user_cache-u6][exec=99c1ac37] starts now
[2025-02-24 19:28:30] [INFO] [generate_user_cache-u6][exec=99c1ac37] wins the race and gets the token!
[2025-02-24 19:28:30] [INFO] [getuserdata][exec_code=b708][user_id=6] needs user_cache to be rebuilt
[2025-02-24 19:28:30] [INFO] [generate_user_cache-u6][exec=52f5bf6d] starts now
[2025-02-24 19:28:30] [INFO] [generate_user_cache-u6][exec=52f5bf6d] skip
[2025-02-24 19:28:30] [INFO] [getuserdata][exec_code=b708][user_id=6] starts to wait for another request to build user_cache
[2025-02-24 19:28:30] [INFO] [getuserdata][exec_code=fd7a][user_id=6] user_cache generated, executed in 0.284 s
[2025-02-24 19:28:31] [INFO] [getuserdata][exec_code=b708][user_id=6] user_cache generation waiting k=0 user_cache rebuilt, after waiting 1.000 s
Here you see 2 simultaneous execs (fd7a and b708) that requires user_cache to be rebuilt for user #6. fd7a arrives first and "wins the race" to get the flag/token for rebuilding. The other one, b708, does nothing but wait for the other one to finish.
In this case, Piwigo has avoided to compute the user_cache twice at the same time. It's a small improvement. Sometimes if you have many visitors, you have 100 simultaneous requests and in Piwigo 15.3.0 it was overloading the server CPU, because building the cache is a CPU intensive task. Now in Piwigo 15.4.0, only one will build the cache and other requests will wait for the compute to be done.
So I'm curious to know if many people are in this situation.
Offline
plg wrote:
So I'm curious. For those who feel the difference with Piwigo 15.4.0, do you have many anonymous visitors? Do you often reset user cache (uploading a single photo resets this cache) ? Do you see this kind of lines in your _data/logs/*.txt (when you search "user_cache"):
I found this only once for the last month and it was happened just after upgrade to 15.4.0
[2025-02-23 18:24:40] [INFO] [getuserdata][exec_code=de57][user_id=2] needs user_cache to be rebuilt
[2025-02-23 18:24:40] [INFO] [generate_user_cache-u2][exec=d7d0b9f2] starts now
[2025-02-23 18:24:41] [INFO] [generate_user_cache-u2][exec=d7d0b9f2] wins the race and gets the token!
[2025-02-23 18:24:41] [INFO] [getuserdata][exec_code=c8b7][user_id=2] needs user_cache to be rebuilt
[2025-02-23 18:24:41] [INFO] [generate_user_cache-u2][exec=b20a9ad6] starts now
[2025-02-23 18:24:41] [INFO] [generate_user_cache-u2][exec=b20a9ad6] skip
[2025-02-23 18:24:41] [INFO] [getuserdata][exec_code=c8b7][user_id=2] starts to wait for another request to build user_cache
[2025-02-23 18:24:41] [INFO] [getuserdata][exec_code=cf36][user_id=2] needs user_cache to be rebuilt
[2025-02-23 18:24:41] [INFO] [generate_user_cache-u2][exec=53b261d7] starts now
[2025-02-23 18:24:41] [INFO] [generate_user_cache-u2][exec=53b261d7] skip
[2025-02-23 18:24:41] [INFO] [getuserdata][exec_code=cf36][user_id=2] starts to wait for another request to build user_cache
[2025-02-23 18:24:42] [INFO] [getuserdata][exec_code=c8b7][user_id=2] user_cache generation waiting k=0 user_cache rebuilt, after waiting 1.000 s
[2025-02-23 18:24:42] [INFO] [getuserdata][exec_code=de57][user_id=2] user_cache generated, executed in 1.561 s
[2025-02-23 18:24:42] [INFO] [getuserdata][exec_code=cf36][user_id=2] user_cache generation waiting k=0 user_cache rebuilt, after waiting 1.078 s
[2025-02-23 18:25:55] [INFO] [getuserdata][exec_code=3c74][user_id=1] needs user_cache to be rebuilt
[2025-02-23 18:25:55] [INFO] [generate_user_cache-u1][exec=d5824388] starts now
[2025-02-23 18:25:55] [INFO] [generate_user_cache-u1][exec=d5824388] wins the race and gets the token!
[2025-02-23 18:25:57] [INFO] [getuserdata][exec_code=3c74][user_id=1] user_cache generated, executed in 1.558 s
Offline
@abravorus so what I learn from your log file
* the user_cache gets generated in 1.5 seconds. That's already quite big (unless you have 100k photos)
* the new algorithm in Piwigo 15.4.0 has avoided 2 concurrent rebuilt of the user_cache
Offline
plg wrote:
@abravorus so what I learn from your log file
* the user_cache gets generated in 1.5 seconds. That's already quite big (unless you have 100k photos)
* the new algorithm in Piwigo 15.4.0 has avoided 2 concurrent rebuilt of the user_cache
Yes, we have 120k photos and about 4k albums in the gallery. And sometimes we have a very big load on MySQL database because of search (or may be not only search, AI?) bots. Recently we had to completely close access to Piwigo for bots via robots.txt because the server just went down because of bots' activities.
We have no opportunity to use dedicated server for the database only, so we are very interested in any improvements in the server load. Thank you very much for these efforts.
Gallery: https://terijoki.spb.ru/photos/
Offline
abravorus wrote:
sometimes we have a very big load on MySQL database because of search (or may be not only search, AI?) bots. Recently we had to completely close access to Piwigo for bots via robots.txt because the server just went down because of bots' activities.
I can understand very much. On Piwigo.com we have rules to completely block robots of all kinds (search engines, AI harvester, spammers, marketing tools). Robots represent between 80 and 95% of web traffic for us. That's huge and that's a problem. We have built applications for humans, not for robots.
Offline
Thank you! :-)
Also for me it started logging it after the 15.4 upgrade. I assume part of the fix.
[2025-03-03 11:02:36] [INFO] [getuserdata][exec_code=7db6][user_id=2] needs user_cache to be rebuilt
[2025-03-03 11:02:36] [INFO] [generate_user_cache-u2][exec=3c70983c] starts now
[2025-03-03 11:02:36] [INFO] [generate_user_cache-u2][exec=3c70983c] wins the race and gets the token!
[2025-03-03 11:02:36] [INFO] [getuserdata][exec_code=9532][user_id=2] needs user_cache to be rebuilt
[2025-03-03 11:02:36] [INFO] [generate_user_cache-u2][exec=e2da1718] starts now
[2025-03-03 11:02:36] [INFO] [generate_user_cache-u2][exec=e2da1718] skip
[2025-03-03 11:02:36] [INFO] [getuserdata][exec_code=9532][user_id=2] starts to wait for another request to build user_cache
[2025-03-03 11:02:37] [INFO] [getuserdata][exec_code=df8d][user_id=2] needs user_cache to be rebuilt
[2025-03-03 11:02:37] [INFO] [generate_user_cache-u2][exec=9326317e] starts now
[2025-03-03 11:02:37] [INFO] [generate_user_cache-u2][exec=9326317e] skip
[2025-03-03 11:02:37] [INFO] [getuserdata][exec_code=df8d][user_id=2] starts to wait for another request to build user_cache
[2025-03-03 11:02:37] [INFO] [getuserdata][exec_code=9532][user_id=2] user_cache generation waiting k=0 user_cache not ready yet, after waiting 1.000 s
[2025-03-03 11:02:38] [INFO] [getuserdata][exec_code=df8d][user_id=2] user_cache generation waiting k=0 user_cache not ready yet, after waiting 1.000 s
[2025-03-03 11:02:38] [INFO] [getuserdata][exec_code=9532][user_id=2] user_cache generation waiting k=1 user_cache not ready yet, after waiting 2.001 s
[2025-03-03 11:02:39] [INFO] [getuserdata][exec_code=4279][user_id=2] needs user_cache to be rebuilt
[2025-03-03 11:02:39] [INFO] [generate_user_cache-u2][exec=2e9d75aa] starts now
[2025-03-03 11:02:39] [INFO] [generate_user_cache-u2][exec=2e9d75aa] skip
[2025-03-03 11:02:39] [INFO] [getuserdata][exec_code=4279][user_id=2] starts to wait for another request to build user_cache
[2025-03-03 11:02:39] [INFO] [getuserdata][exec_code=df8d][user_id=2] user_cache generation waiting k=1 user_cache not ready yet, after waiting 2.001 s
[2025-03-03 11:02:39] [INFO] [getuserdata][exec_code=9532][user_id=2] user_cache generation waiting k=2 user_cache not ready yet, after waiting 3.001 s
[2025-03-03 11:02:40] [INFO] [getuserdata][exec_code=84cb][user_id=2] needs user_cache to be rebuilt
[2025-03-03 11:02:40] [INFO] [generate_user_cache-u2][exec=7e2d3288] starts now
[2025-03-03 11:02:40] [INFO] [generate_user_cache-u2][exec=7e2d3288] skip
[2025-03-03 11:02:40] [INFO] [getuserdata][exec_code=84cb][user_id=2] starts to wait for another request to build user_cache
[2025-03-03 11:02:40] [INFO] [getuserdata][exec_code=4279][user_id=2] user_cache generation waiting k=0 user_cache not ready yet, after waiting 1.000 s
[2025-03-03 11:02:40] [INFO] [getuserdata][exec_code=df8d][user_id=2] user_cache generation waiting k=2 user_cache rebuilt, after waiting 3.001 s
[2025-03-03 11:02:40] [INFO] [getuserdata][exec_code=9532][user_id=2] user_cache generation waiting k=3 user_cache rebuilt, after waiting 4.001 s
[2025-03-03 11:02:41] [INFO] [getuserdata][exec_code=84cb][user_id=2] user_cache generation waiting k=0 user_cache rebuilt, after waiting 1.000 s
[2025-03-03 11:02:41] [INFO] [getuserdata][exec_code=4279][user_id=2] user_cache generation waiting k=1 user_cache rebuilt, after waiting 2.001 s
[2025-03-03 11:02:42] [INFO] [getuserdata][exec_code=7db6][user_id=2] user_cache generated, executed in 5.258 s
[2025-03-03 11:02:42] [INFO] [getuserdata][exec_code=eb6c][user_id=51] needs user_cache to be rebuilt
[2025-03-03 11:02:42] [INFO] [generate_user_cache-u51][exec=ce57cd0c] starts now
[2025-03-03 11:02:42] [INFO] [generate_user_cache-u51][exec=ce57cd0c] wins the race and gets the token!
[2025-03-03 11:02:47] [INFO] [getuserdata][exec_code=eb6c][user_id=51] user_cache generated, executed in 4.447 s
Over 300k photos. 8.5k albums. We only have "admin" users and all site visitors are not-logged-in anonymous users.
And nowadays some bots seem to ignore robots.txt sadly.
(KHTML, like
Gecko) Chrome/78.0.3904.97 Safari/537.36 (+https://www.loc.gov/programs/web-archiving/for-site-owners/)
So looking this site: https://www.loc.gov/programs/web-archiv … te-owners/
quote: "Our crawler is instructed to bypass robots.txt External in order to obtain the most complete and accurate representation of websites."
Last edited by deemon (2025-03-03 10:36:08)
Offline