mod_perl memory leaks on Windows
Hi, I'm using ActiveState Perl v5.6.1 MSWin32-x86-multi-thread, Apache 1.3.26 and mod_perl 1.27 ( as DSO ) on Windows 2000 with 256MB of RAM. I configurel location in a simple way, showed below: -- a piece from httpd.conf Location /mod_perl Options +ExecCGI AddHandler perl-script .pl PerlHandler Apache::Registry /Location --- Every thing seems to run fine. But when I went to check the performance of mod_perl pages, I noticed that it was leaking memory. I simplified situation as much as i can. Details are as follows : After a fresh restart, I started Apache/mod_perl. Then i issued a little stress test using simple perl script with LWP::Simple. I ran a performance test on /mod_perl/index.pl page for 10 minutes. The source code of that page is given below : - #!/perl/bin/perl use CGI qw(:all); print header; print Hello, World!; - After 10 mintues of execution, the memory consumption of Apahce.exe had jumped from approx 5 MB to 120MB ( virtual memory ). I ve noticed, that Apache child grown by 4-8kb per each request. Since then I've tried many different versions of Apache/mod_perl (1.24/mod_perl 1.26 too) including the one available as a binary distribution at perl.apache.org. All the mod_perl scripts sleak memory. I know that mod_perl on Windows is a development version but still this memory leak thing is pretty obvious and should have been taken care off. Please let me know if this has something to do with my Apache/mod_perl on Windows or is it that mod_perl on Windows is buggy. -- Best regards, Andrey mailto:[EMAIL PROTECTED]
RE: Apache vulnerability: update of uwinnipeg win32 packages planned?
Greetings. Randy Kobes wrote: [...] There is still some demand for the all-inclusive apache/perl/mod_perl perl-win32-bin-x.x.exe binary packages we have, Uhm, yes I would be in that audience :) but I wasn't planning on making a new one of those until perl-5.8 is officially released. Any idea on when that may happen? In alternative, do you have any automated build environment for producing one of those? I would be willing to lend some CPU/man time to make that happen. Cheers, alf
RE: getting node values from XML::Parser
ok, it's 1am, time to ask. I am able to parse thru XML (using XML::Parser, Expat) to retrieve the element I am interested in with: my $line= $parser-current_line; $data =~ s/\n/n\t/g; but how to get the element value?? thanks for advice, md __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
Re: Apache vulnerability: update of uwinnipeg win32 packages planned?
Alessandro Forghieri wrote: but I wasn't planning on making a new one of those until perl-5.8 is officially released. Any idea on when that may happen? My wild guess is on July 24, 2002. __ 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: getting node values from XML::Parser
[EMAIL PROTECTED] wrote: ok, it's 1am, time to ask. I am able to parse thru XML (using XML::Parser, Expat) to retrieve the element I am interested in with: my $line= $parser-current_line; $data =~ s/\n/n\t/g; but how to get the element value?? thanks for advice, md is it just me or others think too that someone has started to advertise the address of the mod_perl mailing list as the place Ask about anything, any time, we know the answers. Doh! I suggest renaming the address of the modperl list to: [EMAIL PROTECTED] [hope that spamming engines will pick that one and spread the word around fast] __ 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
ANNOUNCE: Embperl 2.0b8
The URL
ftp://ftp.dev.ecos.de/pub/perl/embperl/Embperl-2.0b8.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GR/GRICHTER/Embperl-2.0b8.tar.gz
size: 628343 bytes
md5: d089a86671a0c559b77f107a4e6d67c9
I have done a lot of fine tuning and error fixing since 2.0b7. Also Embperl
now supports mod_perl 2.0 with prefork MPM (threaded MPM will require Perl
5.8.0). The docs are moveing towards 2.0, but some features are still only
documentent in README.v2.
Everybody who is running a copy of Embperl 2, should upgrade to 2.0b8,
because this will improve stabibility.
Enjoy
Gerald
Changes since 2.0b7:
2.0b8 (BETA) 25. Juni 2002
- exit can now exit the whole request. When called without argument
it exits the current component, like before, when called with argument
it exits the whole request.
- Added support for Apache 2.0 / mod_perl 2.0 (prefork MPM).
- Added the possibility to catch the output of a sub-request
(e.g. a CGI script, Java or PHP output) when running under Apache 2.0
- when setting $r - param - filename in an application object
to a relativ path it is interpreted relativ to original request
- Start to catch up with new features of Embperl 2 in the docs. Added
Config.pod for configuration and calling.
- Lots of improvments in the new Embperl website, which serves as best
example for using the new Embperl 2 features. It's part of the
distribution
and can be found under eg/web. See eg/web/README.
- fixed bug with setting of escmode and print Out reported by
Eric-Olivier Le Bigot.
- fixed incorrected escaping inside of an URL when expanding an hash
or array reference. Reported by Axel Beckert.
- fixed possible endless loop when expanding hash or array inside of
an URL.
- fixed a segfault that occured when source file encryption was enabled.
Reported by Edwin Ramirez.
- fixed a segfault that occured when no input file is given. Reported by
Edwin Ramirez.
- fixed a segfault that occured on solaris when input comes from memory.
Reported by Mike Wesemann.
- readd possibility to build version with and without Apache support
on windows.
- Remove Content-Length: 0 HTTP-Header in CGI Mode
- Fixed segfault when replacing an attribute. Reported by Michael
Stevens.
- Fixed random segfaults, that had occured when Perl had reallocated it's
internal Stack.
- When apache is started with -D EMBPERL_APDEBUG, it outputs a
configuration trace.
- When file is not found, Embperl::Object now returns status 404, instead
of 500. Reported by Cameron McBride.
- When optReturnError is set, Embperl::Object now really returns the
error code.
Reported by Cameron McBride.
- Fixed a reference count error when using the import parameter. Reported
by Michael Smith.
- Fixed string reference counting problem in RTFPOD syntax.
- Fixed a segfault that had occured when a file with a syntax error is
compiled the second time within the same process. Reported by
Michael Smith.
- removed do { } around expressions of [+ +] blocks inside urls, because
this cost performance and now all [+ +] behaves the same. Reported by
Michael Smith.
- make stop now works also on windows.
- make start, which can be used to view/test the Embperl website localy,
now displays the URL how to request the site.
- libxslt does correct error reporting now.
- libxslt output encoding is now recognized correctly.
- set Content-Length when sending error page, so Internet Explorer won't
show
his own error page.
-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131
WWW:http://www.ecos.de Fax: +49 6133 925152
-
RE: when to mod_perl?
At 9:52 Uhr +0200 25.06.2002, Alessandro Forghieri wrote: FastCGI has slightly better speed, but I have seen it hanging (and it does not look like support for FastCGI is going to be huge in the futuer), It took mod_perl ages (i.e. until mod_accel has come up) to get an as decent proxying setup as mod_fastcgi has already provided right from the beginning ;) Re hanging: I've seen it too about 2 years ago with dynamic fastcgi, but that bug had then been fixed, maybe you're talking about the same (and static fastcgi has never given me problems). Christian. -- Christian Jaeger +41 1 430 45 26 http://www.eile.ethz.ch - waiting for someone to take over (and off :)
Re: Apache:: module organization and getting it to work with PAUSE
Hi Tim, thanks for replying, At 22:33 23.06.2002, Tim Bunce wrote: Why am I adressing you? Because Randy suggested, and I agreed, that some kind of module listing in categories would be interesting for the modules and for the mod_perl community--probably having a page dedicated to mod_perl modules. However, we don't want one person to maintain such a category: just like PAUSE exists to avoid one person to take care of all CPAN modules, it would be preferable to get module authors to categorize their modules themselves. This can only be done satisfactorily with PAUSE, to handle password protection etc... So I'm wondering if this is doable: for example, on the Register namespace page, there could be a category called mod_perl modules, which would then bring you to a second page where you choose your mod_perl category. I'd be happy to see the Apache::* modules in section 15 (World Wide Web ...) moved into a new 'Apache' section (needn't be mod_perl specific, could include admin modules etc). I'm not sure how Andreas maintains 00modlist.long.html these days but there is clearly some 'sub-section' concept already in place (Apache PerlAuthzHandler modules, Apache PerlAccessHandler modules etc) Yes, but those came from the original mod_perl module list. so it seems very reasonable that PAUSE should allow users to select which sub-section their module should be listed in. You could almost call it a bug that it doesn't already support it. The UI change ought to be as simple as adding the subsections to the Module List Chapter drop-down list (that currently contains just the 24 existing section names) Yes, this would clearly be great. It's what I was hoping for. What do you think, Andreas? (assuming he gets this mail) .-- Per Einar Ellefsen [EMAIL PROTECTED]
Win32 Binarys
Where can I get a Win32 binary of mod_perl? I use Apache 1.3.26/ActivePerl Build 522. None of Randy Kobes' PPMs would Install and the newest pre-compiled zipped binary is for mod_perl 1.16. Thanks! http://www.sold.com.au - SOLD.com.au - Find yourself a bargain!
Re: Win32 Binarys
At 14:15 25.06.2002, [EMAIL PROTECTED] wrote: Where can I get a Win32 binary of mod_perl? I use Apache 1.3.26/ActivePerl Build 522. None of Randy Kobes' PPMs would Install and the newest pre-compiled zipped binary is for mod_perl 1.16. You probably want to get a new ActivePerl version. Build 522 is pretty outdated now. Newer binary versions of mod_perl won't install because they need ActivePerl 6xx. -- Per Einar Ellefsen [EMAIL PROTECTED]
Is mod_perl the right solution for my GUI dev?
Hello list, Please pardon me if it is not related to the list. We have a C application which runs on both SCO open server and Red Hat Linux with Oracle/Informix database. It is a text based application originally developed for CRDS box with UNOS. Now management needs a GUI for the text application.I have developed some report screens using Apache/Mod_perl/GD. They kind of liked it. Now they want to do a full fledged GUI. My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. Any suggestions on this will be really appreciated. Thanks, Ganesh.
Re: Is mod_perl the right solution for my GUI dev?
At 16:09 25.06.2002, Ganesan M wrote: Hello list, Please pardon me if it is not related to the list. We have a C application which runs on both SCO open server and Red Hat Linux with Oracle/Informix database. It is a text based application originally developed for CRDS box with UNOS. Now management needs a GUI for the text application.I have developed some report screens using Apache/Mod_perl/GD. They kind of liked it. Now they want to do a full fledged GUI. My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. The problem you're looking at is rather different: should you try and create a *web frontend* or should you create a normal GUI? Largely depending on the nature of your application, the answers will be different. I can't say much more without knowing more about what you're trying to do: but to me it seems like if you need GD to do the job, you should probably be looking at a standard GUI instead. This needn't be done in Java or VC++, you could use any programming language with a windowing library, like Perl with Tk (or Gtk or Qt bindings, but I don't know much about any of those) or anything else. My answer: it depends :) -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: when to mod_perl?
md wrote: I was just a bit worried about the amount of static content. In the past I've had a lot more hardware to work with and I never had to worry about it much. Static content is easy; just don't serve it from mod_perl. The proxy approach is good, and so is a separate image server (which you can host on the same machine). I've found thttpd to be an amazingly efficient server for images, but a slimmed-down apache does very well too. - Perrin
Re: mod_perl memory leaks on Windows
Andrey Prokopenko wrote: After a fresh restart, I started Apache/mod_perl. Then i issued a little stress test using simple perl script with LWP::Simple. I ran a performance test on /mod_perl/index.pl page for 10 minutes. The source code of that page is given below : - #!/perl/bin/perl use CGI qw(:all); print header; print Hello, World!; - After 10 mintues of execution, the memory consumption of Apahce.exe had jumped from approx 5 MB to 120MB ( virtual memory ). I ve noticed, that Apache child grown by 4-8kb per each request. Have you tried it without using CGI.pm? Have you tried writing a handler instead of using Apache::Registry? I know that mod_perl on Windows is a development version but still this memory leak thing is pretty obvious and should have been taken care off. There's a pretty good chance that it's not mod_perl causing it. It may be just that Win32 perl grows a little when you run that CGI::header call over and over. The upcoming mod_perl 2 will have better support for Windows. You can find information on it here: http://perl.apache.org/release/docs/ - Perrin
Re: Apache::DBI with mod_perl 2.0
Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? Thanks, -Zac
Re: Is mod_perl the right solution for my GUI dev?
At 16:09 25.06.2002, Ganesan M wrote: My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. The problem you're looking at is rather different: should you try and create a *web frontend* or should you create a normal GUI? Largely depending on the nature of your application, the answers will be different. I can't say much more without knowing more about what you're trying to do: but to me it seems like if you need GD to do the job, you should probably be looking at a standard GUI instead. This needn't be done in Java or VC++, you could use any programming language with a windowing library, like Perl with Tk (or Gtk or Qt bindings, but I don't know much about any of those) or anything else. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? Ganesan.
FW: Is mod_perl the right solution for my GUI dev?
-Original Message- From: Prakash Chatterjee [mailto:[EMAIL PROTECTED]] Sent: 25 June 2002 16:00 To: Ganesan M Subject: RE: Is mod_perl the right solution for my GUI dev? Actually, no you can't. At least not without masses of Javascript and god knows what else. And of course you'll have no guarantee that it won't fall over on the client's browser. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? -Original Message- From: Ganesan M [mailto:[EMAIL PROTECTED]] Sent: 25 June 2002 15:54 To: [EMAIL PROTECTED] Subject: Re: Is mod_perl the right solution for my GUI dev? At 16:09 25.06.2002, Ganesan M wrote: My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. The problem you're looking at is rather different: should you try and create a *web frontend* or should you create a normal GUI? Largely depending on the nature of your application, the answers will be different. I can't say much more without knowing more about what you're trying to do: but to me it seems like if you need GD to do the job, you should probably be looking at a standard GUI instead. This needn't be done in Java or VC++, you could use any programming language with a windowing library, like Perl with Tk (or Gtk or Qt bindings, but I don't know much about any of those) or anything else. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? Ganesan.
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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: Is mod_perl the right solution for my GUI dev?
Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? No, not at all. The web is bound by HTTP and HTML. This comes with many ramifications. There are three main areas where I have and you will run into problems: - Real-time data updates. HTTP is stateless: it serves up the page then closes the connection. Any updating involves a round-trip back to the server. In traditional GUI, you just hold a db connection and repaint the areas that are updated. - State maintenance. Since it is stateless, you have to jump through a lot of hoops to realize that two requests are coming from the same person, since they could be handled by two different child processes or even two different servers. This has all sorts of ramifications on user login, user preferences, where the user was in the application, etc... you have to do a lot of work on the server side to realize that it's the same client that keeps talking to you. - Fancy interface widgets/layouts. HTML/CSS/JavaScript/DHTML can only get you so far. If you need fancy menu types, forms, layouts, etc... it quickly becomes tedious/impossible on the web. This is just the tip of the iceberg. -Fran
Re: Apache::DBI with mod_perl 2.0
Ahhh, ok more clarity. :) Forgive me if I'm just not doing my detective work in poking around for documentation, but is there a doc that contains all the kludges or assumed modules I need to already have in place? I'm assuming that the bulk of these things are handled via a CPAN Apache::bundle install, and because mod_perl2 is still beta we don't have that in place yet? Thanks for all this info, learning more and more every day. :) -Zac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Zac Morris [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 11:02 AM Subject: Re: Apache::DBI with mod_perl 2.0 Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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[2]: mod_perl memory leaks on Windows
Hello Perrin,
Tuesday, June 25, 2002, 6:40:01 PM, you wrote:
PH Andrey Prokopenko wrote:
After a fresh restart, I started Apache/mod_perl. Then i issued a
little stress test using simple perl script with LWP::Simple.
I ran a performance test on /mod_perl/index.pl page for 10 minutes. The
source code of that page is given below :
-
#!/perl/bin/perl
use CGI qw(:all);
print header;
print Hello, World!;
-
After 10 mintues of execution, the memory consumption of Apahce.exe
had jumped from approx 5 MB to 120MB ( virtual memory ).
I ve noticed, that Apache child grown by 4-8kb per each request.
PH Have you tried it without using CGI.pm? Have you tried writing a
PH handler instead of using Apache::Registry?
yep, i wtite a totally simple cgi
--
#!/perl/bin/perl
use strict;
print Content-type: text/plain\n\n;
print Hello, World!;
--
and the same simpliest handler:
--
package MyTest;
use Apache;
use Apache::Constants;
sub handler{
my $r = shift;
print $r-send_http_header(text/html);
print h1HELLO WORLD!/h1;
return OK;
}
1;
--
and still no luck ;(((
Apache child still continued to grow in both cases. ;(((
I even turned off KeepAlive option in httpd.conf
I know that mod_perl on Windows is a development version but still
this memory leak thing is pretty obvious and should have been taken
care off.
PH There's a pretty good chance that it's not mod_perl causing it. It may
PH be just that Win32 perl grows a little when you run that CGI::header
PH call over and over.
I tried a plain Perl cgi script, with no module used, and still the
same. ;((
Do you mean that this leak cannot be fixed from Apache/mod_perl side ?
PH The upcoming mod_perl 2 will have better support for Windows. You can
PH find information on it here: http://perl.apache.org/release/docs/
Sorry, but for now we're stuck with Apache 1.3.x, because we use module, which
cannot work with Apache 2.0. So i seek appropriate solution based on
Apache 1.3 version.
--
Best regards,
Andreymailto:[EMAIL PROTECTED]
TransHandler called a second time after I've returned DECLINED
I'm using a TransHandler, and having a problem where it sometimes gets
called twice when I don't expect it - in most cases it's called just once as
I expect.
When I specify a file in a directory that doesn't exist (I'm going to use
path_info in a Mason dhandler, either to deliver a custom 404 with
autohandler, or for various other nefarious purposes), my TransHandler is
being called twice. The first time, it gets the correct $r-uri(), and I
determine that I don't want to translate the request - returning DECLINED.
The second time, the uri() is jimmied.
On an example request for /exists/non-existent-dir/file.html, the uri() is
screwed up as /file.html. If the request is /exists/non/foo/file.html, then
uri() is /foo/file.html on the second (unexpected) call to my TransHandler.
I've trimmed my server's vhost configuration down to this bare minimum:
VirtualHost IP:PORT
ServerAdmin [EMAIL PROTECTED]
ServerName randy.www.customer.com
DocumentRoot/www/home/cust/dev/randy/www.customer.com/
PerlTransHandler My::Trans
Location /
SetHandler perl-script
PerlHandler My::MasonHandler
order allow,deny
allow from all
/Location
/VirtualHost
Note, if I remove the PerlHandler, the TransHandler isn't getting called at
all, even though I've specified it. The two packages are defined in a
single init script that's still doing fine for other vhosts.
I've troubleshot quite a bit, and the call-stack when I'm called twice is
exactly the same (/dev/null is the caller). The pid and perl interpreter is
the same for both, so I can work around it with a package-global variable
and $r-uri( $foo ) and a $r-register_cleanup( sub{$foo=0}). But not with
$r-pnotes() - it doesn't hold the value!
I don't see anything My::MasonHandler is doing (push_handlers, for instance)
that should cause a second transhandler to be called for - besides which,
that code isn't run until later anyway.
perl 5.005_03
Apache.pm v1.27
compiled into apache, not DSO
I know this Perl version isn't up to the moment, but I've had various
problems with the more up-to-date perls, and none with this version - unless
this turns out to be the exception :)
Has anybody experience with such a problem? Anybody using this perl and
mod_perl with a transhandler of such a nature, with success? Anyone have
suggestions I should try?
Thanks,
Randy
RE: Re[2]: mod_perl memory leaks on Windows
Apache 1.3.x has always been experimental and not-for-production-use on
Win32 :(
Hopefully these modules will support Apache 2.0 pretty soon, for your sake.
Randy
-Original Message-
From: Andrey Prokopenko [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 25, 2002 8:31 AM
To: [EMAIL PROTECTED]
Subject: Re[2]: mod_perl memory leaks on Windows
Hello Perrin,
Tuesday, June 25, 2002, 6:40:01 PM, you wrote:
PH Andrey Prokopenko wrote:
After a fresh restart, I started Apache/mod_perl. Then i issued a
little stress test using simple perl script with LWP::Simple.
I ran a performance test on /mod_perl/index.pl page for 10 minutes. The
source code of that page is given below :
-
#!/perl/bin/perl
use CGI qw(:all);
print header;
print Hello, World!;
-
After 10 mintues of execution, the memory consumption of Apahce.exe
had jumped from approx 5 MB to 120MB ( virtual memory ).
I ve noticed, that Apache child grown by 4-8kb per each request.
PH Have you tried it without using CGI.pm? Have you tried writing a
PH handler instead of using Apache::Registry?
yep, i wtite a totally simple cgi
--
#!/perl/bin/perl
use strict;
print Content-type: text/plain\n\n;
print Hello, World!;
--
and the same simpliest handler:
--
package MyTest;
use Apache;
use Apache::Constants;
sub handler{
my $r = shift;
print $r-send_http_header(text/html);
print h1HELLO WORLD!/h1;
return OK;
}
1;
--
and still no luck ;(((
Apache child still continued to grow in both cases. ;(((
I even turned off KeepAlive option in httpd.conf
I know that mod_perl on Windows is a development version but still
this memory leak thing is pretty obvious and should have been taken
care off.
PH There's a pretty good chance that it's not mod_perl causing
it. It may
PH be just that Win32 perl grows a little when you run that CGI::header
PH call over and over.
I tried a plain Perl cgi script, with no module used, and still the
same. ;((
Do you mean that this leak cannot be fixed from Apache/mod_perl side ?
PH The upcoming mod_perl 2 will have better support for Windows.
You can
PH find information on it here: http://perl.apache.org/release/docs/
Sorry, but for now we're stuck with Apache 1.3.x, because we use
module, which
cannot work with Apache 2.0. So i seek appropriate solution based on
Apache 1.3 version.
--
Best regards,
Andreymailto:[EMAIL PROTECTED]
Re: when to mod_perl?
Perrin == Perrin Harkins [EMAIL PROTECTED] writes: Perrin Static content is easy; just don't serve it from mod_perl. The proxy Perrin approach is good, and so is a separate image server (which you can Perrin host on the same machine). I've found thttpd to be an amazingly Perrin efficient server for images, but a slimmed-down apache does very well Perrin too. On the new www.stonehenge.com, I'm using a stripped down Apache (just mod_proxy and mod_rewrite) for a reverse caching proxy, and it's about 1.5M RSS per process. I divert requests for TT's /splash/images and Apache's /icons, but otherwise, all content requests (including for /merlyn/Pictures/ images) go to my heavyweight mod_perl backends, which are running about 10M RSS. Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. On a 500Mhz 256M box, I'm easily serving 50K requests a day (about 10K of those are fully uncached dynamic pages touching about 20 to 50 TT includes), with loadaverages staying below 0.5. If it ever starts getting higher, I can cache the expensive menubar creation (which is nearly completely static) using Perrin's device, but I've not bothered yet. It's been amazingly carefree. I'm planning to move www.geekcruises.com to be served on the same box, although they get only about 1/10th the traffic. -- 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: Is mod_perl the right solution for my GUI dev?
Thanks for the info. What I am looking for here is: just a front-end GUI which will interact with the existing C programs. The base application is written in C. That is not going to change(That is one heck of the job to re-write the C application). Perl programs will be used to get the data from C programs and display it in a Graph and some fancy menus will be used to drive the C applicaiton. For graph I will be using GD and for menus CGI/Javascript/DHTML/CSS and of course, Apache is my web interface. How good is this solution? Ganesan. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? No, not at all. The web is bound by HTTP and HTML. This comes with many ramifications. There are three main areas where I have and you will run into problems: - Real-time data updates. HTTP is stateless: it serves up the page then closes the connection. Any updating involves a round-trip back to the server. In traditional GUI, you just hold a db connection and repaint the areas that are updated. - State maintenance. Since it is stateless, you have to jump through a lot of hoops to realize that two requests are coming from the same person, since they could be handled by two different child processes or even two different servers. This has all sorts of ramifications on user login, user preferences, where the user was in the application, etc... you have to do a lot of work on the server side to realize that it's the same client that keeps talking to you. - Fancy interface widgets/layouts. HTML/CSS/JavaScript/DHTML can only get you so far. If you need fancy menu types, forms, layouts, etc... it quickly becomes tedious/impossible on the web. This is just the tip of the iceberg. -Fran
Re: [JOB] Crack OOP Perl whitebox tester wanted
I think *all* job postings and offers should be forked to another list. This should be mod_perl only! Per Einar Ellefsen wrote: At 11:46 22.06.2002, Ged Haywood wrote: Hi all, On Fri, 21 Jun 2002, Zac Morris wrote: Old fashioned is right, Can we decide whether this kind of post is or is not welcome on the List? My 0.02 is that if someone has decided on the terms of reference for an offer of employment which he is making then if it's legal, that's the way it has to be and we don't need to discuss it here - especially not at such length. I agree with you Ged; Job announcements are ok, any discussion is way OT.
Re: [JOB] Crack OOP Perl whitebox tester wanted
Hi, What is the right way of authorizing users under Mason? Should it be done as PerlAccessHandler or coded in handler.pl? --- # require myhandler.pl Location /registered PerlAccessHandler Apache::MyAccessHandler PerlHandler HTML::Mason /Location --- Vlad
Re: Is mod_perl the right solution for my GUI dev?
Fran Fabrizio writes: - Real-time data updates. HTTP is stateless: it serves up the page then closes the connection. Any updating involves a round-trip back to the server. In traditional GUI, you just hold a db connection and repaint the areas that are updated. Solved with refresh? JavaScript and Java can also help here. For interactivity, check out: http://www.cs.brown.edu/people/dla/polytope/tetra.html - State maintenance. Since it is stateless, you have to jump through a lot of hoops to realize that two requests are coming from the same person, since they could be handled by two different child processes or even two different servers. This has all sorts of ramifications on user login, user preferences, where the user was in the application, etc... you have to do a lot of work on the server side to realize that it's the same client that keeps talking to you. Cookies work fine. - Fancy interface widgets/layouts. HTML/CSS/JavaScript/DHTML can only get you so far. If you need fancy menu types, forms, layouts, etc... it quickly becomes tedious/impossible on the web. Tedious is questionable. Impossible, I seriously doubt. Remember, you can always delegate part of your screen to a Java applet, although I strongly recommend you avoid this. This is just the tip of the iceberg. Let's talk about the positives: + You update the server and instantly all clients are up-to-date. + You can detect incorrect usage, bugs, etc. by parsing a single log file, in real-time + The system is immune to operate system upgrades. And DLL hell on Windows boxes. + You access the system from anywhere reliably and securely. You don't have to open up a database connection to anybody but the Web server(s). + There is only one version of the software. + Support people can view the output sent to the client exactly as the client received it. Including following a series of actions. + The use of a Web browser is familiar to most users. + The user can keep multiple views of the pages she wants, not what the application decides to offer. + Bookmarks allow users to structure their view of the application. Advanced users can create new organizations (short cut pages) for themselves and their co-users. + Users can share information easily (send page by email, mail bookmarks, print page, save to disk, save picture, etc.) I'm sure others will add to the list. Rob
Re: mod_perl memory leaks on Windows
Andrey Prokopenko wrote: I tried a plain Perl cgi script, with no module used, and still the same. ;(( Do you mean that this leak cannot be fixed from Apache/mod_perl side ? I can't say for sure since I don't use mod_perl on Win32, but most of the process growth problems reported when using mod_perl are not caused by mod_perl. They are usually caused by the perl code involved, but it looks like a mod_perl problem because when running under CGI you never get the chance to notice this growth (because the processes are not persistent). Sorry, but for now we're stuck with Apache 1.3.x, because we use module, which cannot work with Apache 2.0. So i seek appropriate solution based on Apache 1.3 version. Why can't the module work with Apache 2? You might be able to get some advice here on how to fix it. Otherwise, you could look at alternatives like PerlEx, but they may have the same issues. - Perrin
Re: Is mod_perl the right solution for my GUI dev?
[snip] The problem with all of the above is that it takes a VERY VERY complex analysis, planning, deployment, and long term environmental support infrastructure that most companies just don't have. So while J2EE all sounds great on paper, implementation of any reasonable J2EE system actually can create MORE man hours of work than a more straightforward procedural style implementation. It a matter of where you want to put the work, on the development side or on the implementation/support side. People forget or (don't want to remember?) that perl can utilize OOP, Design Patterns, and just good old polymorphism in a more straight forward procedural style implementation. It's especially important to think in these way in those spots you can guess they are going to scope creep on you down the road. [snip]. People can archetect the most elegant system in the world but if you don't have the people to make it all happen, then you have nothing after months and months of development work. -Zac Zac is absolutely 100% right. That was one heck of the answer. This will be very useful when I talk to the management. I hope zac doesn't mind if I quote his e-mail in the meeting ;-). Ganesan. My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI.
What is the right way of authorizing users under HTML::Mason?
Hi, What is the right way of authorizing users under Mason? Should it be done as PerlAccessHandler or coded in handler.pl? --- # require myhandler.pl Location /registered PerlAccessHandler Apache::MyAccessHandler PerlHandler HTML::Mason /Location --- Vlad
Re: Is mod_perl the right solution for my GUI dev?
Rob Nagler wrote: Solved with refresh? JavaScript and Java can also help here. Yes, solved with refresh. Of the entire page. Which may be quite complex and have some hefty SQL queries, etc...not to mention other issues such as network latency, the re-rendering of the page, etc...all distract from the user experience, which may or may not be an issue for the particular application. For example, I once coded an HTML-based game where you guessed movie quotes and if you got it right, you replaced it with one of your own. Two of the issues were 1. I wanted a list of who was currently playing but it quickly got out of date and to update it would mean to refresh the entire page, go to frames, or put the list in a separate window, all messy. 2. When one user correctly guessed a quote, I would have liked to have all the other users' screens update with that new info, but that's impossible without having something like a java applet embedded in the page checking for new data and forcing a refresh of the page. Yes it works, but it's messy once again. These are real issues, and issues which I have solved as best as possible on the web but that are easier in other systems. Cookies work fine. You oversimplify. Cookies do work fine. What creates, reads, modifies, validates the cookies? What ties the cookies to useful state information that is stored server-side? There's a lot of coding potentially involved. Yes, perl modules exist. Yes, they'll most likely need customization (in my case, I've customized AuthCookie, and tied it to Apache::Session. It wasn't the end of the world, but it wasn't trivia. A cookie by itself is of rather limited usefulness. Tedious is questionable. Impossible, I seriously doubt. Remember, you can always delegate part of your screen to a Java applet, although I strongly recommend you avoid this. Reinventing common widgets by coding up in HTML, CSS, JavaScript something that's a one-liner in a typical GUI environment is not tedious? I think you're oversimplifying again. As for a Java applet, a java applet ceases to be a web frontend. It's a GUI front end using the web as a communication/distribution layer. Once it's launched, you use stateful sockets to talk back to the server, etc... If you find yourself doing a majority of your interface via java applet (which is not something you want to try if cross-browser implementation is a desired feature, by the way), then you might as well make it a standalone java app, especially since you're apt to hit the applet security sandbox on any sort of robust app. There are a TON of positives to web frontends. I'm not arguing. I have made my living for the past 8 years building these things, I'm a friend of the web front end. =) You've captured the positives quite well, so I don't need to reiterate. But let's not fall into the trap of saying the web is the best tool for every front end usage imaginable. The user has said fancy menus and graphs are to be the mainstay of the app. I speak from first-hand experience, hell my current project has both of these things in a web interface, and neither were trivial. I crafted an expandable-tree menu (think Windows Explorer style menu) from HTML, CSS, JavaScript and HTML::Template. I have graphs dynamically generated using GD::Graph. Both took time, lots of trial and error, and lots of hair-pulling. Massaging the data for GD::Graph was just one chore I remember being harder than expected. These tools worked and are great tools that enable things on the web that aren't otherwise possible, but it was hard -because- it was a web app with all the inherent limitations - these things are much more native to traditional GUIs. In my case, we have a -need- to be a web app and so I'm willing to jump through hoops to make the interface richer where we need it to be, but if I was choosing between web and traditional, and I didn't -need- web, and I knew that graphs and fancy widgets were the mainstay of my app, I'd think twice before trying web. Fancy widgets especially are not that much fun to code on the web when a very robust library of them already exist for most GUI systems. Yes, it can be done (though there are still some things which I found impossible, some widgets which I don't think can be duplicated acceptably on the web. I like clicking on column headers and have them resort without doing a round-trip, for instance) but it's not much fun sometimes. That's my only point. -Fran
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc that contains all the kludges or
assumed modules I need to already have in place?
All the docs that we have now are at
http://perl.apache.org/release/docs/index.html
Most of the kludges are documented here:
http://perl.apache.org/release/docs/2.0/user/compat/compat.html
There are much more to come, but it'll take time. For now there is more
than enough docs to get yourself started. If something is unclear or
missing please shout aloud.
I'm assuming that the bulk of these things are handled via a CPAN
Apache::bundle install, and because mod_perl2 is still beta we don't have
that in place yet?
yes, but Apache::Module is an XS module using mod_perl 1.0's API, so it
won't be in the Apache::Bundle for 2.0. This patch may go in soon:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.61
diff -u -r1.61 compat.pm
--- lib/Apache/compat.pm4 Jun 2002 12:40:53 - 1.61
+++ lib/Apache/compat.pm25 Jun 2002 15:17:56 -
@@ -91,7 +91,8 @@
}
sub module {
-require Apache::Module;
+eval { require Apache::Module };
+die Please install Apache::Module from CPAN if $@;
return Apache::Module::loaded($_[1]);
}
Thanks for all this info, learning more and more every day. :)
cool :)
__
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: when to mod_perl?
Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. . I have a question regarding to the cached files. Although the maximal period is set to be 24 hours in httpd.conf's proxy settings, many of the files, which were cached from the backend mod_perl dynamical program, are strangely modified every a few minutes. For all the files I checked so far, they do look to be modified because the hex strings on top of the files (such as 3D189FC2) are different after each modifications. Forgive me if this is off-topic: it is more likely a mod_proxy question. I searched, but could not find related information pages to read. Thanks. Peter Bi - Original Message - From: Randal L. Schwartz [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Cc: md [EMAIL PROTECTED]; Stas Bekman [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, June 25, 2002 8:38 AM Subject: Re: when to mod_perl? Perrin == Perrin Harkins [EMAIL PROTECTED] writes: Perrin Static content is easy; just don't serve it from mod_perl. The proxy Perrin approach is good, and so is a separate image server (which you can Perrin host on the same machine). I've found thttpd to be an amazingly Perrin efficient server for images, but a slimmed-down apache does very well Perrin too. On the new www.stonehenge.com, I'm using a stripped down Apache (just mod_proxy and mod_rewrite) for a reverse caching proxy, and it's about 1.5M RSS per process. I divert requests for TT's /splash/images and Apache's /icons, but otherwise, all content requests (including for /merlyn/Pictures/ images) go to my heavyweight mod_perl backends, which are running about 10M RSS. Thanks to the caching, any of my images or other static content gets pushed once a day to the front, and then doesn't tie up the back ever again. On a 500Mhz 256M box, I'm easily serving 50K requests a day (about 10K of those are fully uncached dynamic pages touching about 20 to 50 TT includes), with loadaverages staying below 0.5. If it ever starts getting higher, I can cache the expensive menubar creation (which is nearly completely static) using Perrin's device, but I've not bothered yet. It's been amazingly carefree. I'm planning to move www.geekcruises.com to be served on the same box, although they get only about 1/10th the traffic. -- 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: when to mod_perl?
Peter == Peter Bi [EMAIL PROTECTED] writes: Peter I have a question regarding to the cached files. Although the Peter maximal period is set to be 24 hours in httpd.conf's proxy Peter settings, many of the files, which were cached from the backend Peter mod_perl dynamical program, are strangely modified every a few Peter minutes. For all the files I checked so far, they do look to be Peter modified because the hex strings on top of the files (such as Peter 3D189FC2) are different after each modifications. If you're talking about www.stonehenge.com, I don't provide last-modified for any of the HTML pages: they're all dynamic. If the proxy server is caching them, it's going to still punch through to the back for each hit. Similarly, if you are talking about your own site, and you *do* provide a mostly useless last modified time, then the front end is still going to go to the back end and say I've got a version from time $x, is that current? and if you're not handling if-modified-since, then every hit will be cached, uselessly. I avoid that on stonehenge by not providing last-modified for any of my HTML pages. mod_proxy thus has no idea about caching, so it's all dynamic. My images automatically have last-modified, and thus the cache can check for updates with if-modified-since, using the cache when needed. If I was really smart, I'd use mod_expires to say this image is good for $N hours, and then the front end wouldn't even touch the back end at all. As I said, as long as my loadav is low enough for my current hits, I've got better things to work on. :) -- 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: Is mod_perl the right solution for my GUI dev?
Thank you all for all your input on this. Here are the reasons why I chose web interface using Apache/CGI/Mod_perl/GD for our front-end reports. * Quick solution. Our management needed the report screens in a very short period. * Our C application runs on two different OS and two different DB. SCO openserver and Linux, Informix and Oracle. Our front-end needed multi-platform support. * Perl can go with any major language. AFAIK, perl interaact very well with any language. * Re-designing the look and feel (appearance) is very easy with web interface. * GD generates graphs on the fly. I don't know which other softwares do the same. * With Apache/perl web interface you do not need to install anything at the client side. (No dll/library installation problems). * As Zac Morris said, we did not have time and resources to go through a complex J2EE deployment. I would like to continue in the same web front-end path for more interactive forms. May be I will have to fight with Javascript more. I just want to know is this the right path? Someone suggested perl/TK. Again, you have to write 4 different codes for 4 different platforms. More suggestions on this are welcome. Once agin, thanks for all your input. Ganesan.
Re: Is mod_perl the right solution for my GUI dev?
Well it sounds like most of your design goals are pointing you towards the web interface. These same goals are what made me choose web even though I knew that I'd have to make some sacrifices on the interface. You'll be able to do it fine on the web, just be prepared to be flexible with the interface and learn to accept/work around the web's inherent limitations. Some thoughts: * GD generates graphs on the fly. I don't know which other softwares do the same. GD sits on top of C's gd library. I would like to continue in the same web front-end path for more interactive forms. May be I will have to fight with Javascript more. Yes, much more. But a book I found helpful was 'DHTML and CSS for the WWW'. It has helpful examples of various menus and widgets that can be accomplished on the web to make an interface richer. And with that, I think we've officially left the topicality of a mod_perl list. :-) Enjoy, Fran
RE: Is mod_perl the right solution for my GUI dev?
:I would like to continue in the same web front-end : path for more : interactive forms. May be I will have to fight with : Javascript more. : : Yes, much more. But a book I found helpful was 'DHTML : and CSS for the : WWW'. It has helpful examples of various menus and : widgets that can be : accomplished on the web to make an interface richer. While not germane to mod_perl, I did want to add my two cents to this. I did not follow the rest of the thread, so I am not sure in what context you want to deploy a web-site, but be careful with JS and other client-side technologies. IMO, they should be used when they are value-added, but do not become mission critical. In that, they might add some functionality that is useful but not vital for the user to complete the forms or navigate the site. Even in an intranet setting, unless you can positively ensure what browsers are used, you will encounter situations where things just do not work for a certain set of users. When using these technologies, do not be tempted to use browser-specific functions or plug-ins unless you are willing to accept that people will have to use your choice of browser. Follow open standards and rely of server-side solutions as in the end they will save you a lot of headaches and enable you to support the greatest variety of users with the least amount of effort. Good luck! Cheers, Ward
Re: ANNOUNCE: Embperl 2.0b8
At 12:39 25.06.2002, Gerald Richter - ecos gmbh wrote: I have done a lot of fine tuning and error fixing since 2.0b7. Also Embperl now supports mod_perl 2.0 with prefork MPM (threaded MPM will require Perl 5.8.0). The docs are moveing towards 2.0, but some features are still only documentent in README.v2. Everybody who is running a copy of Embperl 2, should upgrade to 2.0b8, because this will improve stabibility. Hello Gerald, While I am not very familiar with Embperl, I saw some discussion concerning PHP that struck me as pretty interesting for Embperl and similar applications: have you considered making (or atleast having an option for) Embperl an output filter for Apache 2/mod_perl 2? I think this would more clearly show its purpouse, just like SSI is now really a filter under Apache 2.0. If there is already a way to filter output through Embperl, I'm sorry for this useless post :( -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: when to mod_perl?
- Original Message -
From: Randal L. Schwartz [EMAIL PROTECTED]
To: Peter Bi [EMAIL PROTECTED]
Cc: Perrin Harkins [EMAIL PROTECTED]; md [EMAIL PROTECTED];
Stas Bekman [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, June 25, 2002 10:18 AM
Subject: Re: when to mod_perl?
Peter == Peter Bi [EMAIL PROTECTED] writes:
Peter I have a question regarding to the cached files. Although the
Peter maximal period is set to be 24 hours in httpd.conf's proxy
Peter settings, many of the files, which were cached from the backend
Peter mod_perl dynamical program, are strangely modified every a few
Peter minutes. For all the files I checked so far, they do look to be
Peter modified because the hex strings on top of the files (such as
Peter 3D189FC2) are different after each modifications.
If you're talking about www.stonehenge.com, I don't provide
last-modified for any of the HTML pages: they're all dynamic. If the
proxy server is caching them, it's going to still punch through to the
back for each hit.
That is one of our sites.
Similarly, if you are talking about your own site, and you *do*
provide a mostly useless last modified time, then the front end is
still going to go to the back end and say I've got a version from
time $x, is that current? and if you're not handling
if-modified-since, then every hit will be cached, uselessly.
I used:
$r-update_mtime($id); # id is less than the current time and does not
change for a specific page
$r-set_last_modified;
if ($r-protocol =~ /(\d\.\d)/ $1 = 1.1){
$r-header_out('Cache-Control' = max-age= . 100*24*3600);
} else {
$r-header_out('Expires' = HTTP::Date::time2str($id + 100*24*3600));
}
It would not be surprising if none of the dynamic pages created was cached,
which then meant I had improper headers in mod_perl. In fact, they do serve
a number of views (maybe several tens) before modifying in the proxy
directory again. For example, I checked a file status:
$last access time: Tue Jun 25 11:44:12 2002
$last modify time: Tue Jun 25 11:40:52 2002
and for the same file later:
$last access time: Tue Jun 25 11:51:14 2002
$last modify time: Tue Jun 25 11:44:54 2002
so they were modified but not for every hits.
I avoid that on stonehenge by not providing last-modified for any of
my HTML pages. mod_proxy thus has no idea about caching, so it's all
dynamic. My images automatically have last-modified, and thus the
cache can check for updates with if-modified-since, using the cache
when needed. If I was really smart, I'd use mod_expires to say this
image is good for $N hours, and then the front end wouldn't even
touch the back end at all.
But if one makes a proper header, the proxy would not distinquish whether it
is static or dynamic. It should deliver or cache all the backend pages the
same way, providing the headers are right.
Here is another strange clue for me. The cached files have three extra
request headers X-Forwarded-For:, X-Host: , X-Server-Hostname: (from
mod_proxy_forward). While the files are modified continuously, the
X-Forwarded-For header, which record a browser's IP, does NOT change
although the later hits come from completely different IPs.
As I said, as long as my loadav is low enough for my current hits, I've
got better things to work on. :)
--
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!
Peter Bi
Re: ANNOUNCE: Embperl 2.0b8
Hi, While I am not very familiar with Embperl, I saw some discussion concerning PHP that struck me as pretty interesting for Embperl and similar applications: have you considered making (or atleast having an option for) Embperl an output filter for Apache 2/mod_perl 2? I think this would more clearly show its purpouse, just like SSI is now really a filter under Apache 2.0. Yes, 2.0b8 can be a output filter for Apache 2.0, even more Embperl::Object, which allows you to create your site out of objects or components, can now not only include other Perl output, but any output that is created by a Apache request, you just use the subreq parameter to the Execute function (which is used to inlcude other parts), give it an URI and you have that part included in your page, regardless if it is a CGI script, output generated by PHP or Java or whatever runs inside Apache and of course you can postprocess the output that comes from other Apache components. If there is already a way to filter output through Embperl, I'm sorry for this useless post :( Questions are never useless, this one for example gives me the chance to show one of the new feature of Embperl 2 :-) Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: ANNOUNCE: Embperl 2.0b8
At 21:30 25.06.2002, Gerald Richter wrote: Hi, While I am not very familiar with Embperl, I saw some discussion concerning PHP that struck me as pretty interesting for Embperl and similar applications: have you considered making (or atleast having an option for) Embperl an output filter for Apache 2/mod_perl 2? I think this would more clearly show its purpouse, just like SSI is now really a filter under Apache 2.0. Yes, 2.0b8 can be a output filter for Apache 2.0, even more Embperl::Object, which allows you to create your site out of objects or components, can now not only include other Perl output, but any output that is created by a Apache request, you just use the subreq parameter to the Execute function (which is used to inlcude other parts), give it an URI and you have that part included in your page, regardless if it is a CGI script, output generated by PHP or Java or whatever runs inside Apache and of course you can postprocess the output that comes from other Apache components. Ok, great then! If there is already a way to filter output through Embperl, I'm sorry for this useless post :( Questions are never useless, this one for example gives me the chance to show one of the new feature of Embperl 2 :-) :-) But I'm still sorry for not checking up enough. -- Per Einar Ellefsen [EMAIL PROTECTED]
