Re: tracking down why a module was loaded?;
"One or two mod_perlers could do the work of a java shop of ten in half the time." Can we prove this ? Does anyone have any real evidence to support this claim. I hope so because I need to defend my use of mod_perl in developing the intranet site for my company ;-) All my experience suggests that this is true but sometimes the PHB's insist on the numbers. Simon. From ed [EMAIL PROTECTED]Date 26 September 2000 To Gunther Birznieks [EMAIL PROTECTED]Time 20:50 Copy to[EMAIL PROTECTED] (bcc: Simon Wilcox/BASE/WilliamsLea) Bcc Simon Wilcox/BASE/WilliamsLea Fax to Subject Re: tracking down why a module was loaded?; Gunther Birznieks wrote: I unfortunately have to agree. snip And in the end, the salaries for mod_perl programmers are pretty high right now because of it -- so will a system really cost less to develop in mod_perl than in Java if Java programmers are becoming less expensive than mod_perl programmers? /snip Mod_perl programmers are more expensive as individuals, because mod_perl is more powerful, and allows you access to the Apache API; mod_perlers are more saavy. One or two mod_perlers could do the work of a java shop of ten in half the time. Still a savings. Not to mention the hardware that goes with Java by fiat! ed __ This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or reply on this email.
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Gunther Birznieks wrote: At 10:28 PM 9/26/2000 +0200, Alexander Farber (EED) wrote: Doug MacEachern wrote: modperl is the best kept secret on the net. Shame! seems to generate plenty of list traffic for a "secret" ;) Don't you all think, that mod_perl isn't promoted enough and this will kill it someday, despite its technical goodness? Perl in general too, although I disagree with Stas on this one. (we discussed it in the pub on the first night of the conference). - There are no articles in the "mainstream" computer press (like cnet.com, www.ix.de, etc) about mod_perl. True, but then you need to explain the apache phenomenon first, and too many corporates want to deal only with corporates, making them feel a need to use IIS (with no mod_perl :/ ) - There are no benchmarks, comparing to Java/Coldfusion/whatever. None of these give you anything like the hooks that mod_perl gives you, though, so in general they are uncomparable. CF is pig-slow, and java - well. :) - I work at a big telco, and no one cares/knows here about mod_perl (except our intranet-webmaster, who still prefers PHP, since it makes him less trouble). Again, not comparable. I have written a quick hack auth system that hooks into uri translation, try doing that under any other system. - People, who have heard about mod_perl, are looking for servlet/ JSP-programmers, because mod_perl-coders are hard to find. perhaps. Mod_perl jobs are hard to find too... :/ I unfortunately have to agree. perhaps. Depending on where you go Perl programmers may be easier to find that Java programmers, but finding an existing mod_perl programmer is not easy. It's doable, but not easy. And in the end, the salaries for mod_perl programmers are pretty high right now because of it -- so will a system really cost less to develop in mod_perl than in Java if Java programmers are becoming less expensive than mod_perl programmers? I have yet to see companies in this country really advertising for mod_perl jobs. The company where I currently work mentions it, but we're not really looking for it very hard, and if they've done any perl, we mostly teach them about the templating system we use (yes, yet another one, and going on CPAN soon :) We all have to do our part to evangelize mod_perl more. I think ISPs are really key here as I think I may have mentioned before. If you get the ISPs Well, I can tell you for a fact that mod_perl is running on http://www.bluepet.co.uk/ http://www.freedomjewellery.com/ http://www.londontransport.co.uk/ http://www.swisslife.com/ http://www.sciencephoto.com/ (the current version uses PerlRun, but the new version will be all mod_perl) supporting and evangelizing mod_perl (and pre-installed mod_perl applications) then you will get users using it and liking it. How many ISPs Yes, but the way it runs does raise problems for security advertise support for mod_perl? How many without charging like US$100 more a month on top of the normal account fees? This is difficult, due to the security issues. If you have client cgi, you can always use something like suEXEC or even something as complex as userv to run your cgi scripts. With mod_perl, the plugged in scripts can do anything that the webserver can, and you can (by writing a module that doesn't compile) break the entire webserver. PHP comes with a lot of ISP accounts for free with no extra cost. Java does not yet, but I've started seeing ISPs starting to support Java in the low end shared server accounts... Wow. I'm surprised, for the security reasons I've outlined above. But then I don't know much about PHP, really. MBM -- UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote: We all have to do our part to evangelize mod_perl more. I think ISPs are really key here as I think I may have mentioned before. If you get the ISPs Actually I think the people we need to get involved are the web site builders - the larger companies offering dynamic web content creation. We also need some more mainstream tools, the oft-requested "Zope-a-like" in Perl. And it needs to be trivial to install (I'm not sure how likely that is to be yet). advertise support for mod_perl? How many without charging like US$100 more a month on top of the normal account fees? This is difficult, due to the security issues. If you have client cgi, you can always use something like suEXEC or even something as complex as userv to run your cgi scripts. With mod_perl, the plugged in scripts can do anything that the webserver can, and you can (by writing a module that doesn't compile) break the entire webserver. PHP comes with a lot of ISP accounts for free with no extra cost. Java does not yet, but I've started seeing ISPs starting to support Java in the low end shared server accounts... Wow. I'm surprised, for the security reasons I've outlined above. But then I don't know much about PHP, really. PHP can runs as a normal CGI, using suExec. So it's like advertising Perl support. What would help mod_perl is a working sandboxing system, based on Safe and SafeHole. I've advocated that idea before, but still don't have the time to go and build it. With that sort of system, and ISP could easily trap or prevent whatever they need to, and we could work with them to build up secure proffessional installations. However, I'm honestly not sure if the whole of mod_perl is "right" for the majority of small fee ISP's. What the ISP's need is perhaps one of the mod_perl modules, like Mason, Embperl or AxKit, or something like that. Rather than letting users write PerlInitHandlers! Unfortunately I have no idea how you might secure one of these modules, even though one is my own. -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org | AxKit: http://axkit.org
Re: tracking down why a module was loaded?;
On Wed, 27 Sep 2000, Matt Sergeant wrote: On Wed, 27 Sep 2000, Matthew Byng-Maddick wrote: Actually I think the people we need to get involved are the web site builders - the larger companies offering dynamic web content creation. We also need some more mainstream tools, the oft-requested "Zope-a-like" in Perl. And it needs to be trivial to install (I'm not sure how likely that is to be yet). This is roughly the kind of company I work for, so agreed. PHP comes with a lot of ISP accounts for free with no extra cost. Java does not yet, but I've started seeing ISPs starting to support Java in the low end shared server accounts... Wow. I'm surprised, for the security reasons I've outlined above. But then I don't know much about PHP, really. PHP can runs as a normal CGI, using suExec. So it's like advertising Perl support. Right. What would help mod_perl is a working sandboxing system, based on Safe and SafeHole. I've advocated that idea before, but still don't have the time to go and build it. With that sort of system, and ISP could easily trap or prevent whatever they need to, and we could work with them to build up secure proffessional installations. Schwern and I were discussing a new mechanism for a sandbox in Perl6, but unfortunately, I'm not sure how trivial it would be for Perl5, and also, you have to wonder whether any improvement will take away any performance advantage that mod_perl gives you. However, I'm honestly not sure if the whole of mod_perl is "right" for the majority of small fee ISP's. What the ISP's need is perhaps one of the mod_perl modules, like Mason, Embperl or AxKit, or something like that. Rather than letting users write PerlInitHandlers! Unfortunately I have no idea how you might secure one of these modules, even though one is my own. With difficulty. :) that wasn't helpful - but we really need a perl sandboxing mechanism. (perhaps if you can use safe to restrict open(), socket(), creat() etc, then you're doing the right thing) MBM -- UNIX is hot. It's more than hot. It's steaming. It's quicksilver lightning with a laserbeam kicker. -- Michael Jay Tucker
Re: tracking down why a module was loaded?;
Doug MacEachern wrote: modperl is the best kept secret on the net. Shame! seems to generate plenty of list traffic for a "secret" ;) Don't you all think, that mod_perl isn't promoted enough and this will kill it someday, despite its technical goodness? - There are no articles in the "mainstream" computer press (like cnet.com, www.ix.de, etc) about mod_perl. - There are no benchmarks, comparing to Java/Coldfusion/whatever. - I work at a big telco, and no one cares/knows here about mod_perl (except our intranet-webmaster, who still prefers PHP, since it makes him less trouble). - People, who have heard about mod_perl, are looking for servlet/ JSP-programmers, because mod_perl-coders are hard to find.
Re: tracking down why a module was loaded?;
At 10:28 PM 9/26/2000 +0200, Alexander Farber (EED) wrote: Doug MacEachern wrote: modperl is the best kept secret on the net. Shame! seems to generate plenty of list traffic for a "secret" ;) Don't you all think, that mod_perl isn't promoted enough and this will kill it someday, despite its technical goodness? - There are no articles in the "mainstream" computer press (like cnet.com, www.ix.de, etc) about mod_perl. - There are no benchmarks, comparing to Java/Coldfusion/whatever. - I work at a big telco, and no one cares/knows here about mod_perl (except our intranet-webmaster, who still prefers PHP, since it makes him less trouble). - People, who have heard about mod_perl, are looking for servlet/ JSP-programmers, because mod_perl-coders are hard to find. I unfortunately have to agree. Depending on where you go Perl programmers may be easier to find that Java programmers, but finding an existing mod_perl programmer is not easy. It's doable, but not easy. And in the end, the salaries for mod_perl programmers are pretty high right now because of it -- so will a system really cost less to develop in mod_perl than in Java if Java programmers are becoming less expensive than mod_perl programmers? We all have to do our part to evangelize mod_perl more. I think ISPs are really key here as I think I may have mentioned before. If you get the ISPs supporting and evangelizing mod_perl (and pre-installed mod_perl applications) then you will get users using it and liking it. How many ISPs advertise support for mod_perl? How many without charging like US$100 more a month on top of the normal account fees? PHP comes with a lot of ISP accounts for free with no extra cost. Java does not yet, but I've started seeing ISPs starting to support Java in the low end shared server accounts... Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: tracking down why a module was loaded?;
Gunther Birznieks wrote: I unfortunately have to agree. snip And in the end, the salaries for mod_perl programmers are pretty high right now because of it -- so will a system really cost less to develop in mod_perl than in Java if Java programmers are becoming less expensive than mod_perl programmers? /snip Mod_perl programmers are more expensive as individuals, because mod_perl is more powerful, and allows you access to the Apache API; mod_perlers are more saavy. One or two mod_perlers could do the work of a java shop of ten in half the time. Still a savings. Not to mention the hardware that goes with Java by fiat! ed
Re: tracking down why a module was loaded?
Thanks for the hint. It worked perfectly. I didnt connect
Cluck, and BEGIN. doh.
nobody spotted the unintended irony in my question ..
perl-status itself (Apache::Status) was the one pulling in CGI.pm !!
Turns out, if you load Apache::Request before Apache::Status,
it uses that instead of the (large) CGI.pm .. that wasnt mentioned
in my Apache::Status manual :-(
-Justin
On Thu, Sep 14, 2000 at 10:46:39PM +0200, Stas Bekman wrote:
On Thu, 14 Sep 2000, Justin wrote:
Can anyone tell me the easiest slickest way of determining
what was responsible for requesting a module, having discovered
that it has been loaded when viewing perl-status?
A.pm:
-
package A;
use Carp ();
BEGIN { Carp::cluck("I don't want to wake up!!!")}
1;
test.pl
---
require "A.pm";
now run:
% perl test.pl
I don't want to wake up!!! at A.pm line 4
A::BEGIN() called at A.pm line 4
eval {...} called at A.pm line 4
require A.pm called at test.pl line 1
Also see:
perldoc -f caller
and while I've got the podium:
I would like to congratulate Doug and
everyone involved in modperl.. by checking
pcdataonline.com, I found our entirely modperl site is
now #1850 in the top 10,000 websites, with over 10 million
*entirely dynamic* pages pushed out a month.. to half a
million unique users. This is a single Dell 2300 box with
two PII 450s cpus and a gig of memory.. (the mysql server
is on another box). Most pages are built between 20-100ms
of user time.. the same box runs backend and frontend
servers, serves images as well, plus a hunk of other
processes.
If a fortune500 company asked razor fish / concrete media
to build them a website that would scale to that, with
entirely dynamic pages, they'd be dragging the client down
to Sun to pick out the color of their enterprise 4000, or
microsoft would be pushing a cluster of multi processor
compaqs and NT servers with all possible software trimmings
added.. and then you'd need a team of specialists to keep
the whole thing moving.. no wonder dotcoms go broke.
Wow! That's cool!
modperl is the best kept secret on the net. Shame!
:)
_
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://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
--
Justin Beech http://www.dslreports.com
Phone:212-269-7052 x252 FAX inbox: 212-937-3800
mailto:[EMAIL PROTECTED] --- http://dslreports.com/contacts
Re: tracking down why a module was loaded?;
On Fri, 15 Sep 2000, Matt Sergeant wrote:
On Thu, 14 Sep 2000, Justin wrote:
Can anyone tell me the easiest slickest way of determining
what was responsible for requesting a module, having discovered
that it has been loaded when viewing perl-status?
use OtherPackage; # because you need import to be defined first
sub OtherPackage::import {
warn join(':', caller), " tried to load me\n";
}
Not really. import() is not called for any of these.
use Foo ();
require Foo;
do Foo;
BEGIN{}+cluck in the code or just cluck will do per my original reply.
Not foolproof, and could cause more damage than good, but sometimes its a
useful debugging technique.
modperl is the best kept secret on the net. Shame!
Indeed!
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
_
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://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: tracking down why a module was loaded?;
On Fri, 15 Sep 2000, Stas Bekman wrote:
On Fri, 15 Sep 2000, Matt Sergeant wrote:
On Thu, 14 Sep 2000, Justin wrote:
Can anyone tell me the easiest slickest way of determining
what was responsible for requesting a module, having discovered
that it has been loaded when viewing perl-status?
use OtherPackage; # because you need import to be defined first
sub OtherPackage::import {
warn join(':', caller), " tried to load me\n";
}
Not really. import() is not called for any of these.
use Foo ();
require Foo;
do Foo;
BEGIN{}+cluck in the code or just cluck will do per my original reply.
Yep, its a better solution in most cases, except you have to edit the
original package for it to work. Sometimes thats not possible (e.g. on a
system you don't have admin rights for). So two solutions to the problem
are simply good to know.
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
tracking down why a module was loaded?;
Can anyone tell me the easiest slickest way of determining what was responsible for requesting a module, having discovered that it has been loaded when viewing perl-status? and while I've got the podium: I would like to congratulate Doug and everyone involved in modperl.. by checking pcdataonline.com, I found our entirely modperl site is now #1850 in the top 10,000 websites, with over 10 million *entirely dynamic* pages pushed out a month.. to half a million unique users. This is a single Dell 2300 box with two PII 450s cpus and a gig of memory.. (the mysql server is on another box). Most pages are built between 20-100ms of user time.. the same box runs backend and frontend servers, serves images as well, plus a hunk of other processes. If a fortune500 company asked razor fish / concrete media to build them a website that would scale to that, with entirely dynamic pages, they'd be dragging the client down to Sun to pick out the color of their enterprise 4000, or microsoft would be pushing a cluster of multi processor compaqs and NT servers with all possible software trimmings added.. and then you'd need a team of specialists to keep the whole thing moving.. no wonder dotcoms go broke. modperl is the best kept secret on the net. Shame! - Justin Beech http://www.dslreports.com
Re: tracking down why a module was loaded?;
On Thu, 14 Sep 2000, Justin wrote:
Can anyone tell me the easiest slickest way of determining
what was responsible for requesting a module, having discovered
that it has been loaded when viewing perl-status?
A.pm:
-
package A;
use Carp ();
BEGIN { Carp::cluck("I don't want to wake up!!!")}
1;
test.pl
---
require "A.pm";
now run:
% perl test.pl
I don't want to wake up!!! at A.pm line 4
A::BEGIN() called at A.pm line 4
eval {...} called at A.pm line 4
require A.pm called at test.pl line 1
Also see:
perldoc -f caller
and while I've got the podium:
I would like to congratulate Doug and
everyone involved in modperl.. by checking
pcdataonline.com, I found our entirely modperl site is
now #1850 in the top 10,000 websites, with over 10 million
*entirely dynamic* pages pushed out a month.. to half a
million unique users. This is a single Dell 2300 box with
two PII 450s cpus and a gig of memory.. (the mysql server
is on another box). Most pages are built between 20-100ms
of user time.. the same box runs backend and frontend
servers, serves images as well, plus a hunk of other
processes.
If a fortune500 company asked razor fish / concrete media
to build them a website that would scale to that, with
entirely dynamic pages, they'd be dragging the client down
to Sun to pick out the color of their enterprise 4000, or
microsoft would be pushing a cluster of multi processor
compaqs and NT servers with all possible software trimmings
added.. and then you'd need a team of specialists to keep
the whole thing moving.. no wonder dotcoms go broke.
Wow! That's cool!
modperl is the best kept secret on the net. Shame!
:)
_
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://jazzvalley.com
http://singlesheaven.com http://perlmonth.com perl.org apache.org
Re: tracking down why a module was loaded?;
On Thu, 14 Sep 2000, Justin wrote:
Can anyone tell me the easiest slickest way of determining
what was responsible for requesting a module, having discovered
that it has been loaded when viewing perl-status?
use OtherPackage; # because you need import to be defined first
sub OtherPackage::import {
warn join(':', caller), " tried to load me\n";
}
Not foolproof, and could cause more damage than good, but sometimes its a
useful debugging technique.
modperl is the best kept secret on the net. Shame!
Indeed!
--
Matt/
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
