[OT] Re[2]: temporal directory used by apache/mod-perl?
Hello Hector Pizarro,
Wednesday, June 18, 2003, 12:21:54 AM, you wrote:
HP Apache::Request has a bug, it doesn't throw an error code when the file is
HP partially uploaded. That's why I'm using Apache read() instead. Any idea
HP how tosetup the temporal directory for mod-perl without Apache::Request?
What's wrong with TEMP_DIR ?
my $apr = Apache::Request-new($r, TEMP_DIR = /home/httpd/tmp);
HP my
$upload = $apr-upload('file');
$upload-link(/home/user/myfile) || warn link failed: $!;
see: perldoc Apache::Request
--
WBR, Mike P. Mikhailov
mailto: [EMAIL PROTECTED]
ICQ:280990142
My mother always used to tell me, The early bird gets the worm.
HP --
HP Hector Pizarro
HP Amautatech
Sorry, I'm mislead somewhere :(. So, you reading post data by itself,
right? And *you* choose where temporary folder will be. Choose it on
the same FS as target folder and use rename :) Or use File::Copy 'move'
function which will copy file content if src and trg on different FS.
Or `mv $src $trg`. TIMTOWTDI.
But this is a far away from mod_perl topic.
--
WBR, Mike P. Mikhailov
mailto: [EMAIL PROTECTED]
ICQ:280990142
Always listen to experts. They'll tell you what can't be done, and why. Then do it.
doc discrepancy?
Hi! Just doing some late night reading, and found something in the second paragraph under the PerlAuthenHandler heading in the following webpage: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthenHandler !--- Otherwise the handler returns *|Apache::AUTH_REQUIRED|* to indicate that the user has not authenticated successfully. --- According to: http://perl.apache.org/docs/2.0/user/porting/compat.html#Deprecated_Constants AUTH_REQUIRED is depracated in favor of HTTP_UNAUTHORIZED. Is Apache actually returning AUTH_REQUIRED, which is then aliased behind the scenes? (I have been using HTTP_UNAUTHORIZED successfully in conjunction with both versions of modperl...) thanks, speeves cws
Re: mod_perl slower than expected? - Test Code!
Hi there, On Wed, 18 Jun 2003, Trevor Phillips wrote: Whether it's i686 or i386 - both mod_perl and FastCGI are using the same compile of perl - so what difference should there be? Must have got my wires crossed somewhere - I thought you must be using different Perls. 73, Ged.
Re: mp2: right place to unescape HTML?
Stas Bekman wrote:
Carl Brewer wrote:
I'm using Stas's read_post() call from the test
directory in mp1.99-10-dev, and am using it
to grab POST data of the form of an email
address ..
this is giving me this :
read_post returned : username=carl%40somewherepassword=foo
Escaped the @ ... of course.
I'm curios, where's the best place to unescape it?
Should I do it in the read_post function, or afterwards?
Recommendations?
Look at CGI.pm, you could easily prototype your code after it, as it's
written in pure perl. Hint: look at the function param().
For the archives, if anyone's interested, I used CGI::Util::unescape()
My read_lines() subroutine is now (cribbed extensively from
Stas's test scripts) :
$post_params = read_post($r);
sub read_post {
use Apache::Filter ();
use APR::Bucket ();
use APR::Brigade ();
use constant IOBUFSIZE = 8192;
use Apache::Const -compile = qw(MODE_READBYTES);
use APR::Const-compile = qw(SUCCESS BLOCK_READ);
use CGI::Util;
my $r = shift;
my $debug = shift || 0;
my @data = ();
my $seen_eos = 0;
my $filters = $r-input_filters();
my $ba = $r-connection-bucket_alloc;
my $bb = APR::Brigade-new($r-pool, $ba);
do {
my $rv = $filters-get_brigade($bb,
Apache::MODE_READBYTES, APR::BLOCK_READ, IOBUFSIZE);
if ($rv != APR::SUCCESS) {
return $rv;
}
while (!$bb-empty) {
my $buf;
my $b = $bb-first;
$b-remove;
if ($b-is_eos) {
warn EOS bucket:\n if $debug;
$seen_eos++;
last;
}
my $status = $b-read($buf);
warn DATA bucket: [$buf]\n if $debug;
if ($status != APR::SUCCESS) {
return $status;
}
push @data, $buf;
}
$bb-destroy;
} while (!$seen_eos);
my $string = join '', @data;
return CGI::Util::unescape($string);
}
Seems to work ok in lieu of Apache::Request being available.
Carl
Re: mp2: Session method not seeming to set extra records?
Carl Brewer wrote: I'm an idiot :) It's important that the user accessing a MySQL database to do any work with Apache::Session::MySQL or Session have update permission as well as insert, select and delete on the sessions table. Carl
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hey Sorry - it took 30 mins to receive the confirmation (wasn't sure if it went through successfully the 1st time)... Anyway, I don't have a BUG to report - all I want to know is, is it SAVE to run non-LFS Apache with LFS Perl using mod_perl LFS. It works...sure...but I'm not sure what the outcome will be if I deploy this solution into our production environment. Intermittent Segmentation Faults? Again...sorry for the 'impatience' but I need to make a decision today if we're to go ahead with this solution... Regards, Jaco Greyling -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 03:36 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) [EMAIL PROTECTED] wrote: Guys, anyone with experience on the below problem??? why reposting the same question 3 times? Please give people some time to respond to your questions, you can't expect an immediate reply. Please advice, I would really appreciate the help. [...] Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... Sounds like the right place to me. We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? You have to send a complete problem report as explained here, including a core dump's back trace: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... __ 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 Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Perl 6 + mod_perl
Hi, I've just been reading Stas + Eric's new book - it looks great - well done to everyone involved! The Apache 2.0, mp2 section is really interesting and when things stabilise here at turbo10.com we will change over to it in production. While reading this section I wondered how Parrot would fit into the interpreter pool scheme available in mp2? Has anyone got any theories on how Perl 6 and mod_perl may merge in the future? Or will Perl 6 Web Applications go down the Java track and execute in JBoss-esque application servers? I know this is really speculative but I think it would be fun to discuss NIge -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: doc discrepancy?
Shannon Eric Peevey wrote: Hi! Just doing some late night reading, and found something in the second paragraph under the PerlAuthenHandler heading in the following webpage: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAuthenHandler !--- Otherwise the handler returns *|Apache::AUTH_REQUIRED|* to indicate that the user has not authenticated successfully. --- According to: http://perl.apache.org/docs/2.0/user/porting/compat.html#Deprecated_Constants AUTH_REQUIRED is depracated in favor of HTTP_UNAUTHORIZED. Is Apache actually returning AUTH_REQUIRED, which is then aliased behind the scenes? (I have been using HTTP_UNAUTHORIZED successfully in conjunction with both versions of modperl...) Thank you, Shannon, I've corrected that document as per your advice. __ 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
[RELEASE CANDIDATE] Apache::Test 1.03-dev
I've uploaded 1.03's release candidate. If nobody finds any faults, I'll upload it tomorrow on CPAN. (libapreq needs to rely on 1.03 fixes to release its 1.2's version). Please try it out: http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz Test it with mod_perl 1.0: perl Makefile.PL -httpd /path/to/1.x/httpd make test and with mod_perl 2.0: perl Makefile.PL -httpd /path/to/2.x/httpd make test Alternatively you can do: APACHE=/path/to/1.x/httpd perl Makefile.PL make test or for C-style shell users: env APACHE=/path/to/1.x/httpd perl Makefile.PL make test __ 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
MS SQL Server
Anyone got any experience of doing MS SQL Server from mod_perl on Linux (via the FreeTDS drivers)? Any gotchas I should be aware of? I have a very high performance requirements application (millions of hits/day) and I need to know the architecture can cope with it (the alternative being PostgreSQL). -- !-- Matt -- :-get a SMart net/:- Spam trap - do not mail: [EMAIL PROTECTED]
ANNOUNCE: Cache::Mmap 0.07
Anyone running 0.05 on perl 5.6.0 or later should upgrade to this version, unless they are absolutely sure that none of their cached data contains UTF8 encoded characters. I didn't think my data did, but my caches were exhibiting some very peculiar behaviour because of it. From the README: This module provides a shared cache, using a memory mapped file. Very useful for mod_perl applications. If routines are provided which interact with the underlying data, access to the cache is completely transparent, and the module handles all the details of refreshing cache contents, and updating underlying data, if necessary. Changes since version 0.05 Add a check for super-sized entries (those which extend past the bucket end) Make zero-sized check message include cache filename and key Add t/03corrupt.t to check that the corruption checks are working Deal with utf8 properly (and add t/04utf8.t) This changes the file format, so added format version number to file header Existing files which aren't cache files are not overwritten From: PAUSE [EMAIL PROTECTED] To: Peter Haworth [EMAIL PROTECTED] Subject: CPAN Upload: P/PM/PMH/Cache-Mmap-0.07.tar.gz Date: Tue, 17 Jun 2003 20:54:32 +0200 The uploaded file Cache-Mmap-0.07.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PM/PMH/Cache-Mmap-0.07.tar.gz size: 19897 bytes md5: 1288f95fa9a86a83c0884602b69597f1 No action is required on your part Request entered by: PMH (Peter Haworth) Request entered on: Tue, 17 Jun 2003 18:52:52 GMT Request completed: Tue, 17 Jun 2003 18:54:32 GMT Thanks, -- paused, v343 -- Peter Haworth [EMAIL PROTECTED] i like Sample A because it tastes great and is less typing. -- brian d foy in c.l.p.misc
Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
[EMAIL PROTECTED] wrote: Hey Sorry - it took 30 mins to receive the confirmation (wasn't sure if it went through successfully the 1st time)... Anyway, I don't have a BUG to report - all I want to know is, is it SAVE to run non-LFS Apache with LFS Perl using mod_perl LFS. It works...sure...but I'm not sure what the outcome will be if I deploy this solution into our production environment. Intermittent Segmentation Faults? Ah sorry then, I thought I'm concerned about Segmentation Faults meant that you had such. You can rebuild Apache with: CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Assuming that you don't trip on any functions that Apache considers unsafe on your os with largefiles enabled. See Makefile.PL for more info. The point is: You need to have both components to agree on sizeof() the vars they use. If they don't at best you will get immediate problem, at worst there will be subtle problems happening only in certain situations. It may work OK, if you call only methods which use variables, whose sizeof() doesn't change when LARGE_FILES are enabled. I know it's a big pain :( Same in mod_perl 2.0 and Apache 2.0. e.g. we have a problem with APR::PerlIO, and it seems that I've worked around it, by disabling -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 only for building this module, if perl was built with large files support. Your safest bet is to have both components compiled with the same large file flags. Again...sorry for the 'impatience' but I need to make a decision today if we're to go ahead with this solution... Understood. __ 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: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Thanks for your prompt response! We did compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 but we're trying to move away from this now, because of vendors like IBM and Oracle not willing to re-compile (websphere mods and mod_ossos) with the same flags. Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution. Like I said before Doug MacEachern actually allows you to get away with this in mod_perl 1.27 (with mod_perl 1.24 it would squeal and terminate during compile time). Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. Is there another low level consideration I'm not taking into account? Last but not least...Perl 5.6.1 and greater compiles with LFS (default) and Apache has always compiled without it (unless you specifically specify it). Did you re-compile Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64? Thanks again, Jaco Greyling -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 10:59 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: Re: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) [EMAIL PROTECTED] wrote: Hey Sorry - it took 30 mins to receive the confirmation (wasn't sure if it went through successfully the 1st time)... Anyway, I don't have a BUG to report - all I want to know is, is it SAVE to run non-LFS Apache with LFS Perl using mod_perl LFS. It works...sure...but I'm not sure what the outcome will be if I deploy this solution into our production environment. Intermittent Segmentation Faults? Ah sorry then, I thought I'm concerned about Segmentation Faults meant that you had such. You can rebuild Apache with: CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64. Assuming that you don't trip on any functions that Apache considers unsafe on your os with largefiles enabled. See Makefile.PL for more info. The point is: You need to have both components to agree on sizeof() the vars they use. If they don't at best you will get immediate problem, at worst there will be subtle problems happening only in certain situations. It may work OK, if you call only methods which use variables, whose sizeof() doesn't change when LARGE_FILES are enabled. I know it's a big pain :( Same in mod_perl 2.0 and Apache 2.0. e.g. we have a problem with APR::PerlIO, and it seems that I've worked around it, by disabling -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 only for building this module, if perl was built with large files support. Your safest bet is to have both components compiled with the same large file flags. Again...sorry for the 'impatience' but I need to make a decision today if we're to go ahead with this solution... Understood. __ 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 Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev
[Xavier, please keep reports on the list so others won't have to duplicate the effort for reported platforms/setups ;) thanks ] Xavier Noria wrote: On Wednesday 18 June 2003 11:13, Stas Bekman wrote: I've uploaded 1.03's release candidate. If nobody finds any faults, I'll upload it tomorrow on CPAN. (libapreq needs to rely on 1.03 fixes to release its 1.2's version). Please try it out: http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz Tests OK over here: Solaris (Intel), perl 5.8.0, Apache 1.3.27, mod_perl 1.27. fxn -- __ 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: MS SQL Server
Matt Sergeant wrote: Anyone got any experience of doing MS SQL Server from mod_perl on Linux (via the FreeTDS drivers)? Not under mod_perl, but I think the experience is still relevant. Any gotchas I should be aware of? I have a very high performance requirements application (millions of hits/day) and I need to know the architecture can cope with it (the alternative being PostgreSQL). Sorry if I mention obvious things, but I know of: 1) lack of placeholders support with DBD::Sybase + Freetds layer. I used freetds 0.53, but 0.61 had the same problem for me. 2) I wasn't able to use sql transactions in the same way I normally do with postgresql/db2/informix/sybase/... This could be due to my fault, SQL server version (?), or other problems I couldn't track down. -- Cosimo
Re: mod_perl slower than expected? - Test Code!
Trevor Phillips [EMAIL PROTECTED] writes: [...] On my main dev box, ab gives an average of 8.8secs for the mod_perl run, and 7.2secs for the FastCGI run. The internal timer and printed output reflects these results too. How does the cgi/command-line version stack up? AFAICT your test isn't measuring any architectural differences between modperl and fastgci, just how well the server's embedded perl interpreter performs relative to perl itself. I wonder if compiling modperl as a DSO versus compiling it statically might explain the performance lag. -- Joe Schaefer
Re: MS SQL Server
On Wed, 18 Jun 2003, Cosimo Streppone wrote: Any gotchas I should be aware of? I have a very high performance requirements application (millions of hits/day) and I need to know the architecture can cope with it (the alternative being PostgreSQL). Sorry if I mention obvious things, but I know of: 1) lack of placeholders support with DBD::Sybase + Freetds layer. I used freetds 0.53, but 0.61 had the same problem for me. Ah, that explains why people are using unixODBC with the TDS driver instead. I assume that supports placeholders (?). Sounds like a bit of a showstopper to me! 2) I wasn't able to use sql transactions in the same way I normally do with postgresql/db2/informix/sybase/... This could be due to my fault, SQL server version (?), or other problems I couldn't track down. Any chance you can expand on that? I use transactions in the application heavily (it has been developed on PostgreSQL), and had feared this might be an area of contention. -- !-- Matt -- :-get a SMart net/:- Spam trap - do not mail: [EMAIL PROTECTED]
Re: mod_perl slower than expected? - Test Code!
Joe Schaefer wrote:
Trevor Phillips [EMAIL PROTECTED] writes:
[...]
On my main dev box, ab gives an average of 8.8secs for the mod_perl
run, and 7.2secs for the FastCGI run. The internal timer and printed
output reflects these results too.
How does the cgi/command-line version stack up? AFAICT your test isn't
measuring any architectural differences between modperl and fastgci,
just how well the server's embedded perl interpreter performs relative to
perl itself. I wonder if compiling modperl as a DSO versus compiling it
statically might explain the performance lag.
I doubt that this makes any difference. I think what makes the difference is
the fact that the mod_perl handler is setup via .htaccess. Have you tried
setting it in httpd.conf? Otherwise it's parsed on each request, no surprises
that it's slower.
Also add:
PerlModule Thrash
PerlModule Apache::Request
to your httpd.conf to pre-compile the modules.
Moreover, your code loads Apache::Request, but doesn't use it.
Unrelated to the case, but related to performance in general:
eval use Time::HiRes;;
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
is probably a bit faster as:
eval { require Time::HiRes };
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
and neater as:
use constant UseTimeHiRes = eval { require Time::HiRes };
__
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: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: Thus without re-compiling my whole Perl 5.8.0 build I need to come up with a solution. I really don't see why you don't recompile your Perl. It's not a big deal and it's going to be a lot safer that way. Sorry for my ignorance but it does look like it will work (non-LFS Apache) provided that you don't try to access files larger then 2GB. I can't tell you how much what you're proposing to do worries me. I wouldn't dream of doing it on one of my servers, not even on a development machine. The size of the files you access isn't the issue. It's the size of the variables in the C data structures. If different parts of the same code disagree about that, and they pass each other pointers to different shaped structures, you are going to have serious problems. As Stas said, the *best* you can hope for is an immediate crash of some sort. It's possibile however that the problems might not surface immediately and that the symptoms might not be obvious. You could have all kinds of data corruption before you know what's hit you. 73, Ged.
Re: mod_perl slower than expected? - Test Code!
Stas Bekman wrote:
Joe Schaefer wrote:
I doubt that this makes any difference. I think what makes the
difference is
the fact that the mod_perl handler is setup via .htaccess. Have you
tried setting it in httpd.conf? Otherwise it's parsed on each request,
no surprises that it's slower.
Eh? How can that make a difference? Yes, I know that, between .htaccess
vs httpd.conf vs FastCGI vs CGI there will be some small performance hit
when accessing the URL. But that speed difference is irrelevant given
the run time of the content generator. I'm not talking about a
lightning-fast routine on a heavily hit server; I'm talking about a
complex request whose time can be measured in whole seconds. In that
scenario, .htaccess vs httpd.conf is irrelevant.
(And in my dev environment, both the FastCGI and mod_perl were being
configured from .htaccess)
And on the topic of DSO vs Static, yes, I tested that today. The static
mod_perl was marginally faster than the DSO mod_perl - but still nowhere
near as fast as the FastCGI, CGI and command line versions.
Interestingly, I tried Thrash on the aforementioned anomaly: My Sun Box
running Debian. I was wrong in saying the performance was the same for
both versions - turns out the mod_perl version on THAT platform is
slightly FASTER (but nowhere near the performance gap shown on the Intel
platforms).
Moreover, your code loads Apache::Request, but doesn't use it.
Oops. Kick-back from the original module I was cloning.
Again, though, that would only affect start-up time, which in this test,
is marginal. Also, it would not affect the time shown by the internal
time difference displayed.
Unrelated to the case, but related to performance in general:
eval use Time::HiRes;;
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
is probably a bit faster as:
eval { require Time::HiRes };
if (!$@)
{
$Thrash::UseTimeHiRes = 1;
}
and neater as:
use constant UseTimeHiRes = eval { require Time::HiRes };
Thanks for the syntax tips. I'll change my other code to use them. ^_^
--
. Trevor Phillips - http://jurai.murdoch.edu.au/ .
: Web Technical Administrator - [EMAIL PROTECTED] :
| IT Services- Murdoch University |
| On nights such as this, evil deeds are done. And good deeds, of /
| course. But mostly evil, on the whole. /
\ -- (Terry Pratchett, Wyrd Sisters) /
Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev
Hi Stas, On Wed, 18 Jun 2003, Stas Bekman wrote: Please try it out: http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz Neat! 73, Ged. Script started on Wed Jun 18 13:29:03 2003 hurricane:~/src/Apache-Test-1.03-dev$ t/TEST -times=10 -order=random *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -times=10 -order=random /usr/local/apache/bin/httpd -X -d /home/ged_demountable/src/Apache-Test-1.03-dev/t -f /home/ged_demountable/src/Apache-Test-1.03-dev/t/conf/httpd.conf -DAPACHE1 using Apache/1.3.27 waiting for server to start: . waiting for server to start: ok (waited 0 secs) server localhost:8529 started *** Using random number seed: 894127215 (autogenerated) [snip] All tests successful. Files=20, Tests=120, 10 wallclock secs ( 7.25 cusr + 1.44 csys = 8.69 CPU) *** server localhost:8529 shutdown hurricane:~/src/Apache-Test-1.03-dev$ Script done on Wed Jun 18 13:29:26 2003
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Ok -
This comes from the Makefile.PL:
sub uselargefiles_check {
return unless $] = 5.006 and $Config{uselargefiles}
and $PERL_USELARGEFILES and $USE_APXS;
local $Apache::src::APXS = $WITH_APXS;
my $cflags = Apache::src-new-apxs('-q' = 'CFLAGS') || '';
return if $cflags =~ /LARGEFILE/;
$PERL_USELARGEFILES=0; #just do it since
return; #nobody seems to listen to the warning below
phat_warn(EOF);
Your Perl is uselargefiles enabled, but Apache is not, suggestions:
*) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0
*) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
*) Rebuild Perl with Configure -Uuselargefiles
*) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1)
EOF
}
As you can see it suggests rebuilding mod_perl with $PERL_USELARGEFILES=0 (which we
do) so according to him it will work?
If not then I'll mail Doug and tell him to add a conditional statement :)
Jaco Greyling
-Original Message-
From: Ged Haywood [mailto:[EMAIL PROTECTED]
Sent: 18 June 2003 13:06
To: Greyling, Jaco
Cc: mod_perl Mailing List
Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi there,
On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote:
Thus without re-compiling my whole Perl 5.8.0 build I need to come
up with a solution.
I really don't see why you don't recompile your Perl. It's not a big
deal and it's going to be a lot safer that way.
Sorry for my ignorance but it does look like it will work (non-LFS
Apache) provided that you don't try to access files larger then 2GB.
I can't tell you how much what you're proposing to do worries me.
I wouldn't dream of doing it on one of my servers, not even on a
development machine.
The size of the files you access isn't the issue. It's the size of
the variables in the C data structures. If different parts of the
same code disagree about that, and they pass each other pointers to
different shaped structures, you are going to have serious problems.
As Stas said, the *best* you can hope for is an immediate crash of
some sort. It's possibile however that the problems might not surface
immediately and that the symptoms might not be obvious. You could
have all kinds of data corruption before you know what's hit you.
73,
Ged.
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
mod_perl 2 and file upload how-to
Hello, I need help in file uploading with mod_perl 2. Apache::Request is not compatible with mod_perl 2, and I want to know how can I upload file widthout using CGI.pm Please send me an example if possible. Thanks, Alejandro.
Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev
On Today at 7:13pm, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB Please try it out: SB http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz SB 1) Gentoo Linux 1.4 (2.4.20-ck6), perl 5.8.0, apache 2.0.46, mod_perl 1.9909 2) Redhat Linux 8.0 (2.4.18), perl 5.8.0, apache 2.0.44, mod_perl 1.9908 All tests successful. -- Haroon Rafique [EMAIL PROTECTED]
Re: MS SQL Server
Matt Sergeant wrote: Anyone got any experience of doing MS SQL Server from mod_perl on Linux (via the FreeTDS drivers)? Only a little, but I know that Simon Matthews ([EMAIL PROTECTED]) has done a lot. ISTR he switched from Postgres to SQL Server (from mod_perl front end, via FreeTDS) and hasn't looked back. He has nothing but good things to say about SQL Server, and from the limited exposure that I'm getting to it now, I'd be inclined to agree. A
RE: MS SQL Server
Title: RE: MS SQL Server omg... linux people using MS SQL servers? shame on you... =) -Original Message- From: Andy Wardley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 18, 2003 10:15 AM To: Matt Sergeant Cc: [EMAIL PROTECTED] Subject: Re: MS SQL Server Matt Sergeant wrote: Anyone got any experience of doing MS SQL Server from mod_perl on Linux (via the FreeTDS drivers)? Only a little, but I know that Simon Matthews ([EMAIL PROTECTED]) has done a lot. ISTR he switched from Postgres to SQL Server (from mod_perl front end, via FreeTDS) and hasn't looked back. He has nothing but good things to say about SQL Server, and from the limited exposure that I'm getting to it now, I'd be inclined to agree. A
RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
Hi, mod_perl does not look different between 2 builds (lfs and non-lfs apache) - our assumption that mod_perl shares memory with Apache might just be wrong or there is a way for mod_perl to make system calls with lfs against perl and non-lfs against apache. Hence we need a developer feedback :) Jaco Greyling -Original Message- From: Ged Haywood [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 14:53 To: Greyling, Jaco Cc: [EMAIL PROTECTED] Subject: RE: non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl) Hi Jaco, On Wed, 18 Jun 2003 [EMAIL PROTECTED] wrote: As you can see it suggests rebuilding mod_perl with $PERL_USELARGEFILES=0 (which we do) so according to him it will work? Well it's in the list of suggestions, I don't think that's quite the same thing... I guess the bit about nobody listening to the warning is at least as relevant. :) If none of your system is configured to use large file offsets that's fine. It's when you choose to link together different parts, some of which do and some don't that I'd worry. Structure (mis)alignment can cause all kinds of subtle problems, some very obvious and some not, and the more you play with additional modules, interfaces to the Perl guts etc., the more likely you are to come across them before anyone else does. Traditionally the advice is even that you should use the same compiler to build Perl and mod_perl, for exactly this reason. I would always want to make sure that my Perl and mod_perl were both compiled the same way. 73, Ged. Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: [OT] Re[2]: temporal directory used by apache/mod-perl?
That will do it, thanks!
Hello Hector Pizarro,
Wednesday, June 18, 2003, 12:21:54 AM, you wrote:
HP Apache::Request has a bug, it doesn't throw an error code when the
file is HP partially uploaded. That's why I'm using Apache read()
instead. Any idea HP how tosetup the temporal directory for mod-perl
without Apache::Request?
What's wrong with TEMP_DIR ?
my $apr = Apache::Request-new($r, TEMP_DIR = /home/httpd/tmp);
HP my
$upload = $apr-upload('file');
$upload-link(/home/user/myfile) || warn link failed: $!;
see: perldoc Apache::Request
--
WBR, Mike P. Mikhailov
mailto: [EMAIL PROTECTED]
ICQ:280990142
My mother always used to tell me, The early bird gets the worm.
HP --
HP Hector Pizarro
HP Amautatech
Sorry, I'm mislead somewhere :(. So, you reading post data by itself,
right? And *you* choose where temporary folder will be. Choose it on
the same FS as target folder and use rename :) Or use File::Copy 'move'
function which will copy file content if src and trg on different FS.
Or `mv $src $trg`. TIMTOWTDI.
But this is a far away from mod_perl topic.
--
WBR, Mike P. Mikhailov
mailto: [EMAIL PROTECTED]
ICQ:280990142
Always listen to experts. They'll tell you what can't be done, and why.
Then do it.
--
Hector Pizarro
Amautatech
RE: MS SQL Server [x-adr]
Title: RE: MS SQL Server [x-adr] Matt Sergeant wrote: On Wed, 18 Jun 2003, Cosimo Streppone wrote: 1) lack of placeholders support with DBD::Sybase + Freetds layer. I used freetds 0.53, but 0.61 had the same problem for me. Ah, that explains why people are using unixODBC with the TDS driver instead. I assume that supports placeholders (?). Yep. 0.61 has support for placeholders and odbc call sytax. There are a couple syntax issues which are resolved in CVS. But if you check the mailing list archives you should be able to get things working. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
RE: MS SQL Server
On Wed, 18 Jun 2003, FARRINGTON, RYAN wrote: omg... linux people using MS SQL servers? shame on you... =) I hold in one hand the option of taking a pager home with me. In the other hand is using MS SQL Server and giving support over to our 24/7 DBAs. Which would you choose? -- !-- Matt -- :-get a SMart net/:- Spam trap - do not mail: [EMAIL PROTECTED]
non-LFS Apache 1.3.27 w/ LFS Perl 5.8.0 (using mod_perl)
All Sorry if this question goes out to the wrong discussion group, but I've been told if anyone could answer this then it'll be someone on this forum :) Ok, here goes... We use Perl 5.6.x and Perl 5.8.0 with LFS. We also use mod_perl 1.27 with LFS and Apache 1.3.27 (with LFS). To make a long story short...we are running into issues with vendors like IBM and Oracle where they don't want to re-compile their code (i.e. mod_ossos) with LFS. So, we need to run a non-LFS build of Apache 1.3.27. The only way (to our knowledge) we can do this is by re-compiling Perl 5.8.0 without LFS, which means that we have to support two versions of Perl / CPAN / etc...not likely in our current situation. Someone just told me that we can use Apache (Non-LFS) with Perl (LFS) using mod_perl (PERL_USELARGEFILES=0, set in Makefile.PL)? This I know Doug MacEachern did not support in earlier versions of mod_perl. BTW. We just-compiled it and it seems to work, HOWEVER I'm concerned about Segmentation Faults (this is common when using LFS modules with a non-LFS Apache build). For some reason we don't get these errors when using mod_perl /LFS with non-LFS Apache. How is this possible? Here is our mod_perl build script: ... # run the following from the mod_perl source directory $perl_base/bin/perl Makefile.PL \ INSTALLDIRS=perl PREFIX=$prefix \ USE_APXS=1 WITH_APXS=$apache_base/bin/apxs \ EVERYTHING=1 ... Regards, Jaco Greyling _ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
Re: [RELEASE CANDIDATE] Apache::Test 1.03-dev
Stas Bekman wrote: I've uploaded 1.03's release candidate. If nobody finds any faults, I'll upload it tomorrow on CPAN. (libapreq needs to rely on 1.03 fixes to release its 1.2's version). Please try it out: http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz Thank you all very much for testing this release candidate. Apache::Test 1.03 is propogating to CPAN mirrors at this very moment. __ 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: mod_perl 2 and file upload how-to
Alejandro Galue wrote: Hello, I need help in file uploading with mod_perl 2. Apache::Request is not compatible with mod_perl 2, and I want to know how can I upload file widthout using CGI.pm Please send me an example if possible. Simply copy the relevant code from CGI.pm. Alternatively if you have some time help Joe to finish the porting of Apache::Request, which is getting there. Join the apreq-dev list: http://httpd.apache.org/apreq/, and offer your help. __ 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
Few Important Questions
Hi Everybody, mod_perl is a great software. Thanks for everybody who spent time on it and make it available. When you send a reply to this, can you also describe how we can help, as an individiual, to support mod_perl and people behind it financially. Now here are some of my questions. I am working on a project that will enable people, regular people, to use their computers remotely using apache and a web browser. I have various questions though. I started this with CGI, then migrated to mod_perl. However I want to bring a very general solution to the problem, so that developers can develop in any language they want. Number one issue is that, I selected perl because that's how I get started. Now I am using mod_perl for speed and various other issues. But what is the fastest solution out there. This application is supposed to run on a standalone PC, so it doesn't have to scale well, but it has to be as fast as possible. Is mod_perl the fastest solution available, other than the C of course. How does it compare to java. Second, what are my options if I want to combine mod_perl with other solutions, such as php, java and so on. One problem seem to be the session management. The second problem is that I want to be able to mix perl files with php files. For example the directory which should be handled by mod_perl should also have php files which should also run fine. Another question is that, why hosting guys avoid using mod_perl. Is it just because mod_perl is memory hungry? Finally how can I dynamically ban an ip address in mod_perl. For example, normally you can specify certain ip addresses with Allow, Deny directives. How can I do that dynamically using mod_perl. You can answer any of the above. Thanks __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
