eAccelerator. APC (PHP Accelerator) Disclaimer: i do not guarantee it will work for you so you better use it at your own risk.
It works for me. * I am using # symbol for all shell commands I am posting a quick step-by-step guide to install APC on servers (dedicated or VPS) with cpanel/whm working. First login as a root to your server/vps and make a directory to work with this plugin, #mkdir /home/APC-php #cd /home/APC-php. Innodb Performance Optimization Basics. November 1, 2007 by Peter Zaitsev77 Comments Note: There is an updated post on this topic here.
Interviewing people for our Job Openings I like to ask them a basic question – if you have a server with 16GB of RAM which will be dedicated for MySQL with large Innodb database using typical Web workload what settings you would adjust and interestingly enough most people fail to come up with anything reasonable. So I decided to publish the answer I would like to hear extending it with basics of Hardware OS And Application optimization. I call this Innodb Performance Optimization Basics so these are general guidelines which work well for wide range of applications, though the optimal settings of course depend on the workload.
Hardware If you have large Innodb database size Memory is paramount. 16G-32G is the cost efficient value these days. Operating System First – run 64bit operating system. There are bunch of other options you may want to tune but lets focus only on Innodb ones today. MYSQl Tuner. Memcached. Arguments in favour of PostgreSQL. From MoodleDocs Martin Langhoff argues in favour of PostgreSQL (source: Moodle over webct and LNLS at Athabasca University?
Forum posting) There are several reasons to go with Postgres, I'll try to make a brief outline. We run a variety of RDBMSs at Catalyst, and have a lot of in-house experience with them: Oracle, Postgres, MySQL and Progress, plus a few others. We also have experience with replicated databases, clustering and other tricks -- which we use for the backend of the .nz root domain servers as well as a few other mission-critical systems.
On the performance side, Postgres requires a bit more up-front configuration than MySQL. Write performance is also an issue with MySQL -- with a lot of traffic, it has serious problems with concurrent writes. But to tell you the truth, the real reason for choosing Postgres is reliability. No matter how hard we try, MySQL databases with a lot of usage have recurring index corruption issues. Michael is talking about having UPSs. See Also. Servidor WEB (Apache) Cherokee Web Server. NGINX, Inc. Lighttpd - fly light. JMeter resources. Jmeter FOR MOODLE. JMeter Scripts fÓRUM. Hi Anton, Ok, so it looks like you've tested your server with 500 concurrent connections, over a 500s period, equating to 3600 'hits' on the web server (split 2/3 over index.php/logout.php).
I'd intiially suggest that you add a ramp-up period of 15-30s. 500 threads with no warmup is unlikely to happen in the real world, and a ramp-up period will give things like PHP caching time to prime itself. Generally your server will be a happier server. Anyway, we can see from the min column that under ideal circumstances, your server will return pages in an acceptable timeframe (0.754s and 0.123s respectively). However, in the worst case scenario, your server is failing to serve ~8-15% of pages, and can take upto 20s to serve a page ( max )*; this is most likely to be when all 500 threads are hitting the server at once. *as a side note here, I suspect that you have a timeout somewhere set to 20s, since both your pages are failing after a maximum of 20s.
Hope this helps, Ben. Performance testing: 1.9 vs. 2.0. At LUNS Ltd. we have done some measurements recently and I think it worth sharing our findings with Moodle community.
Having enhanced JMeter testplan generation plugin originally developed by James Brisland, we used it to run performance tests on Forum, Chat and Quiz activities in 1.9 and HEAD (2.0) versions. Each testplan included all steps required to perform the task (logging in, navigating to required page, posting in chat/forum or submitting quiz). Test was done with 10 threads (simultaneous users) and each user made 5 posts in corresponding activity (in Quiz only one submission was done). Static content retrieving (images, css) are not included in the testplan, so the time only reflects php script output rendering on the client side.
All tests were done on dev-box: Intel(R) Core(TM)2 Duo CPU E8600 3.33GHz, 8GB RAM, Debian/GNU "squeeze", Kernel: Linux 2.6.26-2-vserver-amd64. Now the results. . * Navigation was slower than actual chat communication. An image with the same data: Loadtesting – Forums & Quizes – jMeter script generation « Moodle – Profiling, Reporting and Continuous Integration.