httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zeev Suraski <>
Subject Re: work in progress: mpm-3.tar.gz (fwd)
Date Sun, 20 Jun 1999 19:15:23 GMT
On Sat, 19 Jun 1999, Dean Gaudet wrote:

> On Sun, 20 Jun 1999, Zeev Suraski wrote:
> To be honest, this sounds like a bug in your code.  Apache never
> guaranteed to call your code from the same thread -- in 1.x it built your
> structures in one process, and then executed them in another process... 
> nevermind thread... 

It's not a bug, it's just that this code never ran in a multithreaded
Apache environment.  That sort of stuff is completely transparent in the
multiprocess environment in Apache 1.x.

> Yeah I know it's not the end of the world -- this is me saying "if you
> follow me down this path, we can kick ass on performance".  But there are
> many many ways to handle this while leaving my restriction in the API...
> for example, you could choose to manage a pool of PHP threads within each
> apache process -- and your module would simply synchronize the apache
> thread with your threads.  That's not as far-fetched as it sounds --
> that's really similar to the jserv model, where the processing occurs
> in another threaded process.  You won't be the only people with this
> requirement, which is why a generic server-server protocol would be
> nice...  and hey, an HTTP/1.1 proxy would solve that :)
> But I really want the php module to be able to take advantage of the async
> stuff -- because php is a real world application, unlike the benchmark
> crap that got me off my butt and started me working on this again.
> For example, I want to provide the primatives so that php can buffer
> responses up to 64k (configurable), and send those out with async support;
> for longer responses I'm happy consuming a thread forever.
> It'll require a little bit of work in the php response handler, and it'll
> mean that the log_request phase will almost certainly happen in a
> different thread.  But I don't expect the changes to be difficult...
> Just so that we're all on the same page, this is what I'm aiming for:
>    - new connection arrives at port 80
>    - mpm does an accept and builds a conn_rec
>    - thread 123 is chosen to process conn_rec
>    - thread 123 goes through the apache API phases:
> 	post_read_request
> 	header_parser
> 	translate_handler
> 	ap_check_user_id
> 	auth_checker
> 	access_checker
> 	type_checker
> 	fixer_upper
>     - thread 123 calls the response handlers
>     - a response handler determines that the async engine can
>       do the job
>     - the stack unwinds from the apache core up into the mpm
>       (thread 123 is no longer handling this connection, it may
>       immediately begin servicing another connection)
>     - the mpm sends the response asynchronously
>     - at some point in the future the response has been sent
>     - thread 234 is chosen to handle the "completion" event
>     - thread 234 notices that the entire response has been sent, so
>       it calls the logger (it may have been doing a range-request,
>       and decided to send more ranges asynchronously)
>     - thread 234 proceeds with keep-alive processing, perhaps this is
>       a persistent connection
>     - if it is, we could repeat the above process, and send another
>       async response and end up back here again
> So we have asynchronous behaviour only in the handler -- and even then
> it only happens with modules that support async behaviour.  The logger
> is the most obvious thing which is going to be called "out of thread".
> And since HTTP doesn't have any state from request to request within
> one connection, I don't think we need to debate about the fact that
> different requests on one connection may occur within different threads.
> That's what I'm aiming for.  The only reason I stated that the thread
> may switch in any phase was to try to help folks like Tony who asked for
> async DNS...
> I think we're all on the same page now :)  I'm not going to break your
> stuff in terrible ways, from what you've said your stuff will work just
> fine within this model.  We just need to tweak our API a bit.

Well, if you're optimistic, I'm optimistic as well :)  I'll wait a bit
until the model is more mature (and until I have more time) and see what
can be done to help PHP take advantage of this asynchornous behavior.  If
it can be done, I don't mind giving users better performance in Apache
than they'd get from IIS (to say the least :)


Zeev Suraski <>
For a PGP public key, finger

View raw message