Re: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks)
Issac Goldstand wrote: I think I got it... I was under the understanding that each fireman could only hande 1 bucket at a time, but there could be up to as many buckets as firemen on the stack at any given time... Do you know why it's like that? a limitation of the current mpms, there is only one thread/process for the whole pipeline of stages (filters/handlers). You could benefit from a real pipelining on an SMP machine. In any case we rather discuss this on the list. Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread... there is a talk about async I/O mpms for 3.0, or later 2.x This sounds like our many buckets with firemen scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space. But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources. The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a constant flush + buffer filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you? Issac
Re: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread... On the opposite, IMHO this is very ON topic, since that's the core of the 2.0. there is a talk about async I/O mpms for 3.0, or later 2.x This sounds like our many buckets with firemen scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space. That's the real pipeline. But it'll be only useful if you have many CPUs. I remember reading somewhere, that on a single CPU sequential processing might be faster rather than pseudo-parallel, because of the context-switch overhead. Though admittedly it's much smaller with threads, but depends on the implementation. Now, nothing prevents you from developing your own mpm right now or at any time latter that will do what you want. It's actually much easier that it seems to be because a big chunk of functionality is abstacted away. So it's not like writing an Apache server from scratch. I admit that I haven't written my own mpm yet and that's the impression that I have from reading posts at httpd-dev. But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources. Yes and no. Remember that our perl interpreters live in a separate pool of threads, so if we can release them asap, they can go and serve more requests, while the filters do whatever they do. Since the perl interpreters don't reside on the same thread that serves the connection. Though you are correct that the response handler won't be released until the filters will be done. So we need to think of some trickery to release the response handler earlier. The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a constant flush + buffer filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you? Sure, there is nothing wrong with front/end backend setup, it just makes things a bit more complicated to setup and maintain. So if we can provide an alternative solution that requires only one server, that would be cool. That's said let's worry first to get the core things working first and if you want to play with optimizations please go ahead and hack away :) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks)
- Original Message - From: Stas Bekman [EMAIL PROTECTED] Cc: Ask Bjoern Hansen [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 11:07 AM Subject: default Content-Length calculation has been removed in 2.0 (was Re: mod_perl 2.x vs. mod_perl 1.x benchmarks) Actually, returning to Issac's question regarding releasing the handler early, you need a slightly modified version of the cl filter to do that. Since it's already buffering the data, you just want to do this unconditionaly. How do you mean unconditionaly? BTW: I'm wondering whether the solutnio for the whole buffering thing is write a buffer filter or is this something that should be done internally within the brigades? After all, once the [mod_perl] response handler (or filter) passes the EOS bucket, it's not needed anymore, and who cares if the other filters are ready or not? Stas, it sounded to me like you were suggesting something like: mod_perl handler/filter---Filter API---buffer filtercore-outputclient The assumption is that if bufer_filter slurps up the data, it will release the previous filters' resources, but I think that's kinda backwards thinking. As far as I understand, the only buffer you EVER have to worry about is the data coming IN to your filter. Once you pass the buckets along, you never have to worry about them again. 2 conclusions on this (my thought process included :-)): 1) The seemingly correct thing to do here would be to ensure that a handler/filter's resource pool (and entire thread?) is cleaned up as soon as it's done running. I think the latter is true, and to do this properly, Apache'd really have to give each filter plugged into each request it's own running thread. That's gonna add lotsa overhead. Maybe just a flag to request it's own thread if the module author/user is expecting their handler/filter to really use heavy resources (like an on-the-fly image processing filter for example). That way, heavy modules can get their own resources for when their eneded and release them ASAP. 2) The flipside of this is that a heavy module (like discussed above) *would* need this buffer filter; but it would want the buffer to slurp up the data coming *in*. The idea would be to let these heavy modules *create* themselves only when the data is ready (to optimize resource allocation/usage). The problem with this is that it's useless. Each request, as I understand, requires each filter in the chain to register itself in the bucket brigade chain right at the offset - which means that the private thread idea can't work since it will have to create the thread at the beginning of the request anyway - certainly before the data is ready. Comments? Issac
Re: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
[Issac's view snipped] Rather than commenting on your view Issac, please allow me to try again to explain how I think it works, hopefully more clear this time: Let's forget for a moment about buckets inside bridades, and call the brigades themselves entities that are passed along. Now think of a realworld fireman water bucket brigade, everybody passes a bucket (entity) and usually there are several buckets (entities) moving at the same time. Now let's imagine that the first man in the brigade picks a new bucket only when the last man has poured its bucket out. So at any given moment there is only one bucket (entity) moving along the brigade. This is exactly the situation with httpd. In the current httpd filtering model one entity is moving along the filters stack and no new entity will enter the stack, before the one on the stack will leave it (go to the client if we are talking about output filters). I didn't want to use the httpd buckets and brigades in this example, because they make my comparison confusing. In the real world there is one brigade and many buckets. In httpd, there are many bridages that are moving along the stack of filters (and each brigade have one or more buckets, which are irrelevant to this particular discussion). Hope this clearifies the picture. The conclusion: If the filter stack is busy processing some data and the response handler hasn't finished sending the data, it'll block waiting for the filter stack to return and only then hand over the next chunk of data. At least that's how it appears to the filters. Now if you want to play with it, it should be a trivial thing to do. Just take some response handler that generates a lot of data in a loop and prints some logs to STDERR on each iteration, then insert a filter that passes the brigades unmodified (like MyApache::FilterSnoop does) but has a 'sleep 3' statement. I expect that the response handler will block on each sleep. I hope that my understanding was correct :) Also allow me to suggest that reading the following section: http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter and trying the MyApache::FilterSnoop module at work should clearify a lot. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
.--[ Ask Bjoern Hansen wrote (2002/09/19 at 01:47:39) ]-- | | On Wed, 18 Sep 2002, Josh Chamas wrote: | | [...] | So I run it again with ServerTokens Min, and get the same results. :) | Still something different on the mod_perl headers, looks like mod_perl | 2.x is setting Content-Length where it didn't use to. | | The details evade me, but I recall something about how the buckets | work in the httpd that makes httpd 2.0 always know (and set) the | Content-Length. | | There was discussion about changing it; but I don't remember the | outcome. | | (yes, it has (had?) some implications for how data can be streamed | from the proxy in such a setup, which was the reason for changing | it. Indeed it could be that it was only affecting the proxy. Did I | mention that I forgot the details?). :-) | | - ask | | -- | ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do(); `- Would this mean that a handler that currently cannot know it's Content-Length: ( due to the way it handles templates ) would not have to be re-written on Apache/mod_perl 2.0? Wouldn't this make it only necessary to determine the Last-Modified: header to make caching work? I've been wanting to put front-end caches on my mod_perl handlers for some time but the code changes necessary to generate these two headers have kept me from it for some time. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org -
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
On Wed, 18 Sep 2002, Josh Chamas wrote: [...] So I run it again with ServerTokens Min, and get the same results. :) Still something different on the mod_perl headers, looks like mod_perl 2.x is setting Content-Length where it didn't use to. The details evade me, but I recall something about how the buckets work in the httpd that makes httpd 2.0 always know (and set) the Content-Length. There was discussion about changing it; but I don't remember the outcome. (yes, it has (had?) some implications for how data can be streamed from the proxy in such a setup, which was the reason for changing it. Indeed it could be that it was only affecting the proxy. Did I mention that I forgot the details?). :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
On the Apache 2.0 note, 2.0 breaks terribly when it has to proxy chunked data. It strips the chunk length and does not replace it with a Content-Length. Bug is filed but no one in the Apache group seems to want to play with it :( Just a warning for those of you who may potentially be doing proxy for chunked data. John- On Thu, 19 Sep 2002 01:47:39 -0700 (PDT) Ask Bjoern Hansen [EMAIL PROTECTED] wrote: On Wed, 18 Sep 2002, Josh Chamas wrote: [...] So I run it again with ServerTokens Min, and get the same results. :) Still something different on the mod_perl headers, looks like mod_perl 2.x is setting Content-Length where it didn't use to. The details evade me, but I recall something about how the buckets work in the httpd that makes httpd 2.0 always know (and set) the Content-Length. There was discussion about changing it; but I don't remember the outcome. (yes, it has (had?) some implications for how data can be streamed from the proxy in such a setup, which was the reason for changing it. Indeed it could be that it was only affecting the proxy. Did I mention that I forgot the details?). :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
mod_perl 2.x vs. mod_perl 1.x benchmarks
Hey mod_perl users, I just did a benchmarks to compare mod_perl + apache versions 1 2. What I find striking is that without any optimizations, the v2 mod_perl apache are faster. I'm really blown away, as I was expecting the new versions to be slower with v1 configurations. Here's the numbers in brief: Apache/1.3.26 + mod_perl/1.27 + perl 5.6.1 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1420.710 70.390.000704 322 5062 mod_perl handlerhello.ben 942.510106.100.001061 206 7660 Apache/2.0.40 + Perl/v5.8.0 + mod_perl/1.99_05-dev Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1619.710 61.740.000617 290 5912 mod_perl handlerhello.ben 1210.110 82.640.000826 194 11070 The mod_perl benchmark was run with the Apache::compat layer and the perl-script directive in Apache 2.x, so it was not optimized. Further, the configs between the web servers were identical on my linux server during the benchmarks, so Apache was not optimized at all for v2. on top of that, the mod_perl2 was loaded as a DSO while mod_perl1 was compiled statically. Again, I'm amazed. Obviously the apache mod_perl development teams have done an awesome job in building this next generation server. Regards, Josh
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
Josh Chamas wrote: I just did a benchmarks to compare mod_perl + apache versions 1 2. Cool. Any idea why bytes/hit is lower on apache 2? Are some headers being omitted? - Perrin
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
Perrin Harkins wrote: Josh Chamas wrote: I just did a benchmarks to compare mod_perl + apache versions 1 2. Cool. Any idea why bytes/hit is lower on apache 2? Are some headers being omitted? Looks like its the Server tokens, see below. 32 bytes! Maybe on a benchmark this small, this makes a difference? *sigh* So I run it again with ServerTokens Min, and get the same results. :) Still something different on the mod_perl headers, looks like mod_perl 2.x is setting Content-Length where it didn't use to. Apache/1.3.26 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1417.5 42531 30.000.000705 250 5000 mod_perl handlerhello.ben 939.1 28181 30.010.001065 134 7244 Apache/2.0.40 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1602.4 48236 30.100.000624 250 6756 mod_perl handlerhello.ben 1177.3 36062 30.630.000849 154 11648 -- Josh === Old headers throwing static HTML bytes off HTTP/1.1 200 OK Date: Wed, 18 Sep 2002 20:14:59 GMT Server: Apache/2.0.40 (Unix) mod_perl/1.99_05-dev Perl/v5.8.0 Last-Modified: Sun, 10 Dec 2000 03:43:21 GMT ETag: 153814-c-7363e840 Accept-Ranges: bytes Content-Length: 12 Connection: close Content-Type: text/html HTTP/1.1 200 OK Date: Thu, 19 Sep 2002 01:02:20 GMT Server: Apache/1.3.26 (Unix) Resin/2.1.2 PHP/4.2.1 mod_perl/1.27 mod_ssl/2.8.9 OpenSSL/0.9.6b Last-Modified: Sun, 10 Dec 2000 03:43:21 GMT ETag: 153814-c-3a32fbd9 Accept-Ranges: bytes Content-Length: 12 Connection: close Content-Type: text/html
