Re: speeding up CGI.pm
That would be really amazing if it could still be implemented in mp1, too, as it would allow for interoperability between libapreq-based applications (like Apache::UploadMeter) and response handlers like CGI scripts which use CGI.pm I suppose that this isn't such a big problem in mp2 whose filters will probably make using one API for request handling unnecessary... Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:41 AM Subject: speeding up CGI.pm While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: speeding up CGI.pm
I like the idea of that, although the handsprings needed to do ordinary CGI, mp1 and mp2 might lead to a cloud of confusion. Best to keep them in separate modules and load them into CGI as needed. Is Apache::Request in mp2 ready for prime time? We haven't been able to get it running here (some sort of install problem, my people tell me). Lincoln On Tuesday 25 March 2003 03:25 am, Issac Goldstand wrote: That would be really amazing if it could still be implemented in mp1, too, as it would allow for interoperability between libapreq-based applications (like Apache::UploadMeter) and response handlers like CGI scripts which use CGI.pm I suppose that this isn't such a big problem in mp2 whose filters will probably make using one API for request handling unnecessary... Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:41 AM Subject: speeding up CGI.pm While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache-request in mp2
I suppose there might be name clashes, but I'll look into doing that. Lincoln On Monday 24 March 2003 07:08 pm, Stas Bekman wrote: Lincoln Stein wrote: How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it. Sounds interesting. What would be the advantage of that? The advantage is that - you don't have to keep around two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request-new($r); $r = CGI-new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
At least with some versions of perl, the require gets evaluated at compile
time and raises an exception even if it is enclosed by the eval {} braces.
The only way to get around this is to eval the string.
I'm not sure whether this is a current issue or was a problem with 5.00503,
but I've kept it in.
Lincoln
- why eval string:
eval require mod_perl;
shouldn't it be:
eval { require mod_perl };
?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
RE: Oracle9.2 and mod_perl - advice sought
Jim, ODBC is not the way to go for Oracle if you can. Early on I tried using ODBC and I had crashes and hang-ups. Performance is substantially better also. The modules below and the oci libraries in the Oracle install will get it for you. This version works with the 9i Release 2 for me. DBD-Oracle-1.12.tar.gz DBI-1.32.tar.gz Using separate boxes works fine. Chuck -Original Message- From: Jim Morrison [Mailing-Lists] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 10:13 AM To: [EMAIL PROTECTED] Subject: Oracle9.2 and mod_perl - advice sought Hello all, Quick request for advice/direction... I'm about to take receipt of an Oracle 9.2 server - for the development of a site/product/service.. I'm happiest writing Perl - under mod_perl - so I'd like to stick to that, but most importantly I need the solution with the lowest transaction overheads.. (The webserver and OracleDB are going to be on different boxes..) I'm told the best solution is to use SQLNet(?) rather than ODBC.. ?? I've managed to get my XML'ing to a level that allows me to avoid databases thus far ;-) So I have little experience of what the best direction is... Any recommendations of modules, other lists etc.. would be very much appreciated.. Thank you kindly :-) Jimbo
RE: Oracle9.2 and mod_perl - advice sought
The regular DBI (http://search.cpan.org/author/TIMB/DBI-1.35/DBI.pm) with DBD::Oracle (http://search.cpan.org/author/TIMB/DBD-Oracle-1.13/Oracle.pm) will work just fine. To make your life easier, take a look at Class::DBI (http://search.cpan.org/author/TMTM/Class-DBI-0.91/lib/Class/DBI.pm) as well. I am currently using this with mod_perl (on linux) and Oracle 9.2 (on solaris). Dmitri -Original Message- From: Jim Morrison [Mailing-Lists] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:13 PM To: [EMAIL PROTECTED] Subject: Oracle9.2 and mod_perl - advice sought Hello all, Quick request for advice/direction... I'm about to take receipt of an Oracle 9.2 server - for the development of a site/product/service.. I'm happiest writing Perl - under mod_perl - so I'd like to stick to that, but most importantly I need the solution with the lowest transaction overheads.. (The webserver and OracleDB are going to be on different boxes..) I'm told the best solution is to use SQLNet(?) rather than ODBC.. ?? I've managed to get my XML'ing to a level that allows me to avoid databases thus far ;-) So I have little experience of what the best direction is... Any recommendations of modules, other lists etc.. would be very much appreciated.. Thank you kindly :-) Jimbo
Re: Mod_perl 1.99_09dev on AIX4.3.3
ODELL, TODD E (SWBT) wrote: On Mar 24 Stas Bekman Wrote: I've applied some fixes for mod_perl to build on aix. I could only test with aix 5.1 on powerpc. Please test that things work on other configurations. I got 1.99_09dev working on AIX4.3.3/apache 2.0.44 on powerpc_power3. I had trouble with make test, but I'm reviewing the recent messages on that. I decided to see what it would do after make install and it does seem to work. It's shows Apache/2.0.44 (Unix) mod_perl/1.99_09-dev Perl/v5.6.1 PHP/4.3.1. Fantastic! What compiler/loader were you using? on the machine I was testing it was cc_r and ld. What's the output of: % perl -V:ld -V:cc If you provide more details on the 'make test' problems we will try to solve these as well. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
get_server_port (was:Re: run_access_check)
On Mon, 24 Mar 2003, Stas Bekman wrote:
Jie Gao wrote:
Hi All,
I am getting the following error mesg:
Can't locate object method run_access_checker via package Apache::RequestRec
at /usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/xxx/.pm
for the section:
sub handler {
my Apache::Connection $c = shift;
my APR::Socket $socket = $c-client_socket;
my $r = Apache::RequestRec-new($c);
$r-location_merge(__PACKAGE__);
my $rc = $r-run_access_checker();
..
Any idea why?
I am using 2.0.44 with mp2 from cvs.
Guessing that you haven't loaded Apache::HookRun.
% lookup run_access_checker
to use method 'run_access_checker' add:
use Apache::HookRun ();
Thanks, that worked.
I have run into another problem, though. I am writing a
PerlProcessConnectionHandler based on the example in overview of
mod_perl-2.0. It's going to listen on two ports, and I need to know
which port is being used in order to set up other things. But I could
not get get_server_port work.
I have tried:
my $s = $r-server;
my $port = $s-get_server_port;
but got error message:
Can't locate object method get_server_port via package Apache::Server at
/usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/xxx.pm
I haven't been able to find relevant documentation.
Regards,
Jie
Re: get_server_port (was:Re: run_access_check)
Jie Gao wrote: I have run into another problem, though. I am writing a PerlProcessConnectionHandler based on the example in overview of mod_perl-2.0. It's going to listen on two ports, and I need to know which port is being used in order to set up other things. But I could not get get_server_port work. I have tried: my $s = $r-server; my $port = $s-get_server_port; but got error message: Can't locate object method get_server_port via package Apache::Server at /usr/local/perl-5.8.0_threaded/lib/site_perl/5.8.0/xxx.pm I haven't been able to find relevant documentation. it's a request method, $r-get_server_port You probably want: $s-port __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::GD::Thumbnail Question
On Tue, 2003-03-25 at 00:12, Issac Goldstand wrote:
- Original Message -
...snip...
From the man page:
* ThumbnailBaseDir
Sets the directory that contains the images to be thumbnailed. Defaults to
.. if not specified
Since the virtual directory /home/me/pics/thumbs/../ is where the pictures
are (eg, /home/me/pics), I can use the default.
...snip...
Why don't you show me your exact configuration, and I'll see if I can help
you out...
Issac
...another snip...
Hey Issac,
Ok, I've dumbed this down to the lowest common denominator ( in this
case, I qualify as this ). In my httpd.conf I have the following lines:
Alias /pics/ /data/httpd/htdocs/image1/pics/
Directory /data/httpd/htdocs/image1/pics
Order allow,deny
AllowOverride None
Order allow,deny
Allow from all
/Directory
Location /*/pics/thumbs
SetHandler perl-handler
PerlHandler Apache::GD::Thumbnail
PerlSetVar ThumbnailMaxSize 75
/Location
In my script source I have the following line:
$r-print ('PA href=/pics/roses1.jpgIMG
src=/image1/pics/thumbs/roses.jpg/A
I have tried this with the PerlSetVar ThumbnailBaseDir set to the
Location, with PerlModule Apache::GD::Thumbnail, with the OBJECT tag
instead of the IMG tag and they all yield the same 404 Not Found error.
At this point I think that I'm probably missing something really stupid,
considering I am following the man page to the letter. The only thing
missing from the man page is any example of HTML/script usage but that
looks to me as really basic - access the URL and the handler takes over.
Any suggestions would be appreciated.
Steve
--
Steven A. Adams [EMAIL PROTECTED]
Re: BerkeleyDB vs. Linux file system benchmark (on Perlmonks)
On Tue, 2003-03-18 at 14:05, Perrin Harkins wrote: I thought some of you might be interested in this thread from Perlmonks.org: http://perlmonks.org/index.pl?node_id=243899 I benched BerkeleyDB against multiple files for medium-sized documents, and the results were that Berkeley was faster for writes and slower for reads. Just a little update on this: At a suggestion from Aaron Ross, I adjusted the Cachesize parameter for BerkeleyDB, which brought it up to par with the file system for reads on my machine. It seems to work even better on slower machines. See the URL above for details. - Perrin
Re: speeding up CGI.pm
On Tue, 25 Mar 2003, Lincoln Stein wrote:
I like the idea of that, although the handsprings needed to do ordinary CGI,
mp1 and mp2 might lead to a cloud of confusion. Best to keep them in
separate modules and load them into CGI as needed.
Is Apache::Request in mp2 ready for prime time? We haven't been able to get
it running here (some sort of install problem, my people tell me).
Not at all ready. I do not believe even a beta release has been made.
- nick
--
Nick Tonkin {|8^)
