| 1 |
On 03/07/2013 04:34 PM, Grant wrote: |
| 2 |
>> Michael's proxy suggestion is excellent too - I use nginx for this |
| 3 |
>> a lot. It's amazingly easy to set up, a complete breath of fresh |
| 4 |
>> air after the gigantic do-all beast that is apache. Performance |
| 5 |
>> depends a lot on what your sites actually do, if every page is |
| 6 |
>> dynamic with changing content then a reverse proxy doesn't help |
| 7 |
>> much. Only you know what your page content is like. |
| 8 |
> |
| 9 |
> It sounds like having apache serve dynamic .html pages and nginx |
| 10 |
> serve images on the same port means turning apache into a proxy for |
| 11 |
> nginx which I'm hoping isn't too difficult. Could this pose any |
| 12 |
> problems for an ecommerce site? |
| 13 |
|
| 14 |
|
| 15 |
|
| 16 |
> Changing completely from a user-facing apache to a user-facing nginx |
| 17 |
> sounds fraught with peril. |
| 18 |
|
| 19 |
Yet this is the way it's done. If you have apache serve as a proxy for |
| 20 |
nginx, you gain absolutely *nothing*; every inbound connection still |
| 21 |
takes Apache resources, and that's exactly what you need to introduce a |
| 22 |
proxy to alleviate. |
| 23 |
|
| 24 |
Think of it like phone lines. Let's say you're getting fifteen phone |
| 25 |
calls an hour. It's too much. You hire a secretary named nginx to screen |
| 26 |
your calls for you and handle the simple responses like "has he changed |
| 27 |
his mind?" |
| 28 |
|
| 29 |
You're *supposed* to have the secretary take all the calls, and then |
| 30 |
pass along the calls to you that really need your attention. |
| 31 |
|
| 32 |
If you stick apache in front of nginx, rather than the other way around, |
| 33 |
what you're instead doing is having everyone call you, and then put the |
| 34 |
secretary you hired on speakerphone while she takes the call... |
Archives