We are using Gallery3 for one of our projects and we find it simply amazing!
But there are a few issues that we have been facing lately:
1) Php caching is not there by default.
2) If there are many photos(say around 2000 photos-the page takes time to load.
3) We are hosting on a popular hosting service, we had processing issues- the CPU utilization suddenly spiked, hence barring our
site by the providers.
So, I have a few questions:
1. How many photos can be uploaded-what is the maximum limit?
2. How can we improve caching and also, how to improve the speed of the gallery.
3. Is there anyway to handle the CPU utilization spike issue? Also, what can be done to ensure that CPU utilization does not spike.
4. Under settings & Graphics, which is a better toolkit to use in order to avoid CPU utilization: Image Magick, GD
Library or Graphics Magick?
The theme we have used is:
3nids theme
modules running :
Exif Data
Gallery 3
Info
ModuleUpdates
Organize
Rebuild items
REST API Module
RSS
Search
Server Add
Slideshow
Tag Albums
Tags
Users and Groups
Posted: Mon, 2013-08-19 10:19
Posts: 1857
Hard to speak on this much in the abstract. (For instance, I have no idea what your server resources look like.)
1. Gallery imposes no maximum limit on the number of photos.
2. I think that Gallery does do some caching already, but you might look at furthering that (and maybe even look at compression). (Again you have me speaking in the abstract. If you have the system authority/access, you may want to look at nginx--depending on your needs.) Neither of these have much to do with cpu use during uploads, but it will (may) help pages load faster for site visitors.
3. I'm assuming that your cpu spike was caused by uploading a ton of photos and/or regenerating thumbs/resizes for a long time; if that's it, you could change the number of simultaneous to 1. It will take longer, but use fewer resources.
You might also want to look at the serveradd module.
http://codex.galleryproject.org/Gallery3:Modules:serveradd
Posts: 27300
There is no maximum limit that the software imposes. All limits are host related. Perhaps other upload methods would be better in your situation.
Also a hosting issue. There is a caching module that might help but I have never tried it:
http://codex.galleryproject.org/Gallery3:Modules:cache
Improving speed; I'm sure there is a few threads related to this. Smaller thumbs and less thumbs per page would reduce page load time for one. Other threads should have some suggestions.
One to get you started:
http://galleryproject.org/node/101616
also see if the default wind theme improves the speed. If it does then it could be theme related.
I would assume that the cpu utilization spike occurs when you add items and the software makes the thumbs and resizes. Smaller chunks or images uploaded would help as well as smaller original sized images.
I'm not sure about CPU utilization but GD uses the same memory as PHP, so using GM or IM would help in almost all situations. There is a few benchmarks out there and here is just one:
http://www.compsci.wm.edu/SciClone/documentation/software/graphics/gm-1.3.7/benchmarks.html
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 3
Hi All,
Let me first introduce myself,
My name is Nissim and I work in the same company with Falaq (the person with the original post)
I personally have been using Gallery2 and Gallery3 since 2008 on a couple of small projects and they have been working pretty well with a home grown server config.
In the present scenario however we have had some issues with the hosting provider. (issues mentioned in the original post)
We have a shared account with limited resoucres (as most shared hosting) and a LAMP server cPanel admin interface. (not a nginx server)
We expect a load of 2000 - 3000 visitors as the highest on a given day.
What caused the issue:
On a single day over 4 thousand images were uploaded to the gallery into one album using the native uploader of G3.
Since the gallery automatically prepares the images to the set size and creates thumbnails, this caused the CPU to spike in usage.
Once the script ran well almost sucessfully with 22 errors only, the gallery seemed to work.
However due to the high CPU usage the hosting service administrators red flagged our account and blocked the website the next day.
After a couple of conversations with the hosting service, plus following the post on how to improve speed of G3 our website is functional.
At the moment we are uploading a new set of photos in batches of 300-500 in each album. Hope all goes well.
We can provide you with the logs sent to us by the hosting provider if it would help.
Nissim
Posts: 27300
I would consider that high usage on a shared server. If you host flags that as high usage then consider adding smaller batches as you have suggested you are doing. Perhaps that will not hit the trigger point of your host to red flag you.
If this is going to be a regular occurrence (4k/day) then you might have to consider a different host or perhaps a different plan with this host.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 3
Hi Dave,
Thank you for your reply!
It would be a good Idea to change the hosting plan and probably use a cloud service me thinks.
I have another idea though:
Is it possible to add the resized images directly add it to the G3 local folder with the thumbnails.
Will it add the images to the database with the album structure and pull the tags ?
This might solve the issue in a diffrent way altogether.
Nissim
Posts: 27300
No.
You could try different upload methods but in the end the application has to make the thumbs and resizes and add info to the DB about those images.
If there is a resource limit imposed by the host then you have to have those limits changes by the methods mentioned:
New host, Different plan with host, smaller uploads in quantity size and or size.
Dave
_____________________________________________
Blog & G2 || floridave - Gallery Team
Posts: 3
Hi,
I came across a few issues
This might help:
Problem: The thumbnails generated from the gallery were in the region of 25 to 40kb each file. This was too high a file size for a thumb 190 in width. The plan was to reduce file size of each thumbnail. Since the gallery contained 5000+ thumbs, this high size was an issue. A typical thumb of this size should be not more that 12kb.
Solution: After examination of a thumbnail file I found that the bulk of the file size was due to the EXIF data which each thumb file was holding. With the mogrify -strip thumb.jpg command I was able to shed off 15 to 20 kb of each file. this brought the average file size to 10kb.
This would be helpful to the gallery project to strip EXIF data when generating thumbnails.
Hope this helps.
Nissim
p.s. what are the files that resize images and generate thumbs on upload ?
Posts: 1857
Yeah, it's preference, I guess. I actually prefer the exif data stay with the thumbs, but that's just me; may not be general consensus.
Even if you save 15kb per thumb for 5,000 photos, that's only about 70MB or so. That's a big deal if someone with a slow connection is loading every page; not so big a deal for disk space or individual page loads (because an individual page would have nowhere near 5,000 thumbs on it). More server resources would likely be a bigger boost if you're seeing slow thumb loads. (It may also be worth looking at the server's time connecting to the db.)
Just my 2 cents.