Wordpress Performance: Why My Site Is So Much Faster Than Yours
People everywhere complain that Wordpress is slow, or that they can’t survive a digg. They die if they get more than 10,000 visitors a day, their hosting providers ban them for using too many resources, and they cry because they have to purchase expensive hosting plans. If this describes your plight, before you run over to Survive Digg hosting and plunk down even more money, take a look at your Wordpress setup and LAMP stack. You can make them better.
My Hardware
I’m not running on a top-of-the-line multi-processor machine with 16 GB of RAM per node. I have a Pentium 4 with 1M L1 cache, 1 GB of RAM, a 160GB SATA2 drive, and 100MB/s ethernet. I get 1.3 TB of bandwidth of month, as well. The hardware is from Cari.net and I pay $80 a month for it.
WP Built-in Object Cache
Did you know Wordpress will try and cache all kinds of database queries as files on disk? It’s so simple. Just add the following to your wp-config.php:
// Enable the WordPress Object Cache:
define(ENABLE_CACHE, true);
This can give a noticeable and immediate performance benefit. Less queries = less overhead and more CPU to go do other things. In case you don’t believe me, I just had a guy whose load average was between 20 and 50. After making this tiny change, it dropped to 2.
WP-Cache
You’ve seen this before, but if you’re not using the WP-Cache plugin, we shouldn’t talk. It serializes your posts to a file on disk and later spits them back. It’s the classic caching solution. It also knows how to update itself when comments are received, etc, so your site is always the most up to date. Currently 304 posts are cached on this site in the last hour.
Wordpress Plugins
Here is the complete list of plugins that run on this blog:
Content Filters: Adbright BritePic Enabler, Admin Info, Adsense Injection,Auto-hyperlink URLs, Feedburner Feed Replacement, Terms2tags, Wordpress Duplicate Content Cure, WPvideo, WP Fixed Size, WP Adsense, WP-Stats, wp-cache
New Functions: delicious - Bookmark this!, Elliott’s Asides, Elliott’s Feed Tagger, Google Sitemaps, PJW Mime Config, Plugins Used, Relative Dates
Remote Services: Akismet, Extract Terms, Get RSS, Text Link Ads, WordPress From/Where
As you can see, there are just five that have any kind of processing impact. Akismet has to make calls to their webservice to verify spam. Extract Terms uses the Yahoo API to build keywords for automatic tagging. Get RSS performs similar operations per post. Text Link Ads keeps track of an xml file it updates every now and then. WP From/Where archives the keywords used to find every post. The first four cache their results. WP From/Where is the only “expensive” plugin I have, since it adds a query to every page load.
You should go through your plugins, and see if there’s a way to make them faster. To make them stop creating queries and use flat files, or better yet, cache things. If your plugins are slowing down your Wordpress installation, fix them and submit a patch their author. He’ll probably even give you a free link.
You can install something like xDebug to profile your PHP code for bottlenecks, as well.
MySQL Query Cache
The MySQL Query Cache saves results of queries in case the query comes by again. However, it only knows how to save the byte-text of queries, not their compiled versions, so small changes to the query will create different cache entries. Turn this on if you don’t have unique ids in every query. You can enable it by adding the following to /etc/my.cnf:
query_cache_type = 1
query_cache_size = 26214400
This will turn on the query cache and instruct it to use 26M of RAM. After you’ve changed the config, restart the MySQL process by /etc/init.d/mysqld restart and then run these SQL queries to verify that it’s working properly:
SHOW STATUS LIKE ‘Qcache%’;
SHOW STATUS LIKE ‘Questions%’;
Qcache_free_blocks 2960
Qcache_free_memory 11693192
Qcache_hits 10433610
Qcache_inserts 5221850
Qcache_lowmem_prunes 2113131
Qcache_not_cached 1335038
Qcache_queries_in_cache 8765
Qcache_total_blocks 20976
Questions 21338215
When I check, I find the Query Cache efficiency is at worst 10433610/21338215, or 49%. That’s not bad.
PHP Opcode Cache
Why recompile our scripts every time, when we can save the bytecode? I use eAccelerator v0.9.5 to accelerate my PHP classes, currently of which 455 are saved. To install it follow these simple steps:
cd eaccelerator-0.9.5
phpize
./configure
gmake (or make)
gmake install (or make install)
add extension=”eaccelerator.so” to your php.ini file
add eaccelerator.cache_dir=”/tmp/eaccelerator” to your php.ini file
mkdir /tmp/eaccelerator
chmod 0777 /tmp/eaccelerator
Their wiki has very clear instructions for how to install it. This extension is a win-win. It uses a bit of disk space, but it also optimizes the opcodes and saves you from having to recompile a script every time. It can shave up to 5000ms off your loading time, depending how bad the php code you’re actually running is. For me, it saves about 650ms per page.
Apache httpd.conf
First, and perhaps most importantly, comment out any modules you’re not using. Loading them takes time and memory. Your apache config file is usually located in /etc/httpd/conf/httpd.conf. Some settings to keep in mind:
# Timeout and Keepalive
Timeout 30
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 6#Maximum Client Connections
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 512
MaxClients 512
MaxRequestsPerChild 4000
</IfModule>
There are tons of how to guides out there for configuring apache to maximize performance, but mostly it’s great software that doesn’t need much tuning.
PHP php.ini
PHP is a beast with all kinds of horrible modules it thinks it needs to load. You find the php configuration usually at /etc/php.ini; here are some settings to observe:
;*Hide our info
expose_php = Off
;*Turn off for performance
register_globals = Off
register_long_arrays = Off
register_argc_argv = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
;*Allow PHP to accept large data
post_max_size = 6M
file_uploads = On
upload_max_filesize = 6M
The real trick is to disable as many extensions as you aren’t using to save memory. You can check out this guide for more information about optimizing a php configuration.
Linux Kernel
Let’s put it this way; you want to be running the latest and greatest versions of all your software. If you’re using a 2.4 Kernel, don’t. The 2.6 kernel is appreciably faster. For me, getting the latest software is as easy as running the yum update command, as I use FC5. If you’re on a different distro, check their documentation for instructions on how to update to the latest version:
[root@fc435152 ~]# yum update
Loading "installonlyn" plugin
Loading "skip-broken" plugin
Setting up Update Process
Setting up repositories
livna 100% |=========================| 951 B 00:00
atomic 100% |=========================| 951 B 00:00
psa-8.1 100% |=========================| 951 B 00:00
updates 100% |=========================| 1.2 kB 00:00
core 100% |=========================| 1.1 kB 00:00
mono 100% |=========================| 951 B 00:00
extras 100% |=========================| 1.1 kB 00:00
Dependencies Resolved==================================
Package Arch Version Repository Size
==================================
Installing:
kernel i686 2.6.20-1.2312.fc5 updates 15 M
kernel-smp i686 2.6.20-1.2312.fc5 updates 16 M
kernel-smp-devel i686 2.6.20-1.2312.fc5 updates 4.6 M
Updating:
alsa-lib i386 1.0.14-0.1.rc1.fc5 updates 404 k
cups i386 1:1.2.8-1.fc5 updates 2.9 M
cups-libs i386 1:1.2.8-1.fc5 updates 180 k
dhcdbd i386 1.15-2.FC5 updates 68 k
gnupg i386 1.4.7-4.1 updates 1.9 M
gpm i386 1.20.1-82.fc5 updates 185 k
krb5-devel i386 1.4.3-5.4 updates 954 k
krb5-libs i386 1.4.3-5.4 updates 558 k
krb5-workstation i386 1.4.3-5.4 updates 858 k
libX11 i386 1.0.0-4.fc5 updates 761 k
libXfont i386 1.2.8-1.fc5 updates 227 k
libpcap i386 14:0.9.4-4.fc5 updates 207 k
openssh i386 4.3p2-4.12.fc5 updates 279 k
openssh-clients i386 4.3p2-4.12.fc5 updates 435 k
openssh-server i386 4.3p2-4.12.fc5 updates 251 k
samba i386 3.0.24-4.fc5 updates 16 M
samba-client i386 3.0.24-4.fc5 updates 4.2 M
samba-common i386 3.0.24-4.fc5 updates 8.5 M
tcpdump i386 14:3.9.4-4.fc5 updates 443 k
tzdata noarch 2007d-1.fc5 updates 451 k
Removing:
kernel i686 2.6.17-1.2142_FC4 installed 38 M
kernel-smp i686 2.6.17-1.2142_FC4 installed 44 M
kernel-smp-devel i686 2.6.17-1.2142_FC4 installed 13 MTransaction Summary
=================================
Install 3 Package(s)
Update 20 Package(s)
Remove 3 Package(s)Total download size: 75 M
Architecture
If you’re serving more than 5 million hits a day, you’ll want to take a different approach than if you’re serving 500,000 hits a day. For a small server, like mine, which can handle up to perhaps 1,000,000 hits a day, you’ll want everything running on the same box:
For a more complicated server, you’ll split off the MYSQL component onto a hefty box, with Apache/PHP instances on a cluster of loadbalanced other boxes:
Conclusion
There’s no good reason for Wordpress or your site to be slow, except your own negligence. Cache everything. Monitor performance. Use the latest versions of your software. Configure it intelligently. If you take an active part in every bit of software that powers your site, soon you’ll find things fit together more smoothly than before, and the secrets of a fast server will naturally fall into place.
Other Resources
Call me Lorelle; I’m going to link every other optimization guide for Wordpress I can find:
- Optimize WP Loading Times
- Optimize your database
- How To: Optimize Your CSS Even More
- Optimizing Wordpress Performance
- Optimizing Wordpress for High Volume Traffic
- High Performance Wordpress
- Optimizing Wordpress and LAMP to survive the Digg effect
- Diggproof & Speed up Your Wordpress Blog
- DiggProof your Wordpress
- WP 2.1 Is Faster Than 2.0
- Summer of Code 2007 Performance Testing Project
This entry was posted on Sunday, April 15th, 2007 at 8:25 pm and is tagged with performance benefit, object cache, database queries, tiny change, processor machine, content filters, admin info, sata2, digg, pentium 4, plight, 100mb, hosting plans, l1, 1m, node, stack, complete list, bandwidth, config. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback.
on April 16th, 2007 at 5:44 pm
Great article. Dugg — Thanks.
on April 16th, 2007 at 5:53 pm
Nice article, this should help me since I have 3 servers now because of load problems but now maybe I can follow some of your PHP hacks!
on April 16th, 2007 at 6:07 pm
test test test test
on April 16th, 2007 at 6:07 pm
Thanks for the link to my article. Here comes the hordes, hope it stays up!
on April 16th, 2007 at 6:39 pm
dugg!
on April 16th, 2007 at 6:56 pm
Hooray! A front-page “how to survive digg” article that actually loads!
on April 16th, 2007 at 7:28 pm
Nice article.. Gives me something to think about for future WP installations.
on April 16th, 2007 at 7:34 pm
I wrote a plug-in a while back that provides some additional insurance against a digging/slashdotting, etc. It allows you to automatically utilize the Coral Content Distribution Network for readers that come from specified domains.
theblogthatnoonereads.tunasoft.com/coralize/
on April 16th, 2007 at 8:34 pm
Wordpress plagued me too for a while.
After that, I just quit.
I go to Tech CX alot now.
www.techcx.blogspot.com
on April 16th, 2007 at 8:35 pm
I had some problems with WP-Cache as it was not showing the comment form on articles for registered users, if the page cache was triggered by a un-registered one. So you might wanna be aware of that….
on April 16th, 2007 at 9:44 pm
Good post! I always find it amazing the people’s solution to any problem is more. Looking at what your doing, and making sure you’re getting the most from any system is vital
on April 16th, 2007 at 9:44 pm
Great article Elliott.
on April 16th, 2007 at 10:25 pm
yeah I left wordpress a while ago
Cool article though!
on April 16th, 2007 at 11:05 pm
I rely on gninx:
advertisement:
Capitalists: we will make tofu from your balls:
www.google.com/alerts
Search terms: Bush took suicide pill
Type: News
How often: as-it-happens
Your e-mail:
Create alert
*************************Be the FIRST to know!*************************
on April 16th, 2007 at 11:07 pm
nginx that is.
))
btw, Bush took red suicide pill
on April 16th, 2007 at 11:27 pm
I just wanted to see if the comments were live and not just permanentally cached.
on April 17th, 2007 at 12:14 am
cached!
on April 17th, 2007 at 12:19 am
No, they’re live really!
on April 17th, 2007 at 1:09 am
ah, how painful it must be to have so many hits! =P
on April 17th, 2007 at 3:55 am
GNC-2007-04-17 #259…
Really wild show I actually recorded the podcast while at the same time having a live stream with people watching the show. It was really weird yet distracting at the same time. I will have a link to the video…….
on April 17th, 2007 at 5:27 am
so i guess i shudnt think about migrating to movabletype …
but i’ve heard so much about mavabletype being the holy grail of blogging software …
guess i’ve heard wrong … hehe …
on April 17th, 2007 at 9:23 am
Let’s see how’s is your wordpress performance(almost 1000 digg). Good to share
on April 17th, 2007 at 9:40 am
I tend to like WP-Cache until it decides to give me some problems. Now, I decided to do without it.
on April 17th, 2007 at 2:27 pm
Thanks for the great post. I’m going to implement most of your suggestions as soon as I can.
on April 17th, 2007 at 4:34 pm
Welcome to the DIGITAL age, mr. bussh.
I’ve got + worker_connections 10240
)), and I need them!
serving more than 7 million hits a day
on April 17th, 2007 at 6:05 pm
Great info Elliott. A few days late for me since I use Wordpress for my site and felt the pain when I made the digg front page on Sunday for the first time. I went down for a little but with the help of my host was able to debug a bad plugin and quickly installed WP-Cache and was back up running fine after that. I can appreciate the fact that you are very lean on plugins. You also offer some great tuning and load balancing tips here. I’m sure other fellow Wordpress users appreciate this.
on April 18th, 2007 at 11:09 pm
Thanks a lot for the useful hacks . I was trying to avoid digg because I didn’t want to over run my shared server but with this help I shouldn’t have to worry about digg crashing anymore.
on April 19th, 2007 at 6:53 pm
Thanks Mark! I really needed techcx.blospot.com!
Keep on blogging!
on April 19th, 2007 at 6:55 pm
Whoops, mis spelled the blog site!
techcx.blogspot.com
on April 20th, 2007 at 6:31 pm
This is great. We’re not quite there yet with tektag.com, but I’m bookmarking this for when the day comes.
Thanks,
Tim
on April 22nd, 2007 at 8:27 am
Bookmarked …
on April 27th, 2007 at 2:02 pm
Is there anyway to implement memcached with wordpress?
on April 27th, 2007 at 7:09 pm
YES! But memcached is pretty hardcore
Take a look at this article or the svn package.
on April 30th, 2007 at 3:16 am
Thank you sir. I will optimize my wordpress now.
on May 7th, 2007 at 10:47 pm
This page was slow to load for me.
on May 7th, 2007 at 11:25 pm
Yes, but you’re from Guam. That might be the first problem. 24/7 monitoring in place shows that this page is loaded in entirety on an average of about 1.5 seconds. Then the images all come in, which takes more time.
on May 9th, 2007 at 6:37 am
Another blog i run has been having severe load issues, and its something i have struggled to understand - i set up the cache and it caches pages but how does it deal with new comments ? Does it recreate the cached pages each time a new comment is posted? I ask becasue i have threads that can generate close to 600 comments in about 5 hours on a particular article _ does any one know where i can find this kind of information ?
Or is the article cached and the comments dynamic or do i need to re do my theme to fit this kind of functionality in
on May 16th, 2007 at 4:40 pm
Top wordpress tools of the month…
Wordpress is the phenomenon (yeah I do believe it is one) that made a lot of dreams come true. It created a bridge between people without any kind of programming knowledge and the fact of being live and writing for people. The road is so much shorter f…
on May 28th, 2007 at 2:52 am
@GrandMaster — the easiest way which will decrease your server’s load most (I assume you;re running Wordpress / similar cms) is to install an edge server / reverse proxy solution.
An easy to follow tutorial regarding this can be read here.
It constantly amazes me how people keep on prescribing the hardest way with minimum return to be done first.
Squid (and other edge server solution) are easy to implement, takes only minutes, and easily drop a double digit server load to a single digit.
Yes, you may not be able to do this on a shared webhosting environment; but so does many of the tips mentioned in this article.
Hope it helps.
on June 11th, 2007 at 7:38 pm
Thanks for the tutorial
on August 10th, 2007 at 8:11 pm
[…] Wordpress Performance: Why My Site Is So Much Faster Than Yours by Elliott Back - There?s no good reason for Wordpress or your site to be slow, except your own negligence. Cache everything. Monitor performance […]
on August 15th, 2007 at 2:05 pm
[…] WP Built-in Object Cache […]
on August 21st, 2007 at 2:37 pm
[…] If you would like some more advice on how to optimise your blog, check out these post: 6 ways to speed up your blog Why my wordpress site is so much faster than yours […]
on September 17th, 2007 at 9:10 am
[…] Maximize your server architecture.The amount of traffic your blog gets can determine the best way to set up your server. For some, it may be better to run everything on one box, but for others, splitting up the components into different boxes can speed things up. […]
on September 28th, 2007 at 12:57 pm
Nice Site!
on October 3rd, 2007 at 6:12 am
[…] But, I implemented some of the great tips from this blog - notably installing the wp-cache plugin for Wordpress, enabling caching in MySQL, and disabling some additional PHP options (although I doubt this last thing has any significant impact). […]
on October 3rd, 2007 at 7:14 am
[…] read more | digg story […]
on October 9th, 2007 at 4:22 pm
[…] Wordpress Performance: Why My Site Is So Much Faster Than Yours by Elliott C. Back Nette Zusammenfassung. […]
on October 13th, 2007 at 8:19 am
[…] WP Built-in Object Cache […]
on November 7th, 2007 at 10:54 am
[…] People everywhere complain that Wordpress is slow, or that they can ’t survive a digg. They die if they get more than 10,000 visitors a day, their hosting providers ban them for using too many resources, and they cry because they have to purchase expensive hosting plans. If this describes your plight, before you run over to Survive Digg hosting andread more | digg story […]
on November 8th, 2007 at 10:10 am
[…] read more | digg story […]
on November 19th, 2007 at 2:08 pm
[…] Mr. Back has some other suggestions at his blog which may be helpful for the WordPress BlogMaster — take a look, in particlular at his “PHP OpCode Cache” technique at that link. Note that I could have classified this under “WordPress Issues”, but the idea of looking at a cache fix using PHP is generic, and probably will work across a range of applications and Content Management Systems. […]
on November 27th, 2007 at 8:30 pm
[…] This object cache supposedly caches database queries to disk to reduce CPU and database overhead. This should increase performance in most cases unless your disk I/O performance is very poor, like Dreamhost’s NFS storage system. This feature seems to be undocumented and had security issues in the past, but is commonly recommended as a safe way of increasing performance. I have heard that the object cache hardly improves performance, but I’d never imagined that it would slow my site down by 10x or more. […]
on December 13th, 2007 at 12:48 pm
[…] Wordpress Performance: Why My Site Is So Much Faster Than Yours by Elliott C. Back […]
on December 14th, 2007 at 1:16 pm
Hi,
Thanks for writing this article, because I have the same performance trouble and now I have installed wp-cache plugin. Glad find your articles from google…
Cheers…
on December 18th, 2007 at 12:30 pm
[…] Mr. Back has some other suggestions at his blog which may be helpful for the WordPress BlogMaster — take a look, in particlular at his “PHP OpCode Cache” technique at that link. Note that I could have classified this under “WordPress Issues”, but the idea of looking at a cache fix using PHP is generic enough, and probably will work across a range of applications, that I have included it here. […]
on December 20th, 2007 at 1:59 pm
[…] People everywhere complain that Wordpress is slow, or that they can ’t survive a digg. They die if they get more than 10,000 visitors a day, their hosting providers ban them for using too many resources, and they cry because they have to purchase expensive hosting plans. If this describes your plight, before you run over to Survive Digg hosting andread more | digg story Mac vs. PC: How Would Linux Fit? » Sorry, no comments yet. […]
on December 28th, 2007 at 7:37 pm
That’s:
// Enable the WordPress Object Cache:
define(’ENABLE_CACHE’, true);
It needs quotes around ENABLE_CACHE.
on January 2nd, 2008 at 4:56 pm
Nice ideas and tips. You didn’t mention moving to CDN service all static content. It provides extra performance (lowers your server load), thus you can serve more web visitors with easy.
on January 11th, 2008 at 2:08 am
[…] People everywhere complain that Wordpress is slow, or that they can ’t survive a digg. They die if they get more than 10,000 visitors a day, their hosting providers ban them for using too many resources, and they cry because they have to purchase expensive hosting plans. If this describes your plight, before you run over to Survive Digg hosting andread more | digg story […]
on January 11th, 2008 at 2:28 am
[…] read more | digg story […]
on January 11th, 2008 at 2:50 am
[…] read more | digg story […]
on January 11th, 2008 at 2:50 am
[…] People everywhere complain that Wordpress is slow, or that they can ’t survive a digg. They die if they get more than 10,000 visitors a day, their hosting providers ban them for using too many resources, and they cry because they have to purchase expensive hosting plans. If this describes your plight, before you run over to Survive Digg hosting andread more | digg story […]
on January 15th, 2008 at 5:59 am
[…] According to these numbers, my dual core server can do 750 requests per second, fulfilling each within about 150ms each. That’s pretty fast, probably because I know the secrets of Wordpress Optimization. If you make every layer as fast as it can be, and cache heavily, you too can see lightening fast Wordpress installations! zeus technology ltd, adam twiss, apache http server, apache software foundation, apache installation, concurrency level, document length, concurrent requests, suitable answer, server hostname, document path, apache 2, server port, man page, server software, benchmark, wordpress, wp, bench, and methodology […]
on January 16th, 2008 at 6:23 pm
[…] Wordpress Performance: Why My Site Is So Much Faster Than Yours by Elliott C. Back (tags: wordpress performance optimization) […]
on January 16th, 2008 at 7:22 pm
[…] Wordpress Performance: Why My Site Is So Much Faster Than Yours by Elliott C. Back (tags: wordpress performance optimization) […]
on January 26th, 2008 at 3:14 pm
Another big gain is to switch from Apache/mod_php to nginx+fastcgi.
It’s smaller, and more free RAM means a couple extra php processes, should you so desire, plus the inherent speed boost you get from using nginx.
In a (wholly unscientific and useless) benchmark, using nginx with 3 php fastcgi processes, eaccelerator, wp-cache, a properly tuned mysql, etc.
/usr/sbin/ab -n 10000 -c 64 host.name/
… gives back ~1500 requests a second at around 525mbit/s total transfer… which puts the limiting factor squarely on my network card.
on January 29th, 2008 at 12:17 am
[…] For more advanced methods of caching and speed improvement, visit Elliot Back’s “WordPress Improvement: Why My Site Is So Much Faster Than Yours” […]
on February 24th, 2008 at 3:57 am
Nice graphics / pictures!
Which software did you use?
Greetings,
Lu
on March 4th, 2008 at 10:52 am
[…] People everywhere complain that Wordpress is slow, or that they can ’t survive a digg. They die if they get more than 10,000 visitors a day, their hosting providers ban them for using too many resources, and they cry because they have to purchase expensive hosting plans. If this describes your plight, before you run over to Survive Digg hosting andread more | digg story […]
on March 10th, 2008 at 3:24 pm
[…] Google Gruppe om webhoteller Et lille Servage.net trick Wordpress performance tricks Posted in Teknik | Leave a Comment […]
on March 28th, 2008 at 11:27 am
This give me a lot of stuff to go over. My site is fine most of the time & some times VERY slow. I am on shared hosting and my site is getting only a few hundred hits a day. I am ready to migrate to my own server…..GRRR headaches.
on May 1st, 2008 at 5:24 am
Check out the recently launched WP-Offload plugin. You will see a dramatical speedup especially if your posts have a lot of static content (images, documents, movies, etc.). It will completely redirect all the requests for static content to external cache servers, so the load on your web server will decrease significantly.
on May 8th, 2008 at 6:53 am
Thank you
on June 6th, 2008 at 9:36 pm
Hi, Do you still recommend Cari.net ? I’ve heard of several people having problems with them. I am about to switch from my previous hosting company Eapps. BTW I recommend Eapps, but I am switching because I need a dedicated server and Cari.net prices are far more cheap than Eapps… almost 90 times more cheap for what I need.
So, if you were about to switch from another hosting company, would you switch to cari.net?
thanks!
on June 22nd, 2008 at 7:50 pm
Hi elliot can you otimize my server for me please? i’ll pay of course, please contact me via the email i provided here thanks.
on August 26th, 2008 at 7:39 am
To turn off all needless apache modules, you will have to go to the /etc/httpd/conf.d/ directory also and rename module files like: squid.conf to squid.off or ssl.conf to ssl.off This way, httpd will not include this modules during startup.
on August 27th, 2008 at 2:50 am
Nice! Will try this out