| 1 |
On 03/06/2013 04:07 PM, Alan McKinnon wrote: |
| 2 |
> On 06/03/2013 22:59, Michael Mol wrote: |
| 3 |
>> On 03/06/2013 03:54 PM, Grant wrote: |
| 4 |
>>> I lowered my MaxClients setting in apache a long time ago after |
| 5 |
>>> running out of memory a couple times. I recently optimized my |
| 6 |
>>> website's code and sped the site way up, and now I find myself |
| 7 |
>>> periodically up against MaxClients. Is a RAM upgrade the only |
| 8 |
>>> practical way to solve this sort of problem? |
| 9 |
>> |
| 10 |
>> Use a reverse proxy in caching mode. |
| 11 |
>> |
| 12 |
>> A request served up by the proxy server is a request not served up by |
| 13 |
>> Apache. |
| 14 |
>> |
| 15 |
>> Squid, nginx and varnish are all decent for the purpose, though squid |
| 16 |
>> and nginx are probably the more polished than varnish. |
| 17 |
>> |
| 18 |
> |
| 19 |
> Grant, |
| 20 |
> |
| 21 |
> If you optimized the site well, I would imagine your RAM needs per page |
| 22 |
> request would go down and you could possibly increase MaxClients again. |
| 23 |
> Have you given it a try since the optimization? Increase it slowly bit |
| 24 |
> by bit comparing the current performance with what it used to be, and |
| 25 |
> make your judgement call. |
| 26 |
> |
| 27 |
> Is there some reason why you can't just add more memory to the server? |
| 28 |
> It's a fast and very cheap and very effective performance booster with |
| 29 |
> very little downtime. But if your slots are full and you need new |
| 30 |
> hardware, that's a different story. |
| 31 |
> |
| 32 |
> Michael's proxy suggestion is excellent too - I use nginx for this a |
| 33 |
> lot. It's amazingly easy to set up, a complete breath of fresh air after |
| 34 |
> the gigantic do-all beast that is apache. Performance depends a lot on |
| 35 |
> what your sites actually do, if every page is dynamic with changing |
| 36 |
> content then a reverse proxy doesn't help much. Only you know what your |
| 37 |
> page content is like. |
| 38 |
|
| 39 |
The thing to remember is that clients request a *lot* of static content, |
| 40 |
too. CSS styles, small images, large images...these cache very well, and |
| 41 |
(IME) represent the bulk of the request numbers. |
| 42 |
|
| 43 |
Unfortunately, with the way mod_php and friends work with Apache, |
| 44 |
resources consumed by static file requests aren't trivial once you |
| 45 |
realize that the big problem is with the number of concurrent |
| 46 |
requests...so it's best if those can be snapped up by something else, first. |
| 47 |
|
| 48 |
I've been running squid in front of my server for a few years. I've been |
| 49 |
eyeing CloudFlare, though; they're a CDN that behaves like a reverse |
| 50 |
proxy. You point their system at your server, your DNS at their system, |
| 51 |
and they'll do the heavy lifting for you. (And far better than having |
| 52 |
your own singular caching server would. I've worked at a CDN, and what |
| 53 |
they accomplish is pretty slick.) |
Archives