On Nov 1, 10:06 am, Graham Dumpleton <[EMAIL PROTECTED]>
wrote:
> On Nov 1, 8:44 am, "Naitik Shah" <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Fri, Oct 31, 2008 at 1:01 PM, Naitik Shah <[EMAIL PROTECTED]> wrote:
> > > On Thu, Oct 30, 2008 at 10:58 PM, Graham Dumpleton <
> > > [EMAIL PROTECTED]> wrote:
>
> > >> In respect of having nginx in front, one of the over benefits of that
> > >> was that nginx could have been quite selective about the URLs that it
> > >> was proxying. That way if you get a SPAM bot or similar hitting the
> > >> site, it could have been blocked at nginx without even going through
> > >> to Apache/mod_wsgi, presuming that such a bot was hitting known URLs
> > >> for security holes in PHP packages or the like. One may also have been
> > >> able to filter SPAM bot traffic at nginx level through user agent or
> > >> other things. Thus, nginx could have further been used as a filter
> > >> point to limit traffic going through to Apache.
>
> > > That's interesting. I wonder if Apache could be made to reject such
> > > requests. I like the current simple setup - I want to avoid adding Nginx
> > > to
> > > the mix :)
>
> > I looked into this approach a bit, and it seems there's more benefits - the
> > one that stood out is that slow clients will first be handled by Nginx, and
> > the request will only be handed off to Apache after Nginx is done receiving
> > it. Thus, holding the Apache process for less amount of time. I'll look into
> > this in more detail once I have the Apache setup working as I like.
>
> Yes, in theory that as well.
>
> This is where one would have thought the Apache event MPM might help,
> but from what I remember at look at code, the special event worker
> thread only deals with accepting the new connection (before handing it
> off to another thread) and later perhaps (can't remember) dealing with
> management of keep alive connections.
>
> In other words, don't believe the Apache event MPM uses the event
> worker thread to at least read in the HTTP request header before
> handing it off to another thread for processing. Thus, request has
> already been handed off to its own thread for that part of the request
> which may arrive slow, ie., the HTTP request information. I will need
> to check again though if what I remember is correct. :-)
>
> This is where nginx is better, as the event model can handle all that
> HTTP request header reading in single thread by multiplexing it based
> on availability of data. Therefore you don't suffer the Apache
> overhead of memory usage for threads sitting there waiting for slow
> data to come for HTTP request header.
>
> Anyway, before you quote me on how Apache event MPM works, I better go
> check.
I think me memory is okay. Comments in event MPM code say:
* This MPM tries to fix the 'keep alive problem' in HTTP.
*
* After a client completes the first request, the client can keep the
* connection open to send more requests with the same socket. This
can save
* signifigant overhead in creating TCP connections. However, the
major
* disadvantage is that Apache traditionally keeps an entire child
* process/thread waiting for data from the client. To solve this
problem,
* this MPM has a dedicated thread for handling both the Listenting
sockets,
* and all sockets that are in a Keep Alive status.
and looking at code it does indeed seem to send accept socket direct
into worker thread queue for processing before any data actually read.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
