Re: Any harm with PerlRun AND Registry AND regular cgi on the same server?
There is plenty of very helpful documentation about converting cgi scripts to registry scripts, and using PerlRun. But I have been called upon to convert an existing web site so that mod_perl is installed, with some scripts running under PerlRun, some under Registry, and (due to laziness, I think), some will stay in cgi-bin, which remains as it was before installing mod_perl. For this, I have created two new directories, called cgi-run and cgi-reg, with the corresponding scripts. (OK, all scripts could run under PerlRun, but there is a time pressure, and a desire to have at least one script running with Registry...) Any problems to be expected with this approach? I haven't seen mention of this in the documentation or books. Well, it helps when you actually read the documentation :) http://perl.apache.org/guide/config.html#Alias_Configurations _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: hello world benchmarks...
Thanks Rudy! Any way you could throw some of the others into the mix, like Apache::ASP, Embperl, Mason, Registry CGI ? The more data there is, the more useful the benchmarks are, since some of the greatest value comes from how they compare on the same system. I understand if not since these benchmarks take a crazy amount of time to run. It takes no time at all if you use Apache::Benchmark. I still didn't have a chance to release it on CPAN. In fact you can prepare a complete setup for other users to run and all they will have to do is to push the button and voila all the results are printed without you doing a thing. At this moment you can grab it from http://stason.org/works/modules/Apache-Benchmark-0.01.tar.gz _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Perl 5.6 patch for AIX available ?
In the README file it says : =item AIX users If you build mod_perl as a DSO you will get core dumps as soon as you try to use xs modules in perl, e.g. use Fcntl or use Socket. The following patch to perl 5.005_3 does fix that problem: Is there a Perl 5.6 patch available ? -- Per Weisteen!Internet support, Norsk Hydro !Email: [EMAIL PROTECTED] N-0246 Oslo, Norway !Phone: (+47) 2273 8227/ !Web: http://www.hydro.com/
Restarting a modperl server
What is the best way to restart modperl server that a) Reloads all perl modules b) reloads and runs the configuration file and if possible c) Only kills each child after it has finished its request 'kill -USR1 pid' doesn't reload the perl-modules in my test neither does 'kill -HUP pid' I am starting all the modules with a startup.pl script called in the httpd.conf file Any ideas Thanks Mark This e-mail, and any attachment, is confidential. If you have received it in error, please delete it from your system, do not use or disclose the information in any way, and notify me immediately. The contents of this message may contain personal views which are not the views of the BBC, unless specifically stated.
[OT] Apache Bench (ab.c) written as perl XS module?
[OT: already posted to [EMAIL PROTECTED], just thought people here might have suggestions, comments, etc] I am thinking about writing the XS glue for the apache bench tool (ab). The ab code as it is, is not very flexible, but it is damn fast. If I implemented it as a perl XS module, I could add the flexibility into a nice OO package. Is there any interest in such a module? Could it fit in with LWP somehow? I have not tried out LWPng yet - does it use XS code to speed up requests much faster than LWP? At our company we need to write a benchmarking suite, and LWP fits our needs perfectly except for the fact that its just not fast enough. It would be perfect if we could integrate ab with LWP. So, just wanting to get general feedback from the LWP community on whether such software would be useful to others. -Adi
Re: [OT] Apache Bench (ab.c) written as perl XS module?
On Wed, 21 Jun 2000, Adi wrote: [OT: already posted to [EMAIL PROTECTED], just thought people here might have suggestions, comments, etc] I am thinking about writing the XS glue for the apache bench tool (ab). The ab code as it is, is not very flexible, but it is damn fast. If I implemented it as a perl XS module, I could add the flexibility into a nice OO package. Is there any interest in such a module? Could it fit in with LWP somehow? I have not tried out LWPng yet - does it use XS code to speed up requests much faster than LWP? At our company we need to write a benchmarking suite, and LWP fits our needs perfectly except for the fact that its just not fast enough. It would be perfect if we could integrate ab with LWP. So, just wanting to get general feedback from the LWP community on whether such software would be useful to others. I'd love to see something like that. -- 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: [OT] Apache Bench (ab.c) written as perl XS module?
Adi wrote: At our company we need to write a benchmarking suite, and LWP fits our needs perfectly except for the fact that its just not fast enough. It would be perfect if we could integrate ab with LWP. So, just wanting to get general feedback from the LWP community on whether such software would be useful to others. I'd love to see such a thing. I need to put together a benchmark program myself. Why not build on the backs of giants? :-) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: [OT] Apache Bench (ab.c) written as perl XS module?
On Wed, 21 Jun 2000, Adi wrote: [OT: already posted to [EMAIL PROTECTED], just thought people here might have suggestions, comments, etc] I am thinking about writing the XS glue for the apache bench tool (ab). The ab code as it is, is not very flexible, but it is damn fast. If I implemented it as a perl XS module, I could add the flexibility into a nice OO package. Is there any interest in such a module? Could it fit in with LWP somehow? I have not tried out LWPng yet - does it use XS code to speed up requests much faster than LWP? At our company we need to write a benchmarking suite, and LWP fits our needs perfectly except for the fact that its just not fast enough. It would be perfect if we could integrate ab with LWP. So, just wanting to get general feedback from the LWP community on whether such software would be useful to others. Adi, I've already implemented a part of the thing you are talking about. At least the core of it. At this point I've the framework for benchmarking suites and I invoke ab directly and then I have the module that process the results and print the nice output. No manual processing anymore. Replacing ab binary with Perl API to the library is one of the things I'd really like to have in this benchmarking suite. Grab the package from: http://stason.org/work/modules/Apache-Benchmark-0.01.tar.gz And if you like the way it's implemented it would be really cool to work on the further development together. I wrote this software mainly for the book writing, since I'd to run hundreds of tests and it wasn't impossible to get advanced and avoiding errors by having the work done manually. But if you look at the TODO list, there are a few cool ideas for a future extensions that will be very useful for some users. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: mod_perl vs. FastCGI
"Scott Thomason" [EMAIL PROTECTED] writes: I know this must have been discussed before, but a mailing list archive search on "fastcgi" didn't turn up much. What guidelines do you folks follow to determine whether FastCGI or Apache::Registry is a better choice? I've 90% written a little paper on this, with feedback from people on the list. I can do you a rough, or you can badger me to put it properly on my web site... Dave -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Apache, mod_perl, MySQL, Sybase hired gun for, well, hire -
[OT] Apache::Benchmark URL
In the last two post I gave the wrong URL for the module. Sorry for that. So here is the right one. http://stason.org/works/modules/Apache-Benchmark-0.01.tar.gz I still cannot decide whether to call it HTTPD::Benchmark or Apache::Benchmark, therefore it's not on CPAN yet. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: [OT] Apache Bench (ab.c) written as perl XS module?
Stas, Yes, actually I downloaded your Apache::Benchmark a while back, and have looked through it quite a bit. I definitely plan on using it, and agree we should continue further development together. Actually #3 on your Apache::Benchmark TODO was what gave me the idea to do this. Thanks (everyone) for the responses, I'll get back to you all when we have something concrete. -Adi Stas Bekman wrote: Adi, I've already implemented a part of the thing you are talking about. At least the core of it. At this point I've the framework for benchmarking suites and I invoke ab directly and then I have the module that process the results and print the nice output. No manual processing anymore. Replacing ab binary with Perl API to the library is one of the things I'd really like to have in this benchmarking suite. Grab the package from: http://stason.org/work/modules/Apache-Benchmark-0.01.tar.gz And if you like the way it's implemented it would be really cool to work on the further development together.
Apache::DBI
Is it be possible to modify Apache::DBI in sich a way that only database connections specified in a PerlRequired startup.pl with Apache::DBI-connect_on_init(...) are stored and all subsequent DBI-connect(...) connections are properly established (if no matching stored connection is available), but not stored afterwards? Or could Apache::DBI::db::disconnect be changed, so it would actually disconnect, except if it was handling one of the connect_on_init connections? -- Eric Jain
Re: [OT] Apache Bench (ab.c) written as perl XS module?
On Wed, 21 Jun 2000, Adi wrote: Is there any interest in such a module? Could it fit in with LWP somehow? I have not tried out LWPng yet - does it use XS code to speed up requests much faster than LWP? You can't really compare ab and LWP. ab is fast partly because it's not doing anything beyond what's absolutely needed and it's making a bunch of (usually correct) assumptions. So what you're going for should probably be a more flexible ab with a Perl interface, but still with a focus on speed and benchmarks. Not a general http tool (like LWP). - ask -- ask bjoern hansen - http://www.netcetera.dk/~ask/ more than 70M impressions per day, http://valueclick.com
Re: [OT] [JOB] mod_perl and Apache developers wanted
It is interesting and and somewhat ironic that the Engineering dep at eToys is part of the open source community and culture while their management's behavior was so disastrously misguided and so misunderstanding of net culture and precedent. They shot themselves in the foot pretty badly. Would eToys have paid for the legal expenses of the Etoy group if they weren't clued in by their Engineering department? Have they learned a hard lesson? Perrin is an exemplary figure, and I commiserate with him, but some basic precedents of net culture need to be respected for the network to function and the culture to flourish. If we had not protested the attempted eToys domain grab, and I was one who protested, they may have never recanted and Etoy might still be fighting at absurd personal cost. Cheers, Ed Paul Singh wrote: Regardless of what eToys' intentions were, the way I see it, this was a case in which a billion dollar corporation (well, at least it was back then) filed suit against a handful of artists who had the etoy.com domain way before eToys came along. eToys had no legitimate stake to the domain... and I don't associate legitimacy with the law... they seldom coincide. So if this isn't a case of the bigger guy bullying the little guy, what is it? Granted, I have a distant association with the eToy crew so my opinions will be biased... however, even with staying to the facts and ignoring eToys' motivations, their actions alone reek of unfairness (at best). Of course, this says little of what type of work environment eToys is and the people that work there... but it does comment on the corporation and the people running it. But as you said, this is definitely off-topic, and I will cease further comment... take care. - jps -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Friday, June 16, 2000 4:48 PM To: Paul Singh Cc: ModPerl Mailing List Subject: RE: [OT] [JOB] mod_perl and Apache developers wanted On Thu, 15 Jun 2000, Paul Singh wrote: While that may be true (as with many publications), I hope you're not denying the facts of this case The basic facts are correct: eToys received complaints from parents about the content their children found on the etoy.com site and, after failing to reach an agreement with the site's operators, filed a lawsuit involving trademarks which led to etoy being ordered to shut down their site by a judge. Slashdot's coverage ignored or underreported some aspects of the situation (the motivation behind the lawsuit, epxloitation of the name confusion on the part of etoy), and reported some conjecture and pure flights of fancy as fact (evil intentions, scheming lawyers). You have no idea how painful it is to read things like that from a source that you trust and consider part of your community. I guess I should have known better though: Slashdot is an op/ed site. If you want the news, you still have to read the New York Times (who had much more accurate coverage of the events). Anyway, I don't claim that eToys was right to take legal action, just that the reports about an evil empire were greatly exaggerated and that eToys is a good place to work, full of good people. Anyone who doesn't believe me at this point probably never will, so I'm going to stop spamming the list about this subject and go back to spamming about mod_perl. - Perrin
RE: Apache::DBI
-Original Message- From: Eric Jain [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 21, 2000 1:30 PM To: Mod_Perl Subject: Apache::DBI Is it be possible to modify Apache::DBI in sich a way that only database connections specified in a PerlRequired startup.pl with Apache::DBI-connect_on_init(...) are stored and all subsequent DBI-connect(...) connections are properly established (if no matching stored connection is available), but not stored afterwards? I'm not sure why you would want to do such a thing, but I don't think it fits with DBI/Apache::DBI's model... why exactly are you looking for this behavior? --Geoff Or could Apache::DBI::db::disconnect be changed, so it would actually disconnect, except if it was handling one of the connect_on_init connections? -- Eric Jain
Re: document contained no data
I posted the message again because it didn't work when i put $| = 1; or $r-rflush() at top or around print statement as some people suggested. It is very confused. it should work without putting those things. The thing affects performance. What i need to do, your any answers would be very much appreciated. Steven Steven Zhu wrote: Hi, All: We have a coffee site with apache_1.3.9, modperl_1.2.1 and mysql database. It works fine in most time. But sometimes it is strange. For instance, the same script works fine sometimes, but sometimes it popups a window with message "The document contained no data Try again later, or contact the server's administrator". It seems that the print statement does not work fine. Any idea. Thank in advance for your quick reply. Steven.
PerlAuthenHandler and browsers
After working with 4 different types of browsers and the PerlAuthenHandler, I am really unimpressed with browser makers. There are so many ways to convince browsers to resend a username password pair. For that reason, my handler can't rely on browsers to behave during the Authentication phase. I am going to have to find a way to force a user to input his password into the browser not using standard HTTP response codes. What is a reliable way to return a CGI script, and doing something with that response, before returning the page requested by the user? JJ -- J. J. Horner Apache, Perl, Unix, Linux [EMAIL PROTECTED] http://www.knoxlug.org/
Re: PerlAuthenHandler and browsers
On Wed, 21 Jun 2000, J. J. Horner wrote: For that reason, my handler can't rely on browsers to behave during the Authentication phase. I am going to have to find a way to force a user to input his password into the browser not using standard HTTP response codes. Could you elaborate on that a little more, please? What is a reliable way to return a CGI script, and doing something with that response, before returning the page requested by the user? JJ -- Blue Lang Unix Systems Admin QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604 Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
How to log post and put contents?
I'm attempting to write a real-world traffic recorder for volume testing and QAing our site In a URI trans handler I'm getting the complete request via $r-the_request and headers via $r-headers_in. The content is proving to be evasive, however! $r-content is clearly documented to be callable only once. $r-read doesn't mention this, but when I use it, the rest of the site won't operate, handing in the created of a new Apache::Request object. Any ideas? -- -- Tom Mornini -- InfoMania Printing and Prepress
RE: mod_perl vs. FastCGI
There was a recent article in WebTechniques comparing the two http://www.webtechniques.com/archives/2000/05/infrrevu/ -Original Message- From: Scott Thomason [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 21, 2000 4:56 PM To: [EMAIL PROTECTED] Subject: re: mod_perl vs. FastCGI You said: Most people on this list probably have already determined that mod_perl is better for their own needs. That`s why I`m here, at least. But "better" is a very subjective term, and you need to define your parameters. What are your goals, what are your constraints, what is your experience, etc., are all questions you need to answer before you can decide whether one technology is more suitable for you to use on a given project than any other technology. OK, my goal is simple: I want my Perl scripts to run lightening fast, ideally without bloating the memory requirements of my webserver. I'm a good Perl developer. I've used mod_perl a little in the past, and spent many agonizing hours cleaning up one-shot CGI scripts so they would work (and on some, I just plain gave up and let them run slow). Last project, I gave FastCGI a whirl (via mod_fastcgi and CGI::Fast) and was delightfully surprised to find there was no headache involved, only benefit. Which got me to wondering, why all the buzz over Apache::Registry if FastCGI offers the same speed without the server bloat or coding restrictions? So, given that, here's the question again: why would you choose Apache::Registry over FastCGI? I want to be a believer... ---scott
re: mod_perl vs. FastCGI
"ST" == Scott Thomason [EMAIL PROTECTED] writes: ST in the past, and spent many agonizing hours cleaning up one-shot ST CGI scripts so they would work (and on some, I just plain gave up ST and let them run slow). Last project, I gave FastCGI a whirl (via I wonder how these scripts on which you gave up would work with FastCGI. I suspect they have memory leaks. If you write your perl programs well, that is, with "use strict" and warnings turned on, and you get a clean execution, then moving those to mod_perl is pretty much trivial. You just need to be careful about global variables. Another reason to use mod_perl is that you're not just getting the ability to write CGI programs. You get the ability to interact with Apache at *any* phase of its API using perl. That is, if I want to write my own authentication mechanism, I can do it in perl. I don't think you can accomplish that in FastCGI, since this is not a CGI operation, it is a web-server operation. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG MIME spoken herehttp://www.khera.org/~vivek/
Re: mod_perl vs. FastCGI
Scott Thomason wrote: So, given that, here's the question again: why would you choose Apache::Registry over FastCGI? I want to be a believer... First, I don't really recommend Registry, if you're serious about your system you should use the direct handler interface and not just port a bunch of crufty old CGI scripts. Back in 96/97, I built an ecommerce engine using FastCGI Perl. Today my company runs its site on Apache/mod_perl. Both technologies address some similar concerns and are designed to reduce execution overhead and enable persistent application servers to communicate with and modify the behavior of web servers. FastCGI is a protocol for a web server to communicate with an application server over network sockets. It also includes some primitive process management facility, I believe. mod_perl is an in-process integration of the Perl interpreter with the Apache web server. When I was using FastCGI, mod_perl was relatively immature. FastCGI worked but also was suffering from the support abandonment of its inventor Open Market. We had to debug several problems with the open source FastCGI code in our environment and there was relatively little support. But we got it to work, and it did work well in production. When we set out to implement our second generation ecommerce engine, we re-evaluated and choose to use mod_perl primarily because it had accumulated a vastly larger user base, resulting in a more mature environment and far superior support resources. I still think this is mod_perl's chief advantage over FastCGI. I've never worried over-much about porting old CGI scripts to either environment so can't speak to either technology's efficacy for this use. FastCGI pros: Web-server independant Language independant mod_perl pros: Larger user base, more real-world implementations More extensive support infrastruction: the guide, this list, etc. Extensive library of modular extensions which have been designed and tested to be used in the mod_perl environment Greater web server integration -- 14 handler hooks for mod_perl: PerlChildInitHandler PerlPostReadRequestHandler PerlInitHandler PerlTransHandler PerlHeaderParserHandler PerlAccessHandler PerlAuthenHandler PerlAuthzHandler PerlTypeHandler PerlFixupHandler PerlHandler PerlLogHandler PerlCleanupHandler PerlChildExitHandler vs 3 server hooks for FastCGI: Responder Authorizer Filter Which one to use should depend on what your needs and experience are. Properly tuned implementations of either will have very similar performance and resource utilization characteristics. -- Devin Ben-Hur | President / CTO | mailto:[EMAIL PROTECTED] The eMarket Group | eMerchandise.com | http://www.eMerchandise.com 503/944-5044 x228 | "Forrester Research projects that by 2003, Internet start-ups will have focused so relentlessly on infrastructure that there will be no remaining actual content on the Web. " -- Salon.com 14-Apr-2000
Re: mod_perl vs. FastCGI
On Wed, 21 Jun 2000, Devin Ben-Hur wrote: Scott Thomason wrote: So, given that, here's the question again: why would you choose Apache::Registry over FastCGI? I want to be a believer... First, I don't really recommend Registry, if you're serious about your system you should use the direct handler interface and not just port a bunch of crufty old CGI scripts. Why's that? I'm relatively new to mod_perl, at least in the sense of what I've been using it for - what're the advantages of going with the direct handler interface as opposed to registry? TIA... e.
Re: [OT] Enough about etoys!
At 01:49 PM 6/21/00 -0500, Jeff Gleixner wrote: Ed Phillips wrote: It is interesting and and somewhat ironic that the Engineering dep at eToys [...] Paul Singh wrote: Enough already! Please stop posting non-mod_perl related drivel to this list! It is neither ironic nor interesting and it's not why people have signed-up for this list. Yes, this message isn't related. Sorry all. I'm just fed up with this noise. Yeah, but it should be [OT] Enough about etoys! :) Believe it or not , some people do explicitly filter out OT's so it's considered etiquette to put that. However, with that said, my impression is that OT topics were at least moderately associated with mod_perl even if not directly. This is just really really not associated with mod_perl directly or indirectly (from a technical level) and so although I read OT posts, I really hate this thread. Especially when it's clearly not a black and white issue and too emotional for a mailing list. I also do not want to hear this talk anymore, stuff like this is better for slashdot. (And it's one of the reasons I stopped reading slashdot although I was an addict for a long while). I am also a ashamed at the thought of people new to mod_perl joining this list and seeing these occasional nasty messages back and forth(whether warranted or not there are other forums for this type of thing). I prefer if we keep this list professional and as ON TOPIC (OT ... :)) as possible even for OT messages. Newbies don't really always understand OT abbreviation and what it means either. Later, Gunther
RE: Any reason not to SSI include Registry scripts?
Hey, I'm doing this too! I use #include virtual to invoke
my CGI scripts to embed some dynamic objects. But to do so
my scripts have to add a if-construct to get the query string
when running as a SSI script:
if ($ENV{SERVER_PROTOCOL} eq 'INCLUDED') {
($qstr) =~ ($ENV{REQUEST_URI} =~ /\?(.*)/);
$q = new CGI $qstr;
} else {
$q = new CGI;
}
yeah, this is ugly, but i'm doing this anyway.
hope this helps.
kenneth
-Original Message-
From: Michael Todd Glazier [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 22, 2000 9:36 AM
To: [EMAIL PROTECTED]
Subject: Any reason not to SSI include Registry scripts?
As a way to speed up the CGIs but allow my designers easy access to
the html file, I'm executing an Apache::Registry CGI script from
within an .shtml document using #exec cgi . The Apache manual says to
prefer use of #include virtual, but that doesn't pass the query
string from the request. In a way this is a hacked template system. :)
Is there a reason, barring the known fact it would be faster as a
full blown module :), not to use this set-up?
Thanks!
- mt
