Tuning a server for coppermine

[trippinsweet]

I'm running a coppermine gallery, version 1.43. The gallery has about 50,000 pictures and 2000 regular users. Usually everything works well, and coppermine is a beautiful gallery system to use when it works well.

Yet during peak hours, I see the sever load spike when 100-200 people are using the gallery at once.

I'd like to think my server is adequate for a gallery this size.

My set-up uses Dual Opteron 246 cpus and 1GB DDR memory.

My question is... what can I do to optimize my server for better performance when using coppermine?

I thought there might be some tips and tricks avaliable. The other software I'm used to... Vbulletin has a pretty extensive line up of optimizations that you can use if you run into high server loads.

I'm not using Vbulletin with this set-up though, and coppermine is basically the only highload software that I'm using.

[Tranz]

It would be more efficient if you provided a link so people can see what you're using that could be turned off, etc.

[Joachim Müller]

I'm running a coppermine gallery, version 1.43.

Upgrade to the most recent stable version (cpg1.4.4) asap.

[trippinsweet]

It would be more efficient if you provided a link so people can see what you're using that could be turned off, etc.

I can't provide a link since its an adult site.

And GauGau, I'm working hard to upgrade to cpg1.4.4. Right now my galleries themes are too heavily hacked but as soon as I figure out how to make all my themes work for cpg 1.4.4. I'll make the upgrade.

Anyways.... here's what I've done so far this week:

I started out with getting a load of 40-50 during peak hours. Incredible, no? I had to get it down so I followed these steps.

Steps:
#0:  Turn off random images, last commented images, etc.
        I did this about 2 weeks ago when I wasn't collecting statistics on the loads. I just knew the gallery was slow and had to do something about it.

#1:  Use the MYSQL query cache
   For me the benefits of this were negligible. Coppermine tables were saved but the pictures table can't be used because each new view causes an update to the table. I could not calculate the load savings.

#2: Use a php cache like eAccellerator
   Load dropped to 6-11 during peak hours. Coppermine uses a lot of static php files, so saving them in a cache keeps them from being recompiled each time a user needs them.

#3: Split the large gallery into multiple smaller ones.
        I split the one large gallery into 5 ones with each holding about 10,000 pictures.   The load during peak hours was unchanged, but during non-peak hours my load fell slightly---from about 1.6 to 0.7. My hypothesis is that during peak hours the load is unchanged because users were staying longer, thus more people used the gallery at a time. I can't be certain of this till I compare my visitor statistics of this week to the average.

#4: Turn off forum statistics (view counts, album counts, etc.)
   - Still checking to see what kind of savings this will bring

What I have left to do:

Turn off checking for banned users, updating the banned list
Turn off voting and view counting
   -- Why? Voting and viewing cause table updates. In order to keep a table in the query cache, we want it to update as infrequently as possible.

Ideally I'd want to keep voting and view counting. My first thoguht was "make a cache for the votes and views" then commit the changes later, but where will I store the cache? If I use a temporary table inside a database, then when there are enough updates I'll have a table that's comparable in size to the original pictures table. Then any benefit I get will vanish till I commit the changes and clear the temporary table.

Till I turn off voting, I'm finding the queries for hit and voting statistics and making them low priority sql updates.



One last thing I did was put in a 'fuse'. I modified init.inc.php and added the lines

Code Select Expand


global $modSettings;
$time = time();
if (($time - $modSettings['fuseBox_lastAvgTime']) > 60)
{
$load = preg_match('~average: ([\d\.]+)~', @shell_exec('uptime'), $match) == 1 ? (float) $match[1] : false;
$modSettings['fuseBox_lastAvgLoad'] = $load;
$modSettings['fuseBox_lastAvgTime'] = $time;
}

$safe = isset($_COOKIE['cpg_ah_gallery_fuse']) ? (int)$_COOKIE['cpg_ah_gallery_fuse'] : 0;
echo 'Last Avg Load: '.$modSettings['fuseBox_lastAvgLoad'];
if ($modSettings['fuseBox_lastAvgLoad'] > 2)
{
echo '  -|-  Warning: The public galleries do not function when the load is greater than 10.';
}
if ($modSettings['fuseBox_lastAvgLoad'] > 10 && !($safe) && !USER_IS_ADMIN)
{
$server_load = $modSettings['fuseBox_lastAvgLoad'];
pageheader("Server too busy, please try later");
msgbox("Server too busy, please try later", "Server too busy, please try later<br> current load $server_load");
pagefooter();
exit;
}
else
{
if (!($safe))
{
setcookie("cpg_ah_gallery_fuse", 1, time()+1800); // Expires in 30 minutes and ensures users who were in the gallery during that time will stay
}
}


just after

Code Select Expand

if (!GALLERY_ADMIN_MODE && $CONFIG['allow_private_albums']) get_private_album_set();

The above code checks if the server load approximately above 15 and refuses new entrants into the gallery. I hand each entrant a cookie that expires in 30 minutes, so I know if they have recently been in the gallery.



The fuse has been the best at halting the load spikes that I was previously seeing.

[sjordan]

Trippinsweet,

Upgrading from 1.43 to 1.44 should be an easy manual patch (even with highly modified themes).

Looks like you really only need to modify 2 files (include/init.inc.php and docs/showdocs.php)

See http://forum.coppermine-gallery.net/index.php?topic=28062.0

[trippinsweet]

Oh I did that much but I was under the impression that there were more changes than were published.

[sjordan]

I believe the only other additions are ...

GauGau wrote:
The new package cpg1.4.4 contains the most recent language files as well as improved doumentation.

Certainly not critical.

[Joachim Müller]

however they solve bugs. The patch you refered to actually fixes a security vulnerability. However, there's a lot of other fixes that went into cpg1.4.4 (compared to cpg1.4.3). Upgrade as suggested.

[trippinsweet]

Turning off voting and view counting worked like a charm.
Now pretty much all the tables stay in the query cache and my cpu usage never rises above 2.0 even during peak hours.

I'm working on an output cache for the php output that coppermine generates... not because I have to now, but I'm planning for future growth.

[Hercules24]

Turning off voting and view counting worked like a charm.
Now pretty much all the tables stay in the query cache and my cpu usage never rises above 2.0 even during peak hours.

I'm on shared webhosting, and on busy days (>25.000 pics viewed) My account gets a temp suspension due to CPU overload.
The only 2 simple things I can still shut down to probably ease CPU load are:
-Display file caption (in addition to title) below the thumbnail   
-Display number of views below the thumbnail 

I have no idea what the first option does and if it eases CPU load.
I also have a question about the second option:
-Does it only stop showing the # of views to regular users, but still updates the MySQL table and the views when in Admin mode.
-Does it stop showing and counting the numer of views so the MySQL viewed table stays unchanged.
-Does it stop counting and resets al counters to 0 by emtying the entire MySQL row.
Thanks if anybody can help me out.