My linode story:
i used to host on a linode 200 several domains with all the standard stuff a company needs: mail [postfix], pop3 [dovecot], web [apache+php], MySQL, ftp [vsftpd]. CPU usage minimum. The websites had reasonable traffic. peak times: 2-3 requests / pres second, for small periods of time.
The problem was RAM. it a few hours after restart it went swapping 120 MB and stayed there.
I said, wow, what's the problem. Reading these forums, i saw LAMP guys handling all I had, in a Linode 100 with little swap. [one was cruel enough to post free -m output and had 3 MB swapping].
I started optimizing.
After studying my system, i concluded that MySQL and Apache+mod_php5 ws the problem.
MySQL: [/etc/my.cnf]
skip-innodb -- it saves some RAM
skip-bdb
skip-networking -- they say it is good if you don't really need it, i didn't

query_cache_type=1 -- these 3 lines make your website run faster
query_cache_limit=1M
query_cache_size=32M

for the Apache and php i adopted the following architecture:
LightTPD in front of a spartan-compiled apache with a spartan-compiled php.
LightTPD would serve all the static files, and the rest was proxied to the apache that was listening on 8080 only on 127.0.0.1.
the transition was not easy. i had it all: vhosts, rewrites, ssl domain, auth basic.
but i did it.

apache:

--prefix=/usr/local/apachephp --exec-prefix=/usr/local/apachephp --disable-v4-mapped --disable-authn-file --disable-authn-default --disable-authz-host --disable-authz-groupfile --disable-authz-user --disable-authz-default --disable-charset-lite --disable-include --disable-env --disable-setenvif --disable-status --disable-autoindex --disable-asis --disable-cgi --disable-imap --disable-actions --disable-userdir --enable-so --disable-echo --disable-dbd --disable-isapi --disable-example --disable-filter --disable-ldap --disable-log-config --disable-env --disable-proxy --disable-proxy-ftp --disable-proxy-ajp --disable-proxy-balancer --disable-dav --disable-status --disable-cgid --disable-cgi --with-mpm=worker --disable-alias

now i have:

httpd -l
core.c
mod_auth_basic.c
worker.c
http_core.c
mod_mime.c
mod_negotiation.c
mod_dir.c
mod_so.c

php:
./configure --with-apxs2=/usr/local/apachephp/bin/apxs --disable-cli --disable-dba --without-mod_charset --disable-cgi --disable-debug --enable-safe-mode --enable-magic-quotes --disable-rpath --disable-ipv6 --disable-all --enable-bcmath --with-curl --enable-ftp --enable-gd-native-ttf --with-gd --with-mysql=/usr/local/include/mysql --with-mysql-sock=/tmp/mysql.sock --enable-sockets --without-pear --with-pcre-regex --enable-session --with-zlib-dir=/usr/include --enable-exif --with-jpeg-dir=/usr/local/ --enable-inline-optimization
[yes, i needed a lot of stuff]

in httpd.conf i put keepaliverequests to off, as apache will execute the php, send the result to lighttpd on local sockets [fast], and then it frees the resource . In the old configuration a 11MB apache process would of been reused for for sending to the browser 100 bytes blank.png files too.
Now i can do the work of the old 5 mpm apache workers with only 2.

now LightTPD, it is just great. i haven't tuned as it is so very tuned by default. i just migrated the rules and vhosts and rewrites to it, and proxied php scripts to apache.

now here is my free -m output after 1 day of hard work from my slack linode:
free -m
total used free shared buffers cached
Mem: 191 157 33 0 11 85
-/+ buffers/cache: 61 130
Swap: 256 0 256

basically the changes that saved me were: lighttpd, the apache/php tunning and the cache in the mysql. the rest , sure helped, but not so much in my opinion.

if you guys have any other tips and tricks about squeezing performance out of our linodes, I welcome any other sugesstions.
This is what I am going to do this summer vacation, so i can have the best linode around .

_________________
jlin

http://www.jlin.ro
office@jlin.ro

Just a question... I was wondering why you were proxying the PHP from Lighttpd through to Apache+mod_PHP5?

I have PHP on my Lighttpd as a FastCGI process. And it seems to work just fine for me. Response time is quick, etc. Memory use low.

At least I think so. I'm just wondering why you have PHP driving around the frontage road instead of down the highway?

well, yes, i read little info about this [all said that fastcgi approach was better], so i still need more sources untill i trust it.
i will setup an environment with this new thing, and if i like it, i will launch it into prod.

Boy, I feel so left behind, so "from jurassic times".

another thing done today:
php.ini
output_buffering = On
zlib.output_compression = 8 #4 kb is just not enough for my php scripts
zlib.output_compression_level = 7 [9 if you want to stress your CPU harder]


is there an absolute[impossible, i know, but still... ] list of tunings [what i do now, is just crawl the web and compile things, usually, i am after things that are "generally" good for performance, not good for specific apps or environments] ?
i saw cake's my.cnf for linodes [
he could add --skip-innodb for the ones that do not need innodb
]. is there something similar for for php.ini, httpd.conf, etc .... ?

_________________
jlin



http://www.jlin.ro

office@jlin.ro

I'll chime in support for fCGI, also. I was in your situation and switching to lighttpd w/ fCGI solved the issue. Luckily for me, the websites I ran were plug and play...no changes needed to make them work with fCGI.

Lighttpd + PHP5 was about completely painless for me.

apt-get install lighttpd

Followed with this tutorial:
http://trac.lighttpd.net/trac/wiki/Tuto ... ttpdAndPHP

And I had a completely working FastCGI PHP. With no back-and-forth with Apache.

Another annoying question from ignorance of what you are doing:

Why not use SQLite for your databases instead of Mysql? You'd get rid of a couple of processes and their memory requirements that way? I've been doing some work with SQLite (it's part of PHP5 now, if it's loaded), and it's just as fast as MySQL for what I use it for (an order entry system, with a couple of SELECTs per page on small to medium sized databases.).

Yup, another using lighttpd + fastCGI for PHP

But one thing you might consider trying first is seriously cutting down the number of workers in apache. Like one process and 3-5 threads, with a maximum of maybe 10 threads. If performance/RAM usage improves, retune it to find your sweet spot... If not, FastCGI.