Linode 768 and LAMP

5000 hits per day is around 3.5 per minute, apache, lighty, nginx can all handle that without even blinking.

The LAMP stack script (http://www.linode.com/stackscripts/view … criptID=10">http://www.linode.com/stackscripts/view/?StackScriptID=10) will tune apache for you and you'll be fine.

Also a 512 can easily handle 5000 h/p/d.

Thanks. I've never used the stack scripts so I didn't know if I could expect it to be tuned up for my Linode or not. I assume that it properly tunes not only Apache, but also MySQL?

I'm moving to the 768 because I regularly use more than my allotted 200GB/month transfer (lots of images). Rather than paying the overage for the extra 100GB or so that I use every month, I figured I might as well upgrade everything else for the same price.

Why do you want to move back to Apache if you've been running problem-free with lighty for three years? By your description (lots of images), it looks like an ideal situation for lighty to shine. Is there something you need that lighty can't deliver, such as per-directory .htaccess configuration or an Apache-only module?

The op said > (The prevalence of Apache rewrite rules over Lighty makes it preferable for the software packages that I'm running.)

However I do agree lighty and nginx perform better on static files than apache but for the number of hits you're talking about I wouldn't worry about which server you run.

Yes the script tunes apache,mysql and php.

> (The prevalence of Apache rewrite rules over Lighty makes it preferable for the software packages that I'm running.)
Oops, missed that.

But is it actually so impossible to use that software package with lighty? I mean, you've been using it for three years just fine. Rewrite rules are setup-once-and-forget-it, so if you can find the right set of rules, you're done for the rest of the decade.

Also, you might want to look into nginx. It's often easier to translate Apache rewrite rules to nginx rewrite rules than lighty rewrite rules, because nginx natively supports more types of rules. Otherwise it's very similar to lighty.

Though it was perhaps a bad choice, I chose Vanilla as my forum software. It's a relatively small userbase (the product itself I mean). I then upgraded to Vanilla 2. There were no lighttpd rewrite rules so I wrote them.

But they're not perfect and I can't figure out how to get some things to work. I have had little luck getting others to join me in the cause because the great majority of Vanilla users are using Apache.

I then chose Piwigo for an image gallery; again not widely used; again no Lighttpd rules for it. I wrote them myelf. Luckily, those have always served me well.

When looking for support for a lot of these packages, people don't know how or don't want to help because I'm not running on the "preferred" web server.

Could I stay with lighty and keep writing my own rewrite rules every time I install some new software? Sure I could. But why not switch to Apache and take one more thing off my plate?

But hybinet, are you ultimately saying that you don't think Apache will work as well for me? Because that was my original question. Certainly, if I can expect noticeable performance degradation, then I'll want to rethink using Apache.

.

Apache should be able to handle 3500 hits/day without breaking a sweat.

If you truly are serving a lot of images, you might be well served by putting something like nginx in front of Apache to serve the static content, and pass all the PHP stuff on to Apache.

Another option you might want to consider… If your primary need is more transfer, you could keep your existing 512 as your web server and move your database off to a separate 512. Transfer is pooled for all Linode's on your account, so you'd get a total of 400GB/month. The web server and db server would communicate over the private network, which doesn't count towards your transfer usage.

A few other tips on saving bandwidth,

1) compress your content using mod_gzip or some other similar mechanism, it won't help for images since they're compressed anyway (unless you're using uncompressed images of course), but it will reduce other content

2) If your images don't change very often employ caching using mod_expires

@Lykaon:

But hybinet, are you ultimately saying that you don't think Apache will work as well for me? Because that was my original question. Certainly, if I can expect noticeable performance degradation, then I'll want to rethink using Apache.
I didn't mean to imply that Apache would be bad for you. I was just wondering why you want to move from lighty back to Apache, because most people on these forums want to move the other way around. If anything, Apache increases memory consumption. Whether or not this matters depends on how much memory you have at your disposal.

With only 5,000 hits per day, any web server would work just fine, as long as you configure it properly. Do you know whether your image files are being served directly by lighty or through a PHP script? You can usually tell by looking at the URL of the images. If it's the former, you can get significant memory savings (and possibly performance gains) by staying with lighty or nginx, but since you have plenty of memory this might not be a concern. If it's the latter, switching to Apache probably won't change anything memory-wise.

Another option, as @JshWright said, is to put lighty/nginx in front of Apache as a reverse proxy. This setup has similar memory and performance characteristics as lighty/nginx with fastcgi, but you also get to play with fancy Apache rewrite rules. If you want to have the best of both worlds and don't mind having some fun tweaking things, try this.

@Lykaon:

I'm about to move over to a larger Linode (768) and I'm interested in trying Apache again. My Linode runs a web server that gets about 5000 hits/day.

On an absolutely insane day for my heaviest site, per awstats, I had 740k hits, 86k pageviews, mostly in a 4 hour period. This is a phpbb3 board. At that time, it was on a 360 (now 512), running apache mpm prefork with mod_php. ie, the heaviest possible way to do it. That said, if you're pushing over 200GB in only 5k hits a day, you're serving up way bigger files than I am (1.1GB used in that day).

Just as an update to this:

I went ahead with testing this out. I got a Linode and installed the standard LAMP stack script. I copied over my data and my sites and did some benchmarks with ab from my home computer (I have no idea if Apache's ab is a good way to get metrics).

In general, Lighty performs better by about 200 milliseconds pretty consistently as I ramp up the concurrent connections.

On the other hand, Apache was a breeze to set up with all my software. It was a lot easier to find guidance on the web about setting up expires headers, apc, etc.

So far, I've set up expire headers, enabled APC, and enabled super-cache for Wordpress. Apache is configured to use up to 40% of the RAM, and mysql gets 40%. Anything else I can do to squeeze out some performance from Apache (besides standing up nginx or Lighty for the static files)?

.

Have you enabled mod_gzip, it will ensure the super cache content is compressed saving you bandwidth and increasing speed.

@obs:

Have you enabled modgzip, it will ensure the super cache content is compressed saving you bandwidth and increasing speed. Good idea. The super-cache addon has a checkbox for zipping the contents, but I'm not sure how it's doing it. If it's doing it via php, then modzip may be more efficient. I'll look into that.

Since I didn't enable mod_zip on Apache, I assume the super-cache plugin has no choice but to do it via php.

.

@Lykaon:

Anything else I can do to squeeze out some performance from Apache (besides standing up nginx or Lighty for the static files)?

The other route you can go with Apache is to replace mpm prefork/mod_php with mpm worker/fastcgi.

@glg:

The other route you can go with Apache is to replace mpm prefork/mod_php with mpm worker/fastcgi.
What are the pros/cons of that?

Apache doesn't have to load php for every requests including static requests, and mpm_worker is threaded so uses less ram.

I'd be very careful going the FastCGI route. Apache's PHP FastCGI implementation is a mess. It sorta works if you configure it just right, but the setup is complicated, inelegant, and nowhere near as robust as lighttpd or nginx. Remember, lighty rewrote the book on FastCGI for a good reason.

I got burned pretty bad by Apache/mpm_worker/fastcgi a while ago, and nowaways I prefer to give all my static files to nginx.

I was able to get it down to about 40ms slower than Lighty with zip and a better wp-super-cache configuration (turns out it wasn't working properly cuz of permissions).

Apache Bench with 10000 connections and 10 concurrent gave a 40ms mean time lead to Lighty, but it's longest attempts were longer than any one attempt on Apache.

The big part seems to be the transfer rate. Lighttpd is transferring at 321 Kbytes/sec and Apache is transferring at 298 Kbytes/sec. Is this really a function of the web server? I would think the web servers would be so fast that transfer rate would be more capped by the link.

But they're both linodes in the same data center, so I would expect the transfer rate to be similar. Is that an incorrect assumption?

.

Are you running ab from a linode in the same datacenter, or are you running it from home? Your last sentence is a little ambiguous, and 300KB/s sounds suspiciously similar to what you'd get with a crappy "high-speed internet" service in the US.

Also, are you requesting a static resource, such as an image file, or a dynamically generated page, such as the home page? If the request goes through PHP at all, the transfer rate will drop dramatically because of the latency imposed by the PHP interpreter. The transfer rate is meaningless when benchmarking PHP scripts. Requests per second is a better indicator of performance. (The longest attempt takes much longer probably because Apache with mpm_prefork puts extra requests on the waiting list until it's done with previous requests.)

I wouldn't worry too much about 40ms latency differences. What you need to look out for is memory consumption of the server while you're hammering it with lots of concurrent requests. Try upping the concurrency to 50 or even 100. Run htop on the server in a different terminal and keep an eye out for memory consumption. If there's something wrong with your Apache configuration, memory will go up dramatically and the server might grind to a halt. As long as that doesn't happen, you're fine.

I was running ab from home. I started doing so from the datacenter.

In the end, I just couldn't tune Apache to my liking. Rather than learning nginx for this particular server since I was on a deadline, I just stood Lighttpd back up. It outperforms Apache in pretty much every discernible way. I'm sure there must be some reason to use Apache over Lighttpd, but I have convinced myself that I can't see it (especially for my needs).

Thanks for all the help. I certainly learned a lot if nothing else.

Next up on my list is to figure out why my php5-cgi processes are all using so much processing power. Under a typical "heavy load" scenario for my site, they're using 200% processor power in aggregate. Seems excessive just for some PHP.

What sort of scripts, and what sort of traffic? A bytecode cache like APC can help reduce the CPU usage of PHP, since PHP recompiles scripts every time they're run.

@Guspaz:

What sort of scripts, and what sort of traffic? A bytecode cache like APC can help reduce the CPU usage of PHP, since PHP recompiles scripts every time they're run.
I've got APC running. I'm running Wordpress, Piwigo and Vanilla 2. I suspect that Vanilla 2 is the main culprit but I have nothing to back that up. Just history of problems with forum software being typically more demanding. I've got wp-super-cache on wordpress, so I think that's about as efficient as it can be.

And overall, the site actually runs like a dream. Everything is served up super fast and I couldn't be happier with the performance. I just don't want to upset my neighbors by stealing their processing time.

You can't steal others processing time, everyone gets an even share and the ability to use unused cpu.

@obs:

You can't steal others processing time, everyone gets an even share and the ability to use unused cpu.
Well that's a relief. I guess I should then worry about not having any unused processing time to borrow and my server getting slow. So far that doesn't seem like it's going to be a problem, but still seems like I should put in my due diligence.

If you haven't already install something like munin, it allows you to track resource usage over days/weeks/months/years so you can see if it looks like you're bottlenecking some where if/when things slow down.