OCS Very Slow on my VPS

[tshore]

I have switched from regular shared hosting to a virtual private server (vps). While there has been a pretty steep learning curve, the company I'm using has been really helpful. I have lived through more than a couple of shared hosting nightmares and I so want this vps solution to work for me. I am hosting 3 OCS conferences on my VPS right now and I have been very unhappy with the load times. I have one other OCS conference running on a dedicated server at a university and it is 5-10 times faster than the sites on my VPS. I have worked with tech support to try to isolate the problem(s) - allocated more memory, moved the MySQL server to a dedicated box, added another CPU core, etc. I am at a loss. I do not want to find another host, but if I can't get these OCS sites running faster, then I will have to move after these conferences are finished.

Has anyone experienced any similar issues?

Here I will contrast the fast site and one of the slow sites

Fast site: http://www.imrf.info/2010
Dedicated server, not too much traffic
OCS 2.1.2.1
Linux
PHP 5.0.4
Apache/2.0.54 (Mandriva Linux/PREFORK-13.3.20060mdk)
mysql 4.1.12-Max

Slow site: http://www.csbbcs.org/2010
VPS
OCS 2.3.0.0
FreeBSD
PHP 5.2.8
Apache/2.2.11 (FreeBSD) mod_ssl/2.2.11 OpenSSL/0.9.8e DAV/2 PHP/5.2.8 with Suhosin-Patch
mysql 5.1.45-log

I realize that everything is different about these two sites, but I am hoping that someone can spot something that might be causing my problems. I had come across a few places where people said that they had speed issues with various PHP web apps after upgrading to MySQL 5, but I couldn't find any suggested fixes that sounded promising.

[jmacgreg]

Hi Trudy,

Thanks for the detail. There were some performance/load issues with OCS/OJS 2.3; see http://pkp.sfu.ca/bugzilla/show_bug.cgi?id=4737 for a report and a fix (there's a patch for OCS 2.3 there too). Cant you try the patch and let us know if that fixes the problem? If it doesn't, could you give us more detail on where you are experiencing the slow load times?

Cheers,
James

[tshore]

I applied the patch from bug #4737, but I'm not sure whether it helped or not. I find the entire site to be sluggish, so I'm not sure how patching 4 files is going to help in my case. What I've been using as a benchmark is the All Enrolled Users page. This was taking 30-40 seconds to load and now, after some tinkering by my webhost, it takes almost a minute to load! What I'm looking for is some kindof MySQL indexing miracle like the one described in bug #4737. Do you have anything else I can try?

[asmecher]

Hi Trudy,

If the entire site is sluggish, it's unlikely that you'll find an easy fix in the form of MySQL indexing or something similar. You'll have to see if you can determine whether the bottleneck is MySQL or PHP -- e.g. using MySQL's slow query log -- and once you know which is causing trouble, you can attempt to debug its poor performance. It might just be that your VPS is not a good performer, especially if you've hosted the same system elsewhere with good results.

FYI, we're using Virtual Machine-based hosting here at SFU, and it's reasonably snappy. However, no two servers are alike...

Regards,
Alec Smecher
Public Knowledge Project Team

[tshore]

I'm dying here. My client can't even use the scheduler. I've had to raise the PHP timeout to something like 100 seconds just to be able to view all enrolled users, but that's not even enough to always have the entire scheduler page load and saving, well, that's another story. It can't only be an issue of a slow server. My webhost has tried a number of things to speed up this site without success. I have a Joomla site running on the same VPS and, while it's not lightning fast, it's performance is fine. Somebody must have had some similar problems with OCS 2.3 getting along with FreeBSD or MySQL 5 or the upgrade process messing up the DB or something. I have a 2.1.2 site on the same VPS and it's also pretty slow, but nothing like the 2.3 site. But this is just the first year for this conference and so there are about 1/3 as many users and, of course, only 1 year's worth of presentations, etc.

[tshore]

I ran something called mysqltuner.pl on my VPS and I thought I would post the output here, just in case anybody might see something that might help me:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.45-log
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 17M (Tables: 470)
[--] Data in InnoDB tables: 1M (Tables: 60)
[!!] Total fragmented tables: 81

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 10m 39s (40K q [9.526 qps], 79 conn, TX: 48M, RX: 4M)
[--] Reads / Writes: 92% / 8%
[--] Total buffers: 298.0M global + 6.3M per thread (151 max threads)
[!!] Maximum possible memory usage: 1.2G (122% of installed RAM)
[OK] Slow queries: 0% (0/40K)
[OK] Highest usage of available connections: 11% (18/151)
[OK] Key buffer size / total MyISAM indexes: 256.0M/15.0M
[OK] Key buffer hit rate: 99.7% (197K cached / 602 reads)
[OK] Query cache efficiency: 88.4% (35K cached / 39K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 851 sorts)
[!!] Temporary tables created on disk: 38% (29 on disk / 75 total)
[OK] Thread cache hit rate: 77% (18 created / 79 connections)
[OK] Table cache hit rate: 95% (138 open / 145 opened)
[OK] Open file limit used: 2% (254/11K)
[OK] Table locks acquired immediately: 100% (6K immediate / 6K locks)
[OK] InnoDB data size / buffer pool: 1.4M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Reduce your overall MySQL memory footprint for system stability
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
tmp_table_size (> 16M)
max_heap_table_size (> 16M)