I tried gallery2 out on a relatively small (1 GHz / 1 GB RAM), but dedicated and not really loaded machine running lighttpd, php5.2.1 and eaccelerator based on gentoo-linux.
My impressions:
+ Very impressive installer: Simple, looks nice, works actually perfect
+ Extremely feature rich: I couldnt find much one can possible miss
+ supports lighttpd / sqlite as I use. Thats still not self-explanatory
+ lots of options to import / upload images
/ Optics are ok
/ Themes work reasonable
/ Size of the whole packet seems ok
/ Sometimes a bit complicated to use, but all basic stuff is easy enough
/ Video support, but it is mostly left to the browser and its plugins to deal with the videos. So what works in one browser fails in the next.
- quite some demands in image processing software, took me a while to install all
- the captcha: Neither did I get it work properly (or I was to dumb to read em), nor does the captcha appear to be safe enough
-- very resource hungry aka slow on small machines: Even with several plugins removed and preformance tuned it takes easily several seconds per page. Speeds up a bit due to caching on second click, but still not fast enough.
Hope the feedback helps and if someone has more questions he's welcome to ask.
Posted: Sun, 2009-09-20 16:59
Posts: 16504
http://codex.gallery2.org/Gallery2:Performance_Tips
There's lots of other tweaks you can do too. But I think most I've seen are Apache and MySQL related and not Lighttpd and sqlite related.
G3 is faster
And on my shared server it doesn't take long for pages to load at all. But G3 doesn't support Lighttpd (runs, but some aspects won't work without making changes to the server's config) and only supports MySQL
Just an FYI, G2's development is complete, maybe a bug fix, maybe a security fix with be released, but major development is done. However, you should be able to get G2 running lighting fast on that hardware. I'd take a look at what sort of disks you are using. Is the DB on the same server, etc...
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 10
Well, I am not sure how fast it should run. The server is a small self-hosted one:
Via Epia 1 GHz, passively cooled. 1 GB RAM. Disk is a 2.5'' laptop drive to preserve energy.
So far everything I tried running there was fast. Generally php/sqlite works fast and doesn't cause delays for simple scripts that I use for other pages. I haven't bothered running is as fcgi yet, but the start overhead seems to be neglible, it is the run time of the main.php from gallery2 that is too long.
A part of the harddrive is encrypted (AES128) and even that hasn't caused delays yet, though I almost expected some when I tried this out. The processor has some hardware acceleration for this however and it works nice. And the system disk plus all that the lighttpd server uses is not encrypted. Also the sqlite db is not on the encrypted part and of course local, as sqlite cannot do remote DB accesses.
The link with the performance tuning I have already exhausted. That did speed it up a bit but its still several seconds for a 50 images gallery. It is apparently the CPU usage of the main.php from gallery2 that causes the delays. ps shows 100% CPU usage for a while when it runs.
I will try out gallery3 just to give it a test. Lets see how that runs with lighttpd/sqlite on that small machine,
Posts: 16504
You're probably nailing the DB such a slow hard drive. Check out G3, but it's totally not supported in that config. SQLite won't work for it, period. Only MySQL at this point.
Maybe try G1 (older, not supported software)
I run G2 and G3 fine on a VPS with only 360MB of RAM. Granted the rest of the hardware is server class. I have 4 processors available to me and the hard drives are server class in RAID 10, not a single slow, low-end laptop drive.
Perhaps the other apps you've been running are not very intensive on the database, but Gallery is, and slow hard drives don't cut it if you want speedy database access.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 10
ok, didnt read well enough. So I guess I won't be able to test gallery3 until it does support sqlite3 as database, because I have no mysql installed there and won't change that and the installer doesn't allow to bypass the mysql check.
When will that be? I can see there are already some hooks in the code when I fgrep for sqlite through the code.
I doubt that is a problem. Usually I can run many projects optimized for apache with lighttpd. Is mostly only a matter of translating the config options a bit. There is hardly anything that apache can do with lighty cannot. The installer already runs nicely till the mysql check on lighty.
Who knows, but I cant see the disk getting jammed during the runtime of main.php from G2. Instead ps faux indicates the php-process hogs 100% CPU for several seconds.
I also can't see such a terrible difference between a laptop drive and a 3.5''. Is mainly the slightly lower spin speed that should give -20% or so but once I had a 3.5'' disk attached and it did not feel any faster (or resp. slower when i replaced it by a 2.5'').
Posts: 16504
SQLite, never unless someone writes the code for it. It's not planned by the core team to code or support it. Same for PostgreSQL, but there is someone with interest doing that. Doing a quick grep myself, I think those hooks you saw are actually part of the default Kohana file system and won't be utilized by G3 unless someone does the work to tie into SQLite.
As for Lighty:
G3 runs just fine on Lighty, I have and do that on a daily basis. The ONLY hangup I've seen is in assigning permissions to albums. G3 drops a .htaccess file in your albums, resizes, and thumbnails directories that correspond with the album you're setting permissions on. That .htaccess file has a rewrite rule to run those files through a file proxy that checks the access level of the user requesting the file. With Lighty, you can set permissions, but it won't run files through the file proxy (the .htaccess rewrite rules don't work on Lighty). So you can edit Lighy's config to run all files in var/albums, var/resizes, var/thumbs through the file proxy, but now you're eating into some of the performance gains you get with G3 being setup this way.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 16504
Try fcgi. What tuning have you done with Apache and PHP? I know with Apache (php module) or Lighty (php fcgi) on my VPS box G3 doesn't even make it sweat at all. I know very little about tuning for those specifically. But I really don't know if Gallery is that tuned to using SQLite or it just has the ability to use it.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 10
The tunings I did on G2 was basically kicking out almost all modules test-wise and wherever applicable following the other hints as e.g. installing eaccelerator and such. Also enabled caching for everything etc.
Another thing I noticed when trying out G2: It is not the login pages or the admin that is really slow. What is slow it adding images (normal, takes also a bit on G1 due to resizing) and then later viewing any album.
G3 I just installed and deleted 10 mins later when I saw it doesn't run at all without mysql.
I by the way just installed G1 for a test. Works easily 5-10x faster than G2 and actually the conclusion is my system is clearly fast enough for G1 even when I put 300 images in 3 albums instead mere 50 in one album on G2.
Remarkable difference. So it seems fcgi vs cgi doesn't do much. G1 also has to start php via cgi and the overhead to start up php processes is anyway only significant on a system where a lot of users access webpages parallel. Not the case here.
Thats also the same tradeoff between MySQL and sqlite. MySQL is faster when you have many concurrent database accesses by many concurrent users. If only few users access the database parallel if at all then sqlite is hands down faster in my experience, which is why I dont use Mysql unless I know I have quite some concurrent accesses.
Posts: 16504
G2 is a beast
G1 doesn't use a database, just flat files, has no caching mechanism and G2 is trying to do everything under the sun, including supplying power to the sun
.
For every single image you import into G2, there is approximately (at a minimum) 6 files that get created. Thumb, resize, fullsize (what you uploaded), and several cached files. I'm sorry but this really sounds like a disk i/o and/or cpu issue. I have a feeling if you were to run this on an Intel or AMD processor and not some puny embedded processor you'd see massive performance increases.
FAQ: Is it my imagination, or is G2 slower than G1?
G2 has many advantages over G1. G1 can get very slow the more photos you have. G2 isn't really going to slow down much with the size of your db or number of photos. Though the more traffic you get the more hardware you're going to have to throw at it. But again, G2 is a beast and it's doing a lot of work all the time.
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here
Posts: 10
Ha! Ha! Ha!
I found one major bottleneck from my G2 installation! That stupid thing was running off the GD php library instead using the ImageMagick programs that I extra installed for it! There is this strangely named "tool priority" menu that I wouldn't have expected to find it under, but GD had highest priority. Gosh, why doesnt it per default prioritize ImageMagick over GD when it is available? GD is soo damned slooow. The installer should warn like "are you mad" when for whatever reason GD is used...
This has quite some impact. With GD library each Album page takes 10s up to 15s. Now with Imagemagick it is down to about 2s per page. Still slow, so yes indeed G2 is a beast. And it is indeed mostly the fact that this thing hogs massive CPU power.
G1 in comparison is 0.5s per page, which may be indeed limited by network / harddrive latency.
So still a difference of almost factor 4, but not that outstanding any more.
Hmm, I would like to switch to G3. My vote definitly goes to putting sqlite import into G3. That shouldnt be that hard to do if G3 is cleanly developed and used the php-PDO interface. Has noone tried just switching the init of the DB over to sqlite type?
Posts: 16504
Ah, yeah, GD is a pig.
sqlite isn't going to be supported in the core product or by the team unless someone wants to join the project and do that work
Same goes for Windows, IIS, MSSQL, etc...
This is, however, the great thing about git. You can fork G3 and get it working and still pull in other updates to keep your repo current yet not blow away your stuff. I've really simplified that, but it's a great tool.
Then your changes, could, if desired, be easily pulled into the main code or people could easily use your repo to get your changes and use that themselves. But with the 80/20 rule, sqlite is not in that 80% of the market
Most people run their sites on shared hosts and they use Apache and MySQL.
If you want to work on it, join the -devel mailing list (it's very low traffic) and jump on #gallery on freenode and I'm sure you'll get helping hands.
http://codex.gallery2.org/Mailing_Lists
http://codex.gallery2.org/IRC
http://codex.gallery2.org/IRC_Support
____________________________________________
Like Gallery? Like the support? Donate now!!! See G2 live here