FastCGI over local network

[Igor Clark]

Ah, so that new static content servers don't need to be contacted  
through the front-end nginx. Thanks, that's a good suggestion. It may  
have some implications for the Flash "security" model, but most likely  
nothing that can't easily be worked out.

Any thoughts about the FastCGI aspect welcome too!

Bests
i

On 1 May 2008, at 18:43, Roger Hoover wrote:

> You might consider hosting your static content on a separate  
> subdomain.  If you have enough hardware, you can have dedicated  
> nginx boxes just for the images + swfs.
>
> On Thu, May 1, 2008 at 7:28 AM, Igor Clark <igor at pokelondon.com>  
> wrote:
> Hi there,
>
> We're building a mainly Flash site which communicates with a PHP  
> gateway via AMF over HTTP to get and set database information. The  
> app's requests will be something like 50% flat files, and the other  
> 50% will be PHP. At the beginning of the project we expect a lot of  
> SWF requests as we'll be serving rich ads trafficked via some big  
> portal sites.
>
> I'm planning an nginx front-end which serves flat content and passes  
> PHP requests to a PHP app server(s) on a local network over FastCGI.  
> The database will reside on a separate host. The idea is obviously  
> that if the app server struggles we can add more, and possibly extra  
> nginx servers to help take the load of image/SWF serving if necessary.
>
> In the past, I've only done this with nginx and PHP residing on the  
> same host.
>
> Is FastCGI good to do this without introducing problems, or should I  
> do something like:
>
> nginx   <--HTTP reverse proxy-->        (nginx+PHP)
>
> Intuitively it seems a bad idea to introduce extra processing, but  
> we haven't done multi-box setups with FastCGI this way before, so I  
> thought I'd check if that or some other approach might be better.
>
> I'd be grateful for any opinions!
> Igor
>
>

--
Igor Clark • POKE • 10 Redchurch Street • E2 7DD • +44 (0)20 7749 5355  
• www.pokelondon.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080502/1b6d8518/attachment.html>