Re: Deployment strategies...
Perrin Harkins wrote: > You can't run two modules with the same name in the same perl > interpreter, so you either need to change the namespaces for > different versions or run separate servers. Yeah it's a pity that the perchild mpm never moved out of experimental. In theory something like loading different versions of modules in each child after the fork could solve the main part of the problem. The thing is that as I'm running the app under Catalyst, once I've started splitting off into different server instances, there's not as much of an advantage in using mod_perl - I can use FastCGI or HTTP::Prefork or even just run catalyst_server.pl. > Two minutes? That's a very long load time. I've seen huge codebases > load in 10-20 seconds. I think something might be wrong there, like a > slow database connection or DNS lookup. I'll do some profiling. Although we don't have a huge amount of code we have a lot of Controllers inheriting from base classes - checking the 3 main culprit apps they contain ~500 Controllers between them. As it's built up gradually I've always just presumed the overhead was from that. > Is the real problem that apache is accepting connections during > startup? Yes. The actual restarting to load updated code is reasonably automated so I'm not sitting waiting. I have had complaints that whilst it's happening the sites seem to freeze. > You could solve that by making your front-end smarter. Some > systems, like perlbal, will wait until apache responds to a HEAD > request before considering a server up. Actually I think the hardware load-balancing we've got does that - so rather than getting apache to balance, I should probably feed the requests back through that. As ever, thanks for your advice Perrin. Carl
Re: migrating to 2.0 and getting tons of warnings
On Thu, 2009-02-26 at 17:17 -0500, Perrin Harkins wrote: > On Thu, Feb 26, 2009 at 4:01 PM, Matthew Lenz wrote: > > Maybe the debian guys did something goofy with the modules. It wouldn't > > be the first time. That or maybe its just a bug in ModPerl. Even if > > some CPAN module out there has 'use warnings;' in it that shouldn't have > > any affect on any code outside of its own package should it? > > Something could be setting $^W. Grep your code for that. I only found a single reference to $^W and it was setting it to 0 for a small block of code. It didn't really even need to do so as no code was enabling them. This same code is going from Debian 3.1 (apache 1, mod_perl 1, perl 5.8) to Debian 5.0 (apache 2, mod_perl 2, perl 5.10) and now I'm getting the warnings. I looked through the packge diff: http://ftp.de.debian.org/debian/pool/main/liba/libapache2-mod-perl2/libapache2-mod-perl2_2.0.4-5.diff.gz and didn't spot any changes that would have this affect. > - Perrin
Re: Deployment strategies...
Hello, Perrin Harkins wrote: On Thu, Feb 26, 2009 at 12:38 PM, Carl Johnstone wrote: 1) We want to run different versions of the same app for different sites - this means I have a namespace problem for MyApp v1 vs MyApp v2 etc. This has been discussed many times on the list. You can't run two modules with the same name in the same perl interpreter, so you either need to change the namespaces for different versions or run separate servers. Carl, can you solve your problem by having a global class and then each site being an object of that class, inheriting or overriding methods as necessary? I'm sure I'm missing something in your question because it sounds so much like what we do and the answer seems so clear that I feel stupid for suggesting it since you probably already thought of it and refjected it. :-) Take care, Kurt Hansen
Re: Deployment strategies...
Carl Johnstone wrote: 1) We want to run different versions of the same app for different sites - this means I have a namespace problem for MyApp v1 vs MyApp v2 etc. Just my opinion, but it's sooo much easier to manage multiple sites if they are all using the same version of the application. What are your reasons for wanting to do that? -- Michael Peters Plus Three, LP
Re: migrating to 2.0 and getting tons of warnings
On Fri, Feb 27, 2009 at 7:58 AM, Matthew Lenz wrote: > I looked through the packge diff: > > http://ftp.de.debian.org/debian/pool/main/liba/libapache2-mod-perl2/libapache2-mod-perl2_2.0.4-5.diff.gz > > and didn't spot any changes that would have this affect. What about other CPAN modules you're using. Do you use a framework like Mason? You probably have different versions on the newer machine. - Perrin
Re: migrating to 2.0 and getting tons of warnings
On Fri, 2009-02-27 at 11:29 -0500, Perrin Harkins wrote: > On Fri, Feb 27, 2009 at 7:58 AM, Matthew Lenz wrote: > > I looked through the packge diff: > > > > http://ftp.de.debian.org/debian/pool/main/liba/libapache2-mod-perl2/libapache2-mod-perl2_2.0.4-5.diff.gz > > > > and didn't spot any changes that would have this affect. > > What about other CPAN modules you're using. Do you use a framework > like Mason? No, this is just a legacy app that runs straight CGI's via ModPerl::RegistryPrefork > You probably have different versions on the newer > machine. Absolutely, I'm guessing nearly every CPAN module being used is updated. > - Perrin I thought that if a package does a 'use warnings;' that it only affects code being executed in that package? Maybe that is not the case under mod perl 2? mod perl 1 didn't exhibit that behavior.
Re: Deployment strategies...
On Fri, Feb 27, 2009 at 5:30 AM, Carl Johnstone wrote: > The thing is that as I'm running the app under Catalyst, once I've started > splitting off into different server instances, there's not as much of an > advantage in using mod_perl - I can use FastCGI or HTTP::Prefork or even > just run catalyst_server.pl. Well, you probably could run it on FastCGI now. I don't think this really changes much. You wouldn't want to make every single app use a different FastCGI backend because it would waste memory, so either way you'll want to group things together as much as possible. Some people have suggested using the interpreter config options to start different interpreters for different virtual hosts. I haven't tried that and I'm not sure it works. (Also, you'd be nuts to run anything serious on HTTP::Prefork.) > Although we don't have a huge amount of code we have a lot of Controllers > inheriting from base classes - checking the 3 main culprit apps they contain > ~500 Controllers between them. As it's built up gradually I've always just > presumed the overhead was from that. 1500 classes is not enough code to cause a 2 minute compile on modern hardware. I've heard people say that DBIx::Class has a slow startup, so if you use that you might look there first. > Actually I think the hardware load-balancing we've got does that - so rather > than getting apache to balance, I should probably feed the requests back > through that. You mean go directly to mod_perl? You'd still want a front-end proxy for buffering. I'd suggest checking with the mod_proxy_balancer people to see if they have a solution. One trick I've used is to make my front end check a specific URL on the backend for alive-ness. When I want to remove a backend from the pool, I just move the file aside and put it back when the server has restarted. - Perrin
Re: migrating to 2.0 and getting tons of warnings
On Fri, Feb 27, 2009 at 11:43 AM, Matthew Lenz wrote: > No, this is just a legacy app that runs straight CGI's via > ModPerl::RegistryPrefork I'd check for any $^W manipulation in ModPerl::RegsitryPrefork. > I thought that if a package does a 'use warnings;' that it only affects > code being executed in that package? Maybe that is not the case under > mod perl 2? It's still the case. mod_perl doesn't change anything about the behavior of perl, just the lifecycle of your scripts. - Perrin
Re: Deployment strategies...
Perrin Harkins wrote: > different FastCGI backend because it would waste memory, so either way > you'll want to group things together as much as possible. Yeah, that confirms my thinking. > I've heard people say that DBIx::Class has a slow startup, > so if you use that you might look there first. We do, I'll look. > You mean go directly to mod_perl? You'd still want a front-end proxy > for buffering. I'd suggest checking with the mod_proxy_balancer > people to see if they have a solution. I mean balancers -> front-end -> balancers -> back-end. Using different IPs on the balancers for front/back. It was supposed to work that way originally, but we never got round to implementing it once we discovered mod_proxy_balancer in Apache 2.2. Thanks Carl
How to require() a file?
I am trying to require() a file using its absolute name. In command line mode everything works fine, but not in Apache: [Fri Feb 27 17:45:07 2009] [error] Can't locate /home/stf/public_html/test/arcv/public_html/../common.pl in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 . /etc/httpd) at /home/stf/public_html/test/arcv/public_html/ticket-list.pl line 13, line 344.\n How can I require() a file when using Perl in CGI mode? Do I have to modify @INC? I don't really feel like making it a module, and putting it into Some Well Known Location is something I don't feel like even more. It's just a supporting file that I want to keep together with the rest of the application. I guess I am using mod_perl: [Fri Feb 27 16:31:48 2009] [notice] Apache/2.2.6 (Unix) DAV/2 PHP/5.2.4 mod_perl/2.0.3 Perl/v5.8.8 configured -- resuming normal operations Thanks! STF === http://eisenbits.homelinux.net/~stf/ . My PGP key fingerprint is: 9D25 3D89 75F1 DF1D F434 25D7 E87F A1B9 B80F 8062 === signature.asc Description: OpenPGP digital signature
Re: How to require() a file?
Stanisław T. Findeisen wrote: I am trying to require() a file using its absolute name. In command line mode everything works fine, but not in Apache: [Fri Feb 27 17:45:07 2009] [error] Can't locate /home/stf/public_html/test/arcv/public_html/../common.pl in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi How can I require() a file when using Perl in CGI mode? Do I have to modify @INC? I don't really feel like making it a module, and putting it into Some Well Known Location is something I don't feel like even more. It's just a supporting file that I want to keep together with the rest of the application. /home/stf/public_html/test/arcv/public_html/../common.pl I believe the ../ in there may be what's throwing things off. That would probably interpolate as /home/stf/public_html/test/arcv/common.pl ... which, unless that is indeed where common.pl is located, would generate the error you're seeing. To answer your question, yes, you can absolutely do a require "/full/path/to/file.pl" just like that without modifying @INC.
Re: How to require() a file?
Michael A. Capone wrote: I believe the ../ in there may be what's throwing things off. That would probably interpolate as /home/stf/public_html/test/arcv/common.pl ... which, unless that is indeed where common.pl is located, would generate the error you're seeing. Yes this is where common.pl is located. It was just a permission problem. :-) STF === http://eisenbits.homelinux.net/~stf/ . My PGP key fingerprint is: 9D25 3D89 75F1 DF1D F434 25D7 E87F A1B9 B80F 8062 === signature.asc Description: OpenPGP digital signature
Re: Deployment strategies...
On Fri, 27 Feb 2009, Carl Johnstone wrote: > Perrin Harkins wrote: > > > I've heard people say that DBIx::Class has a slow startup, > > so if you use that you might look there first. > > We do, I'll look. If you're loading the schema from the database instead of defining it from all the modules, it helps to do this in a startup script so the schema loader class gets cloned to kids after figuring out all the table relationships. > On Thu, Feb 26, 2009 at 12:38 PM, Carl Johnstone > wrote: > > 1) We want to run different versions of the same app for > > different sites - this means I have a namespace problem > > for MyApp v1 vs MyApp v2 etc. > > This has been discussed many times on the list. You can't > run two modules with the same name in the same perl > interpreter, so you either need to change the namespaces > for different versions or run separate servers. What about PerlOptions +Parent? http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ Mark
Re: Deployment strategies...
On Fri, Feb 27, 2009 at 3:06 PM, Mark Hedges wrote: > What about PerlOptions +Parent? > http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ That's the thing I was referring to that I haven't tried. Can anyone confirm that this works? - Perrin
Re: Deployment strategies...
Perrin Harkins wrote: On Fri, Feb 27, 2009 at 3:06 PM, Mark Hedges wrote: What about PerlOptions +Parent? http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ That's the thing I was referring to that I haven't tried. Can anyone confirm that this works? There are some threads in the archives from people about it, mostly related to people having trouble with one thing or another though iirc. This post seems to indicate they were using it successfully. http://marc.info/?l=apache-modperl&m=119500073425071&w=2 Adam
tUsing module
Hi This is a beginner question. I want to instantiate an object just once in the lifetime of a script, not on every request. I'm used to Mason where you can use Mason's <%once> block. In mod_perl proper would the equivalent be to instantiate it in a BEGIN block? But it would need to be in scope for the whole script.. Thanks Justin
Apache Mobile Filter
I have done a module for Apache Web Server that recognizes the device and redirect to the correct contents (WML, XHTML etc.) you have defined. Also it's possible to resize dynamically the images depends of the device characteristics. Do you think this module could be useful? The module is Open Source, and the Device Repository is WURFL For more information: http://www.idelfuschini.it/apache-mobile-filter.html
