Re: Do virtual hosts need their own servers?
On Thu, 16 Aug 2001, Jonathan Edwards wrote: Related to this topic, I have a question about multiple instances of Apache. We run two mod_perl enabled sites on two separate IPs. These sites rely on mod_perl heavily. Each site has a unique perl script that handles just about everything. Currently, we only have one instance of Apache running, and I've noticed that the httpd child processes are quite large (up to 32megs!). We've upgraded the RAM on our server twice and now we're at 512, but it seems to be using all of that without a problem. Are these httpd processes so large because they include copies of both perl scripts? Would it be more efficient to set up two instances of Apache, one for each site/IP, and that way each child httpd would only contain one of the two perl scripts? That might help some, but it all depends[tm]. What you really want is to setup a (reverse) proxy process in front of the mod_perl process. Try looking through my slides at http://develooper.com/modperl/ - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: Do virtual hosts need their own servers?
On Thu, 16 Aug 2001, Dave Baker wrote: [...] p.s. The processes could also be large because of suboptimal coding, Scalability problems are almost never due to bad code and almost always due to bad design. or (if they grow over time) memory leaks ... with possibly that as the exception. :-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl1.26
I tried telneting to your web server to see what's going on. Look at this: $ telnet www.nonserviam.net 80 Trying 65.34.152.103... Connected to nonserviam.net. Escape character is '^]'. GET /modperl/index.pl HTTP/1.1 Host: www.nonserviam.net Hello!Connection closed by foreign host. The HTTP server did not return a proper HTTP header, which is why lynx doesn't like it. Looking at your mod_perl configuration... PerlSendHeader Off Try doing it with PerlSendHeader On. You also might need to add this line at the beginning of your script: print Content-type: text/plain\n\n; (or text/html)
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl 1.26
Philip Mak wrote: I tried telneting to your web server to see what's going on. Look at this: $ telnet www.nonserviam.net 80 Trying 65.34.152.103... Connected to nonserviam.net. Escape character is '^]'. GET /modperl/index.pl HTTP/1.1 Host: www.nonserviam.net Hello!Connection closed by foreign host. The HTTP server did not return a proper HTTP header, which is why lynx doesn't like it. Looking at your mod_perl configuration... PerlSendHeader Off Try doing it with PerlSendHeader On. You also might need to add this line at the beginning of your script: print Content-type: text/plain\n\n; (or text/html) Thanks a million. I'm having one of those saturdays :-) It works like a champ, of course. I guess the only thing I don't understand is why with PerlSendHeader Off, isnt the webserver supposed to send headers? Does it not because it doesn't know what kind of content a .pl file is? In that case, shouldn't it send DefaultType (text/plain) ? Thanks again, I'm going to run autobench again and see if we get better results :)
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl1.26
On Sat, 25 Aug 2001, Philip Mak wrote: I tried telneting to your web server to see what's going on. Look at this: $ telnet www.nonserviam.net 80 Trying 65.34.152.103... Connected to nonserviam.net. Escape character is '^]'. GET /modperl/index.pl HTTP/1.1 Host: www.nonserviam.net Hello!Connection closed by foreign host. The HTTP server did not return a proper HTTP header, which is why lynx doesn't like it. Looking at your mod_perl configuration... PerlSendHeader Off Try doing it with PerlSendHeader On. You also might need to add this line at the beginning of your script: print Content-type: text/plain\n\n; (or text/html) I just wanted to add that you always have to send 'Content-type' header. It's just that PerlSendHeader On reads your STDOUT, recognizes the header at a cost (see the guide) and then sends it along with other headers. With PerlSendHeader Off, you should use either CGI.pm or mod_perl native methods to set the headers. It's all in the guide :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: URI munging and Referer headers
Geoffrey Young wrote: hi mungers... it there a more reliable way to not have your session id's show up in Referer headers than using a refresh tag? I've played around with various redirect methods, but both MSIE5 and Netscape4.7 hold on to the Referer from the original page and ignore the 302 page. seems like meta refresh is the only way to be sure. looking for expert opinions :) I did some experimental work like this back when I first implemented the cookiless session stuff for Apache::ASP, and I found the same thing, that the meta refresh was really the only way to go with redirecting offsite. This would probably be the same for a javascript redirect too ( untested ). When it comes to session ids in URIs I also wonder about cases like search engines indexing pages with them, and then someone coming along later and using an old session id, this really makes it important to garbage collect old sessions so that this session id reuse doesn't hurt. Most major search engines have a very large index refresh window such that even old sessions that expire in a day should be enough protection. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: perlmagick and leaking memory
Jon Molin wrote: Hi list, I've done a scripts that builds an calender and colours the days with different colours depending on the status of the day. I've got 6 colours and one to just fill out so the month starts with the correct day, ie i've got 6 * 31 + 1 = 187 images and each is about 70 bytes so a calender is 6 times 7 of these little sqaures, about 3k. Now this little script handling this tiny amount of data runs amok and grows and grows untill i restart apache brutaly, I guess I've done something very wrong but I can't figure out what, nor can I find any info about this. Here's what the program looks like: Generally, I am not surprised when finding memory leaks in XYZ module. The code in the email looked fine, so I would suspect Image::Magick having the leak. To prove this better, you might take the code out of the mod_perl request, and run it through a test of 1000 iterations in a command line script, and report the problem to the author of Image::Magick. So, without waiting for a Image::Magick fix, you can make memory leaks less painful by setting MaxRequestPerChild lower, say to 100 or by using a solution like Apache::SizeLimit to kill a child process when it uses too much RAM ( unshared RAM on Linux too ) --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
RE: URI munging and Referer headers
I did some experimental work like this back when I first implemented the cookiless session stuff for Apache::ASP, and I found the same thing, that the meta refresh was really the only way to go with redirecting offsite. This would probably be the same for a javascript redirect too ( untested ). cool - thanks When it comes to session ids in URIs I also wonder about cases like search engines indexing pages with them, and then someone coming along later and using an old session id, this really makes it important to garbage collect old sessions so that this session id reuse doesn't hurt. Most major search engines have a very large index refresh window such that even old sessions that expire in a day should be enough protection. I suppose that's true for unauthenticated state management, which I actually hadn't been thinking about - good point. --Geoff
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl 1.26
Tom Allen wrote: ... Location /modperl AllowOverride None Options ExecCGI Indexes SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader Off /Location It appears to work ( I get a webpage that says Hello!), in a Mozilla browser, but httperf shows a connection reset instead of a success message, the same goes for lynx (Alert!: Unexpected network read error; connection aborted.). The ScriptAlias version works fine. The two scripts can be seen online at Regular CGI version : http://www.nonserviam.net/perl/index.pl ModPerl version: http://www.nonserviam.net/modperl/index.pl When I test it, I get a 404 Not Found, which could explain it. But even when it is found, you might try setting PerlSendHeader On, as it may not send a header otherwise. Or you could try explicitly calling Apache-send_http_header in your mod_perl version. --Josh ]# lwp-request -eS http://www.nonserviam.net/modperl/index.pl GET http://www.nonserviam.net/modperl/index.pl -- 404 Not Found Connection: close Date: Sat, 25 Aug 2001 23:58:43 GMT Server: Apache/1.3.20 (Unix) mod_perl/1.26 PHP/4.0.6 Content-Type: text/html Client-Date: Sun, 26 Aug 2001 00:00:09 GMT Client-Peer: 65.34.152.103:80 Title: NonServiam! X-Powered-By: PHP/4.0.6 HTML HEADTITLEAn Error Occurred/TITLE/HEAD BODY H1An Error Occurred/h1 404 Not Found /BODY /HTML
Re: Converting Perl section variables into plain text directives
On Fri, 24 Aug 2001, Eric Hammond wrote: Is there any way to take the Apache::ReadConfig name space (variables set in Perl sections) and generate plain text Apache directives? I don't know if there is a simple answer to this one, but the way I would handle it is to scrap the Perl sections, and generate the entire config file using a standalone perl script. Then just change your apache start script to first generate the config file, and then start Apache. This way you get the best of both worlds! Your config file is dynamically generated, and you can create a light apache without mod_perl. Since you already have a half perl, half text config file, It would probably be quite easy to use one of the many Template modules out there to simplify this process... I guess a module that does this automatically would be interesting, but it would really only be useful to recover from some bad planning :) (and I guess we've all been there at one point or another) Cees For example, assuming some_function() returns myhost, I would like to convert the variables generated by: Perl $ServerName = some_function(); $Port = 80; /Perl into: ServerName myhost Port 80 I have a hypothetical situation where a friend of a friend spent a lot of time setting up a nice Perl configuration for an extended family of web servers with various requirements. He then realized that one of the requirements was that some of the web servers run without mod_perl (to serve static files and proxy requests to separate mod_perl servers). My hypothetical friend of a friend is very embarrassed. After studying the instructions given in the Eagle book on how to convert plain directives into Perl variables, it seems that it should be possible to traverse the name space in Apache::ReadConfig and unwind the directives into something that standard mod_perl-less Apache could process. In fact, I have embarked on a project to build just such a tool. Before I go too far, though, I thought it would be helpful to seek wisdom here. Perhaps somebody else has already done this? Perhaps mod_perl already has the code embedded in it that could be used? Perhaps some wish to tell me it is near impossible in the general case and I should abandon my foolish quest? Of course, I realize that the output generated will not be able to duplicate any side-effects or dynamic nature of code in the Perl sections. One of the requirements for using this utility will be that you only need the end results stored in Apache::ReadConfig. I would be interested in suggestions for package naming if I do succeed to an extent that others might be interested in using it. Should I create a new method in the Apache::PerlSections name space or would this be stepping on Doug's toes? Please do let me know if anybody else has a use for such a tool. This will help me figure out how much time I should spend trying to handle the general cases instead of just writing it to meet my... er, my friend's... specific needs. Thanks -- Eric Hammond [EMAIL PROTECTED] -- Cees Hek SiteSuite Corporation [EMAIL PROTECTED]
cvs commit: modperl Changes
dougm 01/08/25 12:55:03
Modified:lib/Apache ExtUtils.pm
.Changes
Log:
allow overriding of container directive handlers using the func parameter
Submitted by: Geoffrey Young [EMAIL PROTECTED]
Revision ChangesPath
1.23 +1 -1 modperl/lib/Apache/ExtUtils.pm
Index: ExtUtils.pm
===
RCS file: /home/cvs/modperl/lib/Apache/ExtUtils.pm,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- ExtUtils.pm 2000/12/30 05:08:57 1.22
+++ ExtUtils.pm 2001/08/25 19:55:03 1.23
@@ -148,7 +148,7 @@
}
$name ||= $sub;
my $realname = $name;
- if($name =~ s/[\\]//g) {
+ if ($name =~ s/[\\]//g !$cmd-{func}) {
if($name =~ s:^/::) {
$name .= _END;
}
1.619 +3 -0 modperl/Changes
Index: Changes
===
RCS file: /home/cvs/modperl/Changes,v
retrieving revision 1.618
retrieving revision 1.619
diff -u -r1.618 -r1.619
--- Changes 2001/08/22 02:31:29 1.618
+++ Changes 2001/08/25 19:55:03 1.619
@@ -10,6 +10,9 @@
=item 1.26_01-dev
+allow overriding of container directive handlers using the func parameter
+[Geoffrey Young [EMAIL PROTECTED]]
+
enable directive handler support for TAKE13
[Geoffrey Young [EMAIL PROTECTED]]
