Re: Apache 2?
GC == Grant Cooper [EMAIL PROTECTED] writes: GC Is there any documention of a HOWTO or a tutorial about a lightweight GC front-end proxy that loads the data from the mod_perl try this: perldoc mod_perl_tuning It comes with mod_perl, conveniently. Nobody has sent me any updates in two years, so I assume nobody has come up with anything better ;-) I still use the proxypass thing with front end running SSL and back end doing all the heavy lifting in Template Toolkit. I call that my application server to let the buzz-word compliant be happy. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Apache 2?
On Tue, 2002-11-26 at 05:15, Philip Mak wrote: Is the 'front end' and 'back end' apache servers on the 'same box'? My problme is that I had one web server. and I did the FE and BE bit (BE being on the loop back address). to free up some major resources since mod_perl apache gets huges. I didn't need 20meg process serving up 2K images :) and had about 20 to 30 smaller apache process doing the 'static' content serving. I'm currently running Apache2 in a development enviroment. Going to be upgradeing my web servers with 2.0. Most sites will work nicly. I have found that the memory resource problem doesn't excist with 2.0 when you compile with 'worker' or fully threaded. I'm running 2 processes of apache and each of htem have like 20 threaded. performce seems good with just running one apache server. didn't do any real load testing, but I'm sure 2.0 is going to blow 1.3.x away. -- Jason These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Re: Apache 2?
On Sat, Nov 30, 2002 at 12:45:50PM -0500, Jason Czerak (Jasnik) wrote: Is the 'front end' and 'back end' apache servers on the 'same box'? My problme is that I had one web server. and I did the FE and BE bit (BE being on the loop back address). to free up some major resources since mod_perl apache gets huges. I didn't need 20meg process serving up 2K images :) and had about 20 to 30 smaller apache process doing the 'static' content serving. Yes, that's exactly what I do. I have found that the memory resource problem doesn't excist with 2.0 when you compile with 'worker' or fully threaded. I'm running 2 processes of apache and each of htem have like 20 threaded. performce seems good with just running one apache server. didn't do any real load testing, but I'm sure 2.0 is going to blow 1.3.x away. Well, there's multiple benefits of running a separate frontend and backend server: 1. As stated above, the static HTML/GIF/JPG/etc. files don't have to be served by the heavyweight mod_perl process. 2. If the backend is serving a large file, the frontend can retrieve the entire file from the backend and free it up immediately, so that a client with a slow modem will not tie up the backend for the time it takes to download. 3. If you have different sites (presumably owned by different people) on your server, all the backend servers can execute with different userids so that the backend server of one site doesn't have to be able to read the files of another site. And, everyone can change their own server configuration. We know that Apache 2 confers benefit #1 without needing a separate frontend and backend. Benefit #2 seems to be planned, but isn't here yet. ...What about benefit #3?
Re: Apache 2?
3. If you have different sites (presumably owned by different people) on your server, all the backend servers can execute with different userids so that the backend server of one site doesn't have to be able to read the files of another site. And, everyone can change their own server configuration. We know that Apache 2 confers benefit #1 without needing a separate frontend and backend. Benefit #2 seems to be planned, but isn't here yet. ...What about benefit #3? #3: --with-mpm=perchild which is a work in progress http://httpd.apache.org/docs-2.0/mod/perchild.html notice the new AssignUserID and ChildPerUserID directives which now can set different uid/gid for each group of processes/threads. __ 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: Apache 2?
Issac Goldstand wrote: - Original Message - From: Stas Bekman [EMAIL PROTECTED] . Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler start of buckets Filter API End of buckets Core Output client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something? From a quick read through: server/core.c:static apr_status_t core_output_filter(ap_filter_t *f, apr_bucket_brigade *b) I don't think core_output_filter does anything to buffer up the data and release the handler. The only buffering it does is if it doesn't have *enough* bytes to send so it waits for the next brigade. In order to understand how the new model works you really have run the snooping filter and study the output. The important outcome that you gain is that filters are called in a pipeline, i.e. the response handler sends a portion of data to the first filter, which immediately passes that data to the next filter, and so on, while all previous filters that have already passed the first chunk await for the latter filters to return. That's my understanding so far, please correct me if I'm wrong. So if you want to release the handler asap, you need a filter that will buffer up the data and feed it to the remaining filters at the speed they request. It should probably be inserted just before the core_output_filter, so all the processings will be already completed by that time. Think of it as an extension to the core_output_filter which buffers things up. And the cool thing is that you can inject it only when you want it, e.g. you don't want it for non-mod_perl requests. And of course it's not mod_perl specific like you've mentioned, but I don't really know of any other producers that consume a lot of memory and therefore for which we want to minimize their number and keep them busy for real all the time. __ 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: Apache 2?
On Tue, 26 Nov 2002, Philip Mak wrote: On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote: What do yo mean a modem will tie up the Server? I've never heard this before. Let's say you have a mod_perl page that returns a 100k document, and a 28.8k modem downloads that document. The mod_perl process that is serving that document will be tied up until that modem finishes downloading the document, which is inefficient since the mod_perl processes take up a lot of memory. A lightweight front-end proxy that loads the data from the mod_perl process all at once and then feeds it to the modem would save memory. Things are bit complicated. Kernel can buffer some part of document and there is Apache feature named lingering close. For example, client's speed is 3K/s. If you have 64K kernel TCP send buffer then mod_perl will write 64K very soon but it will wait about 12 seconds to write other 36K. And after mod_perl will have written these 36K it will wait 2 second in lingering close. Even you increase kernel TCP send buffer (it's not always good idea) to 100K anyway you still 2 second lingering close delay for slow clients. Note that you never see lingering close state in /server-status (at least in Apache 1.3) - such processes are marked as idle but they are not really idle - they can not handle requests. Also lingering close time is not accounted in %T directive in the log. You can only estimate the count of Apache processes that is in linegring close state using netstat utulity and looking for FIN_WAIT2 socket states. Igor Sysoev http://sysoev.ru/en/
Re: Apache 2?
- Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Philip Mak [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 27, 2002 2:24 AM Subject: Re: Apache 2? . Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler start of buckets Filter API End of buckets Core Output client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something? Issac
Re: Apache 2?
What do yo mean a modem will tie up the Server? I've never heard this before. - Original Message - From: Philip Mak [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 26, 2002 2:15 AM Subject: Apache 2? These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now?
Re: Apache 2?
On Tue, Nov 26, 2002 at 11:40:00AM -0800, Grant Cooper wrote: What do yo mean a modem will tie up the Server? I've never heard this before. Let's say you have a mod_perl page that returns a 100k document, and a 28.8k modem downloads that document. The mod_perl process that is serving that document will be tied up until that modem finishes downloading the document, which is inefficient since the mod_perl processes take up a lot of memory. A lightweight front-end proxy that loads the data from the mod_perl process all at once and then feeds it to the modem would save memory.
Re: Apache 2?
On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote: Is there any documention of a HOWTO or a tutorial about a lightweight front-end proxy that loads the data from the mod_perl I wrote a guide a while back on how to install mod_accel and mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it will work with Apache 2.x. http://www.aaanime.net/pmak/apache/mod_accel/
Re: Apache 2?
Philip Mak wrote: On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote: Is there any documention of a HOWTO or a tutorial about a lightweight front-end proxy that loads the data from the mod_perl I wrote a guide a while back on how to install mod_accel and mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it will work with Apache 2.x. http://www.aaanime.net/pmak/apache/mod_accel/ and of course your perl.apache.org docs: http://perl.apache.org/docs/1.0/guide/strategy.html http://perl.apache.org/docs/1.0/guide/scenario.html __ 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: Apache 2?
Philip Mak wrote: These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now? Theoretically with mod_perl 2.0 with Apache2.0 threaded mpms architecture the need for the front-end/back-end solution has gone away, because now you can have a few threads running Perl interpreters and many other threads which don't run Perl interpreters. So the front-end and the back-end can now co-exist on the same server. Practically we still need to work out the details. Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. The prototype can be written in perl and then probably better ported to C. You can use the MyApache::FilterSnoop (http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter) to trace the data propogation through filters. Of course first you need to understand the 2.0 architecture, which is discussed in details at http://perl.apache.org/docs/2.0/user/index.html (Part IV: mod_perl Handlers). As this is a new documentation please help to improve it. Especially if you have more interesting examples, than the ones I've come up with. __ 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: Apache 2?
Philip == Philip Mak [EMAIL PROTECTED] writes: Philip Let's say you have a mod_perl page that returns a 100k document, and a Philip 28.8k modem downloads that document. Philip The mod_perl process that is serving that document will be tied up Philip until that modem finishes downloading the document, which is Philip inefficient since the mod_perl processes take up a lot of memory. A Philip lightweight front-end proxy that loads the data from the mod_perl Philip process all at once and then feeds it to the modem would save memory. Yeah, I did this to stonehenge.com about five months ago, and am now handling about 3-4 times the traffic for the same loadav. All on one machine. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: apache 2 mod_perl 2 Apache::DBI
On Sun, 9 Jun 2002, Yuri A. Kabaenkov wrote: Hello, How can i install Apache::DBI module with mod_perl 2? I'm not sure what the current status of this is, but see the discussion of Apache::DBIPool at http://perl.apache.org/release/docs/2.0/user/overview/overview.html. best regards, randy kobes
Re: Apache 2 opportunity
On Sun, 2 Jul 2000, Francesco Pasqualini wrote: I think in the current version of modperl there is an important feature missing. At this time is not possible to share resources between apache childs and so we can not use "really" persistent DBI coneection. What I intend is the possibility to store a DBI connection in the $Session hash (Apache::ASP or Apache::Session). In this way we can start a DB connection for each user session and we can have different application upon differnet DB. The connection is started when the user session start, is maintenied in memory (in the apache main process ?),it is visible to the apache childs (threads) and is destroied at session end. With the efforts (syntax tree sharing between threads) necessary to port modperl to apache 2, will be possible to implement such a feature ? it will be possible to share db connections between threads. but 2.0 is hybrid, there are still multiple processes, you cannot share db connections between them, without something like DBD::Proxy.
