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: mod_perl2: apache.pm vs apache2.pm (CGI.pm)
On Fri, 2002-11-01 at 17:54, [EMAIL PROTECTED] wrote: First, make sure you have the latest version of CGI.pm from CPAN. It has fixes in there to automatically load Apache::Compat for you. Also CGI.pm isn't fully mod_perl2 compatable. so there is that over head unfortunally. Right now for me, I'll deal with the extra overhead, and with time Everything will be mod_perl2.0 aware. DBI.pm, CGI.pm, and Text::Templates would be great if they were to port them to work on mod_perl2 ASAP :) -- Jason Czerak > I've mod_perl running on several machines (apache 1.x) Today I > installed a new system with apache2 and ran into deep troubles and > questions: > > I installed perl-5.8.0, apache 2.0.43 and mod_perl 1.99_07 > > I preload Apache2 and use ModPerl::Registry: > > LoadModule perl_module modules/mod_perl.so > PerlModule Apache2 > and for my perl-files: > PerlResponseHandler ModPerl::Registry > > As soon as I try to run a script under mod_perl that uses CGI.pm I get > the problem: > > [Fri Nov 01 23:27:43 2002] [error] 9558: ModPerl::Registry: Can't locate Apache.pm >in @INC (@INC contains: /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/Apache2 >/usr/local/lib/perl5/5.8.0/i686-linux /usr/local/lib/perl5/5.8.0 >/usr/local/lib/perl5/site_perl/5.8.0/i686-linux /usr/local/lib/perl5/site_perl/5.8.0 >/usr/local/lib/perl5/site_perl .) at /usr/local/lib/perl5/5.8.0/CGI.pm line 161. > Compilation failed in require at /home/htdocs/perl/testgoldfisch.cgi line 4. > BEGIN failed--compilation aborted at /home/htdocs/perl/testgoldfisch.cgi line 4. > > Now I was starting to look around and in fact I have Apache.pm and > Apache2.pm on my system. Apache.pm is not in @INC (its in > /usr/local/lib/perl5/5.8.0/CGI/Apache.pm where it came from perl-insallation) > In @INC I only have Apache2.pm, which comes from the mod_perl Installation. > > Now I dont know whats going on. Maybe this both two modules have nothing in common >but a similar name. > Shall I extend my @INC so that Apache.pm is in it (where is best place to change >@INC ?). > > If I use the Compat-mode the problem vanishes. Is the CGI-module > incompatible with mod_perl2 ? If yes, is there any alternative that > can be used without need to rewrite all our libraries that rely on > CGI.pm ? > > thnx, > peter > > -- > mag. peter pilsl > IT-Consulting > tel: +43-699-1-3574035 > fax: +43-699-4-3574035 > [EMAIL PROTECTED] >
Dual Apache setups
I'm messing around with apache 2.0 and modperl 1.99 and Haven't been able to come across any docs that state that I would or would not need a dual apache setup for high load sites. I wish to have apache 2.0 threaded. currently my setup is Apache 1.3.26 with mod_ssl and mod_proxy and mod_rewrite and all other unnecessary modules not compiled in. and for dynamic requests, it proxys them to the back end as suggested by the mod_perl guide, very please with this performance and memory usage. Was wondering what is the statues of such a configuration with apache 2.x.x. -- Jason Czerak
Re: Weird mod_perl & CGI.pm interaction (Bug?)
On Sat, 2002-02-09 at 09:50, Mike McLagan wrote: I asked this question before. I had the same problem on _one_ of my machines but not any of the others. Is this perl 5.6.1 (or 5.6.0 even I dunno). And Do these perl installs have threading enabled? are they self compiled. if you said YES to all of those or even some (most importantly the threading bit). Recompile without threading. and then try. Keep in mind I tried several version of CGI.pm. Where the problem is (and yes, I did hack CGI.pm and fixed it but felt it was unnessary to hack CGI.pm since it wasn't at fault and didn't want to break other working apps), e, the problem is in the read_from_client() call where CGI.pm issues a read() from the STDIN file handle. The problem is when it's called for the second time the handle reference is missing. That is the jist of the details. I can get 100% informative if anyone wishes to know. -- Jason Czerak > On Fri, 8 Feb 2002 17:02:20 + (GMT), Ged Haywood wrote: > > >>My message is about data space. The data space for the modules does not > >> seem to be recreated or reinitialized (BEGIN blocks are not rerun) from one > >> invocation of a script to another. > > > >Yes, this is well known to mod_perl users and it's in the Guide, in > >the same chapter that I've already suggested that you read: > > > >=head1 BEGIN blocks > > > >Perl executes C blocks as soon as possible, at the time of > >compiling the code. The same is true under mod_perl. However, since > >mod_perl normally only compiles scripts and modules once, either in > >the parent server or once per-child, C blocks in that code will > >only be run once. As the C manpage explains, once a C > >block has run, it is immediately undefined. In the mod_perl > >environment, this means that C blocks will not be run during > >the response to an incoming request unless that request happens to be > >the one that causes the compilation of the code. > > Broken behavior, defined or not, is still broken behavior. Maybe it's > up to the CGI.pm author to investigate what he has to do to work around > this problem, but that's still a work around for broken behavior. > > >If you are having trouble coping with mod_perl and CGI.pm perhaps it > >would better if you tried different approach, Apache::Request for > >example has some useful features. > > Linux Online has been using mod_perl and CGI.pm for over 4 years now, > I'm not about to change because I've tripped over this bug. As my > original message said, I found a solution, albeit an unreasonable one. > If Apache::Request was perl only, I might look into it since we only > use CGI.pm for it's query parsing abilities but with the need to drag > along a C library, I'll pass. > >Michael > > > >
Re: Weird mod_perl & CGI.pm interaction (Bug?)
On Thu, 2002-02-07 at 13:38, Ged Haywood wrote: > Hi there, > > On Thu, 7 Feb 2002, Mike McLagan wrote: > > >I have two scripts, call them A and B. > [snip] > >$q = new CGI; > [snip] > > Inveriably, I end up with "B::show()" in my output, not at all what I wanted, > > Isn't this mentioned in the mod_perl Guide? > > http://perl.apache.org/guide > > 73, > Ged. > > As I mentioned ealier today. I asked the question. 'do you have threaded support compiled into perl?'. If you do, this was the solution I needed to fix the same problem that I have been having also. -- Jason Czerak
Re: weird problem. Lost of the POST data (SOLUTION)
On Mon, 2002-02-04 at 11:12, Oscar Serrano wrote: > Hi: > some days ago I wrote to ask for this problem: The CGI.pm (sometimes) could > not receive the POST data. I tried all you recomended me here in the list. > But I still had the problem. Finally I decide to kick out CGI.pm and start > to use the old cgi-lib.pl. But I still had the same problem. Then I turnet > to Apache::Request, and since I use it, I've never had the same problem. > I just tell you because perphaps somebody may have the same problem. I > don't really understan if the problem is in mod_perl, in Apache, in Templat > Toolkit, in my ultrasecure patched kernel, in CGI.pm, but the point is that > Apache::Request seems not to loose any post data :-? > > Thank you all. > > Oscar Serrano. > > > Did anyone of you guys by chacne compile PERL 5.6.1 with 'threading'. Cuz I had the EXACT same porblem. The problem was 'fixable' in CGI.pm. Look at the init() procedure. scroll down to line 453 where is calls read_from_client() (version 2.79 but is in all versions of CGI.pm). Now what I did was remove the reference to the STDIN filehandle and BINGO. things worked fine. But I found that that was unacceptable to modify the CGI.pm source. But that means reference handling was incorrect. I went and put alot of debugging stuff in read_from_client() and confirmed that the read() call was getting nothing returned becuase there wasn anything in the file handle that was passed to it. I 'thought' I had 2 exact matching systems. the one on the web server (that was having this problem) and my workstation/dev box. My dev box worked perfectly fine. At this point I was fed up with this and I started recompiling things. :) started with perl. This time I just ran ./configure and held down the "Enter" button (making sure I compiled libperl.so tho). remove the current perl tree frm the system compleatly. installed it. reinstalled all modules that I needed. That solved any problems. things run perfectly now. The only differnece is that I must of enabled multi-threading support because there was that 'thread' directory tree present. -- Jason Czerak
Re: Fast template system. Ideas,theorys and tools
On Thu, 2002-01-03 at 12:20, Perrin Harkins wrote: > > I implamented some google style timing in the API. It's basicly gets a > > Time::HiRes timestamp in the beginning and does the math at the very end > > and posts it in an html comment. > > You'd be better off with Devel::DProf (or Apache::DProg under mod_perl). > > > My average transaction time is > > about .08 of a second. That leads me to think that my machine can handle > > 10 html page generations a second (this isn't an exact science, but > > close). > > You are assuming serial execution. You should be able to push much more > than that through in a second because of parallel execution. > What do you suggest as a good benchmark tool to use that would be 'smart' when testing a whole complete site. -- Jason Czerak
Re: Fast template system. Ideas,theorys and tools
running with full caching enabled and fully persistant code base for the cart. My average transaction time is about .08 of a second. That leads me to think that my machine can handle 10 html page generations a second (this isn't an exact science, but close). Now, As with the bug I think I am having with text::template. I'm using STDOUT when I compile the template and execute all call backs and sql queries and the such fixes things for now. (the buffering bit it can use to compile the output into a varable is not working, it process the output of the perl API and prints it in the incorrect spot, the beginning of the output). Second feature that I'm not using is caching of output. The caching I'm wondering how to handle it. I would need this text::template buffering bit to work better first before I can use the caching. But I found a few nice mod_perl aware caching tools on CPAN that I'll use to do caching. 3rd. my sql queries are not the most optimized and mostly tossed together. But then again my developemnt tables are not that big at all. Keep in mind that my times are based also on the time it takes to make the transmission of the data from server to client as well as the time it takes to compile the template and do sql queries. I"m not sure if your times are factoring that in. Locally times are .08/sec but remotely from T1 to cable times are .16/sec to .20/sec depending on network conditions and size of html file at the time naturally. Some of the html files can be about 50K in size we found. Also, pages will do about 3 sql queries on average plus queries to the Apache::Session state information. Do these numbers sound right? There are places were I could move from doing SQL to keeping some data in Apache::Session. but it would be small speed improments unless the catagories are very deep, I do have recursive SQL queries inplace for some things. Your talking 50 to 60/sec as slow. So I dunno what is 'fast'. I do plan on release this cart GPL one of these days once I know it works. And I do plan on having a web site explaining it in full detail. If anyone is interested right now in the development of it. Give me a ring. I'll be glad to get some help with it. (expecially with fedex, ups shipping calcs :) ) If anyone would like to see a working site using the cart that I am working on. It's over at http://www2.test.jasnik.net. -- Jason Czerak
NameWithVirtualHost
I"m running Apache 1.3.12 + mod_perl 1.25 I'm looking to fully optimized my mod_perl scripts and in the process I'm finding that I can't totaly seperate my virtual hosts. I'm finding that sub procedure that are in modules that I write will get redefined across vhosts. I did extensive research on this and did all the tricks that was suggest but with no luck. An example test script is like this. /index.pl: # #!/bin/perl -w use strict; require "/path/to/custom/module/test.pm" &testmodulepackage::main(); exit; # Now test.pm would be duplicated and would have simular calls but differnet outputs. Am I assuming correctly that in vhostA.com's /index.pl what ever is 'required' for use is compleatly local to that vhost? or once it's required, it's global but the only thing that is local to that vhost is what ever is in the /index.pl code-wise? That's what I'm getting to assume here. my config is simple here are lines in my dynamic httpd httpd.conf file: #PerlModule Apache::StatINC SetHandler perl-script PerlHandler Apache::RegistryNG->handler Options +ExecCGI #PerlSendHeader On #PerlInitHandler Apache::StatINC #PerlSetVar StatINCDebug On PerlRequire /vhost/bin/apache-dynamic/startup.pl and the lines in startup.pl: #! /usr/bin/perl use strict; use Apache::RegistryNG; use CGI (); use DBI (); use DBD::Pg (); 1; nothing changes if the $Apache::Registry::NameWithVirtualHost = 1 is in the startup.pl or not. If I change the SetHandler perl-script to SetHandler cgi-script all the modules in the startup.pl load and are cached and shared but my scripts are not. I can provide output from perl-status if anyone wishes to C that. But from what I gather, Apache does correctly place all calls in the correct name spaces. -- Jason J. Czerak ([EMAIL PROTECTED]) Linux Systems Evangelist Jasnik Services, LLC http://www.Jasnik.net
