RE:Vulnerability awareness

[Stas Bekman]

On Tue, 6 Jun 2000, ___cliff rayman___ wrote:

> here is something posted to p5p today.
> looks like a good place to start Stas's challenge.

> Benjamin Elijah Griffin wrote:
> 
> > In alt.hackers a while ago I saw this .sig:
> >
> > #!/usr/bin/perl
> > $j=\$j;{$_=unpack(P25,pack(L,$j));/Just Another Perl Wannabe/?print:$j++&&redo}
> >
> > It occured to me after the xlockmore stuff in bugtraq recently that
> > having a way to get a pointer in perl and roam around memory looking
> > for stuff might pose a security problem for embeded perl, eg:
> > a mod_perl script that roams around apache reading passwords stored
> > still in memory.
> >
> > Is this something to worry about?
> >
> > Benjamin

It talks about user being able to run arbitrary Perl code thru your CGI,
look at this reply:

From: Jan Dubois <[EMAIL PROTECTED]> 
I don't think so.  You should never let people execute arbitrary code on
your web server anyways.  If you do, then the potential intruder can do
much more nasty things than just snooping around in memory.
-Jan




_
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:Vulnerability awareness

[Gunther Birznieks]

At 11:45 AM 6/7/00 +0300, Stas Bekman wrote:
>On Tue, 6 Jun 2000, ___cliff rayman___ wrote:
>
> > here is something posted to p5p today.
> > looks like a good place to start Stas's challenge.
>
> > Benjamin Elijah Griffin wrote:
> >
> > > In alt.hackers a while ago I saw this .sig:
> > >
> > > #!/usr/bin/perl
> > > $j=\$j;{$_=unpack(P25,pack(L,$j));/Just Another Perl 
> Wannabe/?print:$j++&&redo}
> > >
> > > It occured to me after the xlockmore stuff in bugtraq recently that
> > > having a way to get a pointer in perl and roam around memory looking
> > > for stuff might pose a security problem for embeded perl, eg:
> > > a mod_perl script that roams around apache reading passwords stored
> > > still in memory.
> > >
> > > Is this something to worry about?
> > >
> > > Benjamin
>
>It talks about user being able to run arbitrary Perl code thru your CGI,
>look at this reply:
>
>From: Jan Dubois <[EMAIL PROTECTED]>
>I don't think so.  You should never let people execute arbitrary code on
>your web server anyways.  If you do, then the potential intruder can do
>much more nasty things than just snooping around in memory.
>-Jan
I think Jan is right to some degree. But he's also not necessarily thinking 
outside the box which is exactly what a hacker will do.

That's what I hate about web security, it's easy to poo-poo something as 
being a security hole, but that's precisely how security holes are 
uncovered. By a hacker thinking outside the box of what the original 
developer thought could be possible holes.

Here's one scenario I imagine that could make a combination of the code 
snippet above plus a mod_perl server being hacked into more dangerous than 
a standard CGI/Perl Apache Server:

A single mod_perl server can be up for hours collecting passwords and 
authentication credentials. It is conceivable that this information may be 
cached in the Perl memory by
modules and whatnot to make the script run faster by a programmer concerned 
about performance.

It is in this scenario that being able to execute arbirtrary code is quite 
dangerous. In one feel swoop, a hacker can snoop the entire history of what 
has happened on that mod_perl server engine.

Whereas, to get the same data without snooping memory, they would have to 
basically replace the script and the web server with hooks that records the 
passwords and other confidential information as they are entered. This 
could take hours and by that time, intrusion detection software may have 
caught wind of the hacker and raised alerts.

In addition, the comment that snooping in memory is less nasty than other 
things is not thinking outside the developer box. For a normal website like 
ours which just serves content but does not contain proprietary 
information, it would simply suck to have the website deleted. Snooping 
memory is a "well, whatever" sort of problem. Probably ActiveState is similar.

But a bank may think differently. I am sure they would rather their website 
was deleted than their precious customer data (and hence their reputation 
for maintaining confidentiality) were to be impaired.

Anyway, this is not meant to be down on what Jan said in his quote as I 
highly respect his work (and liked his Win32 info that he talked about at 
PerlCon last year) but it shows precisely how an extremely clever developer 
like Jan isn't necessarily thinking about the same things that a hacker 
might think about.

One type thinks about how to create things, the other thinks about how to 
destroy things.  It's a different way of thinking altogether.

A person may think it is easier to destroy than create, but I assure them 
that destroying things that have been lovingly protected by the developer 
is a highly creative task in the computer world and not to be taken for 
granted.

Later,
Gunther

__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/

Re: Vulnerability awareness

[Eric Strovink]

Gunther Birznieks wrote:



> >From: Jan Dubois <[EMAIL PROTECTED]>
> >I don't think so.  You should never let people execute arbitrary code on
> >your web server anyways.  If you do, then the potential intruder can do
> >much more nasty things than just snooping around in memory.
> >-Jan
> I think Jan is right to some degree. But he's also not necessarily thinking
> outside the box which is exactly what a hacker will do.



This reminds me of a discussion that has been conducted here before.  One could as
well ask, "Isn't embperl [or any other embedded code implementation] a security
risk?"  One camp says of course not, you should protect yourself against tainted
user data, etc., plus whatever other ways exist to trick the server into executing
a foreign Perl fragment, and it's your fault if you don't, so there's no risk.
Another camp says yes, if your server is *able* to execute embedded code of some
kind, then by enabling this capability you've added to the risk by definition --
and by the way, you can't claim to have thought of *all* the ways that someone
might trick you into running a code frag, because you're probably not thinking
about it as hard as they are.

Big pages and gzip

[Mark Hewis]

it would seem to be quite straight forward to implement a handler to gzip
all output html files depending on the allowed mime-types and/or user_agent.
This would reduce many pages by up to a factor of 10 in size. 

1) Is anyone already doing?
2) If not why not?
3) what borwsers would accept html files in a gzipped format

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.

Re: Big pages and gzip

[Stas Bekman]

On Wed, 7 Jun 2000, Mark Hewis wrote:

> it would seem to be quite straight forward to implement a handler to gzip
> all output html files depending on the allowed mime-types and/or user_agent.
> This would reduce many pages by up to a factor of 10 in size. 
> 
> 1) Is anyone already doing?
> 2) If not why not?
> 3) what borwsers would accept html files in a gzipped format

it's there for a long time:
Apache::Gzip
Apache::GzipChain

It's based on the Accept-Encoding =~ /gzip/ match, and some use User-Agent
but the first one should be enough. (The second is used to discard agents
that known not to handle GZIP while they claim that they can)

For more info see the guide and modules' respective manpages.

> 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.
> 



_
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: Vulnerability awareness

[Gunther Birznieks]

At 07:56 AM 6/7/00 -0400, Eric Strovink wrote:
>Gunther Birznieks wrote:
>
>
>
> > >From: Jan Dubois <[EMAIL PROTECTED]>
> > >I don't think so.  You should never let people execute arbitrary code on
> > >your web server anyways.  If you do, then the potential intruder can do
> > >much more nasty things than just snooping around in memory.
> > >-Jan
> > I think Jan is right to some degree. But he's also not necessarily thinking
> > outside the box which is exactly what a hacker will do.
>
>
>
>This reminds me of a discussion that has been conducted here before.  One 
>could as
>well ask, "Isn't embperl [or any other embedded code implementation] a 
>security
>risk?"  One camp says of course not, you should protect yourself against 
>tainted
>user data, etc., plus whatever other ways exist to trick the server into 
>executing
>a foreign Perl fragment, and it's your fault if you don't, so there's no risk.
>Another camp says yes, if your server is *able* to execute embedded code 
>of some
>kind, then by enabling this capability you've added to the risk by 
>definition --
>and by the way, you can't claim to have thought of *all* the ways that someone
>might trick you into running a code frag, because you're probably not thinking
>about it as hard as they are.

Well, yes and no. At the end of the day, as the server admin you are 
choosing which directories and filetypes are enabled for embperl so it is 
protected in the same way as a cgi script from being run on the server.  If 
embperl then runs in the same model as mod_perl, then it would have the 
same vulnerabilities as I outlined in the part of the mail that was snipped.

The caching of data in a mod_perl server is the particular security 
vulnerability that there is a potential of exploiting. But not too many 
people would think that way, and the mod_perl program would have to be 
caching quite a bit of data on the server which usually is not recommended 
for individual apache program size anyway even if it might improve 
performance when there is enough RAM.

Later,
Gunther



__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/

PerlRun benefit from shared modules ?

[David Brown]

OK, I'm new to all this, and it's by a sheer miracle that I've compiled Perl
5.6, Apache & mod_perl on my BSDI 4.1 box. I may be using completely the
wrong terminology, so please bear with me !

I'm running lots of scripts under Apache::PerlRun, migrating the scripts one
at a time to run in Apache::Registry

My question is: If I add the preload CGI/DBI modules into Apache in my
startup.pl (with use CGI; CGI->compile(':all'); ) will the PerlRun scripts
benefit from that, or is it only Apache::Registry scripts that benefit.

Reason I ask, is that currently all of my scripts under Apache::Registry
have no need for CGI.pm & DBI modules as I've got away with using
Apache::Request to handle requests and they don't access any databases.  I
only need CGI / DBI etc. for the PerlRun scripts, and don't want to bloat my
httpd processes with preloading the modules if they're not going  be used
for PerlRun scripts.

Does any of that make sense ?

I've also got big problems with memory leaking like a sieve when using
PerlRun.. but I'll pose that one later ! ;-)

BTW: Thanks to all you guys, esp. Doug & Stas for submitting so many
responses in the past that I've been able to search through to get where I
am now !

Re: PerlRun benefit from shared modules ?

[Gunther Birznieks]

Yes you get the benefit of shared modules. PerlRun only differs from 
registry in the sense that it clears out the namespace of the main script.

As for leaking memory like a sieve? That is not unexpected with PerlRun 
scripts because they are typically not coded cleanly. Hell, even our 6 year 
old Extropia Perl 4 scripts will run under PerlRun. A surprise. But it 
doesn't mean it is efficient.

In fact, I would suggest that you create two backend mod_perl servers, one 
for  PerlRun and one for your cleaner mod_perl scripts. The PerlRun server 
should be set up to destroy itself after much fewer hits... so you could 
still get the benefits of the shared module loading because of the 
preforked module loading, but the individual apache engines can clean 
themselves out sooner.

At 02:54 PM 6/7/00 +0100, David Brown wrote:
>OK, I'm new to all this, and it's by a sheer miracle that I've compiled Perl
>5.6, Apache & mod_perl on my BSDI 4.1 box. I may be using completely the
>wrong terminology, so please bear with me !
>
>I'm running lots of scripts under Apache::PerlRun, migrating the scripts one
>at a time to run in Apache::Registry
>
>My question is: If I add the preload CGI/DBI modules into Apache in my
>startup.pl (with use CGI; CGI->compile(':all'); ) will the PerlRun scripts
>benefit from that, or is it only Apache::Registry scripts that benefit.
>
>Reason I ask, is that currently all of my scripts under Apache::Registry
>have no need for CGI.pm & DBI modules as I've got away with using
>Apache::Request to handle requests and they don't access any databases.  I
>only need CGI / DBI etc. for the PerlRun scripts, and don't want to bloat my
>httpd processes with preloading the modules if they're not going  be used
>for PerlRun scripts.
>
>Does any of that make sense ?
>
>I've also got big problems with memory leaking like a sieve when using
>PerlRun.. but I'll pose that one later ! ;-)
>
>BTW: Thanks to all you guys, esp. Doug & Stas for submitting so many
>responses in the past that I've been able to search through to get where I
>am now !
>

[performance/benchmark] Reducing the Number of stat() Calls Made by Apache

[Stas Bekman]

Here is another freshly squeezed^H^H^H^H^H^H^H^Hmade benchmark with
comments :)


=head2 Reducing the Number of stat() Calls Made by Apache

If you watch the system calls that your mod_perl server makes (using
I or I depending on your OS), while processing a
request, you will notice that a few stat() calls are made, which are
quite expensive. For example when I fetch http://localhost/perl-status
and I have my C set to I I see:

  [snip]
  stat("/home/httpd/docs/perl-status", 0xb8cc) = -1 
  ENOENT (No such file or directory)
  stat("/home/httpd/docs", {st_mode=S_IFDIR|0755, 
 st_size=1024, ...}) = 0
  [snip]

If you have some dynamic content and your virtual relative URI is
something like I (i.e., there is no such
directory on the web server, the path components are only used for
requesting a specific report), this will generate five(!) stat()
calls, before the C is found. You will see something
like this:

  stat("/home/httpd/docs/news/perl/mod_perl/summary", 0xb744) = -1 
  ENOENT (No such file or directory)
  stat("/home/httpd/docs/news/perl/mod_perl", 0xb744) = -1
  ENOENT (No such file or directory)
  stat("/home/httpd/docs/news/perl",  0xb744) = -1
  ENOENT (No such file or directory)
  stat("/home/httpd/docs/news",   0xb744) = -1
  ENOENT (No such file or directory)
  stat("/home/httpd/docs", 
  {st_mode=S_IFDIR|0755, st_size=1024, ...})  =  0

You can blame the default installed C for this
inefficiency.  Of course you could supply your own, which will be
smart enough not to look for this virtual path and immediately return
C. But in cases where you have a virtual host that serves only
dynamically generated documents, you can override the default
C with this one:

  
...
PerlTransHandler  Apache::OK
...
  

As you see it affects only this specific virtual host.

This has the effect of short circuiting the normal C
processing of trying to find a file system component that matches the
given URI -- no more 'stat's!

Watching your server under strace/truss can often reveal more
performance hits than trying to optimize the code itself!

For example unless configured correctly, Apache might look for the
I<.htaccess> file in many places, if you don't have one and add many
open() calls.

Let's start with this simple configuration, and will try to reduce the
number of irrelevant system calls.

  DocumentRoot "/home/httpd/docs"
  
SetHandler perl-script
PerlHandler Apache::Foo
  

The above configuration allows us to make a request to I
and the Perl handler() defined in C will be
executed. Notice that in the test setup there is no file to be
executed (like in C). There is no I<.htaccess> file
as well.

This is a typical generated trace.

  stat("/home/httpd/docs/foo/test", 0xb8fc) = -1 ENOENT 
(No such file or directory)
  stat("/home/httpd/docs/foo",  0xb8fc) = -1 ENOENT 
(No such file or directory)
  stat("/home/httpd/docs", 
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
  open("/.htaccess", O_RDONLY) = -1 ENOENT 
(No such file or directory)
  open("/home/.htaccess", O_RDONLY)= -1 ENOENT 
(No such file or directory)
  open("/home/httpd/.htaccess", O_RDONLY)  = -1 ENOENT 
(No such file or directory)
  open("/home/httpd/docs/.htaccess", O_RDONLY) = -1 ENOENT 
(No such file or directory)
  stat("/home/httpd/docs/test", 0xb774)= -1 ENOENT 
(No such file or directory)
  stat("/home/httpd/docs", 
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0

Now we modify the CDirectoryE> entry and add S,
which among other things disables I<.htaccess> files and will not try
to open them.

  
AllowOverride None
  

We see that the four open() calls for I<.htaccess> have gone.

  stat("/home/httpd/docs/foo/test", 0xb8fc) = -1 ENOENT 
(No such file or directory)
  stat("/home/httpd/docs/foo",  0xb8fc) = -1 ENOENT 
(No such file or directory)
  stat("/home/httpd/docs", 
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
  stat("/home/httpd/docs/test", 0xb774)= -1 ENOENT 
(No such file or directory)
  stat("/home/httpd/docs", 
{st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0

Let's try to shortcut the I location with:

  Alias /foo /

Which makes Apache to look for the file in the I directory and not
under I. Let's run it:

  stat("//test", 0xb8fc) = -1 ENOENT (No such file or directory)

Wow, we've got only one stat call left!

Let's remove the last C setting and use:

PerlTransHandler  Apache::OK

as explained above.  When we issue the request, we see no stat()
calls. But this is possible only if you serve only dynamically
generated documents, i.e. no CGI scripts.  Otherwise you will have to
write your own I t

Re: PerlRun benefit from shared modules ?

[David Brown]

Thanks for the response Gunther,

I'll look into running seperate servers.

I'm now preloading CGI & DBI and memory APPEARS to be gobbled a lot slower
now. Which is nice.

Does DBI automatically pull in DBD, or should I preload Apache:DBD also ?

Re: PerlRun benefit from shared modules ?

[Stas Bekman]

On Wed, 7 Jun 2000, David Brown wrote:

> Thanks for the response Gunther,
> 
> I'll look into running seperate servers.
> 
> I'm now preloading CGI & DBI and memory APPEARS to be gobbled a lot slower
> now. Which is nice.

I can see a rain of questions coming :)

David, please read the guide and other docs / mailing list archive before
going any further and asking questions that were answered already. thanks!

> Does DBI automatically pull in DBD, or should I preload Apache:DBD also ?

See my benchmarking post from a few days ago, named "Initializing DBI" --
it's all there. You cannot even ask for numbers because it's there too :)

Have a nice mod_perl learning curve!

_
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

Newbie Questions about Perl/Apache

[Rich Lemanski]

Hello all,

I just joined the list the other day and have some questions about
internal and external Perl interpretors for Apache.  Forgive my lack of
knowledge, but I am assuming that mod_perl is the Perl interpretor that
runs internally to Apache and starts when Apache starts.  The external
Perl interpretor option, Perl CGI, is run externally and must be spawned
by Apache anytime they are needed.  

Do I have the right idea?

Which would be better to go with from a performance standpoint?  I am
assuming mod_perl because the instance does not need to be respawned
everytime the interpretor is needed.  Thanks!

Rich

Re: Newbie Questions about Perl/Apache

[Matt Sergeant]

On Wed, 7 Jun 2000, Rich Lemanski wrote:

> Hello all,
> 
> I just joined the list the other day and have some questions about
> internal and external Perl interpretors for Apache.  Forgive my lack of
> knowledge, but I am assuming that mod_perl is the Perl interpretor that
> runs internally to Apache and starts when Apache starts.  The external
> Perl interpretor option, Perl CGI, is run externally and must be spawned
> by Apache anytime they are needed.  
> 
> Do I have the right idea?

Almost, but not quite. Perl launched as a CGI only has access to
environment variables and STDIN (in the case of POST requests) it has no
access to any of the server's API. CGI is a cross-web server platform
concept.

mod_perl on the other hand is a complete implementation of the Apache API
in Perl. This means that you get full access to every C API that Apache
defines, and all the internals of Apache, if you want them. There are a
lot of modules which build on this capability, one of these is
Apache::Registry, which emulates a CGI-like environment in mod_perl, and
provides huge performance boosts over normal CGI. But to get the full
benefit of mod_perl it's often better to get right down into the Apache
API and write server modules to do your work, just as is the case that if
you need to improve a C based CGI, you will probably end up re-writing it
as a server module.

> Which would be better to go with from a performance standpoint?  I am
> assuming mod_perl because the instance does not need to be respawned
> everytime the interpretor is needed.  Thanks!

Yes, mod_perl is faster than CGI. There are a few "gotcha's", but these
are well documented in the guide at http://perl.apache.org/guide/

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

[performance/benchmark] printing techniques

[Stas Bekman]

Following Tim's comments here is the new benchmark. (I'll address the
buffering issue in another post)

  use Benchmark;
  use Symbol;

  my $fh = gensym;
  open $fh, ">/dev/null" or die;
  
  sub multi_print{
print $fh "";
print $fh "";
print $fh "  ";
print $fh "";
print $fh "  Test page";
print $fh "";
print $fh "  ";
print $fh "  ";
print $fh " ";
print $fh "  Test page ";
print $fh "";
print $fh "foo";
print $fh "";
print $fh "  ";
print $fh "";
  }
  
  sub single_print{
print $fh qq{

  

  Test page

  
  
 
  Test page 

foo

  

};
  }
  
  sub here_print{
print $fh <<__EOT__;


  

  Test page

  
  
 
  Test page 

foo

  

__EOT__
  }
  
  sub list_print{
print $fh "",
  "",
  "  ",
  "",
  "  Test page",
  "",
  "  ",
  "  ",
  " ",
  "  Test page ",
  "",
  "foo",
  "",
  "  ",
  "";
  }
  
  timethese
(500_000, {
  list_print   => \&list_print,
  multi_print  => \&multi_print,
  single_print => \&single_print,
  here_print   => \&here_print,
  });

And the results are:

  single_print:  1 wallclock secs ( 1.74 usr +  0.05 sys =  1.79 CPU)
  here_print:3 wallclock secs ( 1.79 usr +  0.07 sys =  1.86 CPU)
  list_print:7 wallclock secs ( 6.57 usr +  0.01 sys =  6.58 CPU)
  multi_print:  10 wallclock secs (10.72 usr +  0.03 sys = 10.75 CPU)

Numbers tell it all, I<'single_print'> is the fastest, 'here_print' is
almost of the same speed, I<'list_print'> is quite slow and
I<'multi_print'> is the slowest.

If we run the same benchmark using the unbuffered prints by changing
the beginning of the code to:

  use Symbol;
  my $fh = gensym;
  open $fh, ">/dev/null" or die;
  
 # make all the calls unbuffered
  my $oldfh = select($fh);
  $| = 1;
  select($oldfh);

And the results are:

  single_print:  4 wallclock secs ( 2.28 usr +  0.47 sys =  2.75 CPU)
  here_print:2 wallclock secs ( 2.45 usr +  0.45 sys =  2.90 CPU)
  list_print:7 wallclock secs ( 7.17 usr +  0.45 sys =  7.62 CPU)
  multi_print:  23 wallclock secs (17.52 usr +  5.72 sys = 23.24 CPU)

The results are worse by the factor of 1.5 to 2, with only
I<'list_print'> changed by very little.

So if you want a better performance, you know what technique to use.

_
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: [performance/benchmark] printing techniques

[Matt Sergeant]

On Wed, 7 Jun 2000, Stas Bekman wrote:

> Following Tim's comments here is the new benchmark. (I'll address the
> buffering issue in another post)
> 
>   use Benchmark;
>   use Symbol;
> 
>   my $fh = gensym;
>   open $fh, ">/dev/null" or die;
>   
>   sub multi_print{
> print $fh "";
> print $fh "";
> print $fh "  ";
> print $fh "";
> print $fh "  Test page";
> print $fh "";
> print $fh "  ";
> print $fh "  ";
> print $fh " ";
> print $fh "  Test page ";
> print $fh "";
> print $fh "foo";
> print $fh "";
> print $fh "  ";
> print $fh "";
>   }
>   
>   sub single_print{
> print $fh qq{
> 
>   
> 
>   Test page
> 
>   
>   
>  
>   Test page 
> 
> foo
> 
>   
> 
> };
>   }
>   
>   sub here_print{
> print $fh <<__EOT__;
> 
> 
>   
> 
>   Test page
> 
>   
>   
>  
>   Test page 
> 
> foo
> 
>   
> 
> __EOT__
>   }
>   
>   sub list_print{
> print $fh "",
>   "",
>   "  ",
>   "",
>   "  Test page",
>   "",
>   "  ",
>   "  ",
>   " ",
>   "  Test page ",
>   "",
>   "foo",
>   "",
>   "  ",
>   "";
>   }
>   
>   timethese
> (500_000, {
>   list_print   => \&list_print,
>   multi_print  => \&multi_print,
>   single_print => \&single_print,
>   here_print   => \&here_print,
>   });
> 
> And the results are:
> 
>   single_print:  1 wallclock secs ( 1.74 usr +  0.05 sys =  1.79 CPU)
>   here_print:3 wallclock secs ( 1.79 usr +  0.07 sys =  1.86 CPU)
>   list_print:7 wallclock secs ( 6.57 usr +  0.01 sys =  6.58 CPU)
>   multi_print:  10 wallclock secs (10.72 usr +  0.03 sys = 10.75 CPU)
> 
> Numbers tell it all, I<'single_print'> is the fastest, 'here_print' is
> almost of the same speed, I<'list_print'> is quite slow and
> I<'multi_print'> is the slowest.
> 
> If we run the same benchmark using the unbuffered prints by changing
> the beginning of the code to:
> 
>   use Symbol;
>   my $fh = gensym;
>   open $fh, ">/dev/null" or die;
>   
>  # make all the calls unbuffered
>   my $oldfh = select($fh);
>   $| = 1;
>   select($oldfh);
> 
> And the results are:
> 
>   single_print:  4 wallclock secs ( 2.28 usr +  0.47 sys =  2.75 CPU)
>   here_print:2 wallclock secs ( 2.45 usr +  0.45 sys =  2.90 CPU)
>   list_print:7 wallclock secs ( 7.17 usr +  0.45 sys =  7.62 CPU)
>   multi_print:  23 wallclock secs (17.52 usr +  5.72 sys = 23.24 CPU)
> 
> The results are worse by the factor of 1.5 to 2, with only
> I<'list_print'> changed by very little.
> 
> So if you want a better performance, you know what technique to use.

I think this last line is misleading. The reality is that you're doing
500,000 iterations here. Even for the worst case scenario of multi_print
with no buffering you're managing nearly 22,000 outputs a second. Now
granted, the output isn't exactly of normal size, but I think what it
comes down to is that the way you choose to print is going to make almost
zero difference in any real world mod_perl application. The overhead of
URL parsing, resource location, and actually running your handler is going
to take far more overhead by the looks of things.

Perhaps this section should be (re)moved into a posterity section, for it
seems fairly un-informative to me.

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: [performance/benchmark] printing techniques

[Stas Bekman]

[benchmark code snipped]

> >   single_print:  4 wallclock secs ( 2.28 usr +  0.47 sys =  2.75 CPU)
> >   here_print:2 wallclock secs ( 2.45 usr +  0.45 sys =  2.90 CPU)
> >   list_print:7 wallclock secs ( 7.17 usr +  0.45 sys =  7.62 CPU)
> >   multi_print:  23 wallclock secs (17.52 usr +  5.72 sys = 23.24 CPU)
> > 
> > The results are worse by the factor of 1.5 to 2, with only
> > I<'list_print'> changed by very little.
> > 
> > So if you want a better performance, you know what technique to use.
> 
> I think this last line is misleading. The reality is that you're doing
> 500,000 iterations here. Even for the worst case scenario of multi_print
> with no buffering you're managing nearly 22,000 outputs a second. Now
> granted, the output isn't exactly of normal size, but I think what it
> comes down to is that the way you choose to print is going to make almost
> zero difference in any real world mod_perl application. The overhead of
> URL parsing, resource location, and actually running your handler is going
> to take far more overhead by the looks of things.
> 
> Perhaps this section should be (re)moved into a posterity section, for it
> seems fairly un-informative to me.

Matt, Have you seen all these scripts with hundreds of print statements? 
This section comes to open the eyes of programmers who tend to use this
style. 

Obviously, that if write the normal code the real choice doesn't really
matter, unless you do lots of printings.

But, remember that each of the performance sections of the guide can be
deleted following your suggestion. Each section tackles a separate
feature/technique. The overall approach only matters. My goal is to show
programmers how to squeeze more out of their code, definitely I'm not
talking to people who run guestbooks code. 

Take for example Ask and Nick from ValueClick.  Let's ask them whether
these techniques matter or not. With 70-80M requests served daily each
saved millisecond counts.  Ask? Nick?

What do you think?

_
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: [performance/benchmark] printing techniques

[Eric Cholet]

> > So if you want a better performance, you know what technique to use.
>
> I think this last line is misleading. The reality is that you're doing
> 500,000 iterations here. Even for the worst case scenario of multi_print
> with no buffering you're managing nearly 22,000 outputs a second. Now
> granted, the output isn't exactly of normal size, but I think what it
> comes down to is that the way you choose to print is going to make almost
> zero difference in any real world mod_perl application. The overhead of
> URL parsing, resource location, and actually running your handler is going
> to take far more overhead by the looks of things.

I don't understand what you're getting at. Does this mean that something
shouldn't be optimized because there's something else in the process that
is taking more time? For example I have a database powered site, the slowest
part of request processing is fetching data from the database. Should I
disregard any optimization not dealing with the database fetches ? These
things add up, so don't you think that whatever can be optimized, should ?
Of course the slowest stuff should be optimized first, but that doesn't
mean that other optimisations are useless.

--
Eric

Re: [performance/benchmark] printing techniques

[Eric Strovink]

Eric Cholet wrote:

> Of course the slowest stuff should be optimized first...

Right.  Which means the Guide, if it is not already so doing, ought to
rank-order the optimizations in their order of importance, or better, their
relative importance.  This one, it appears, should be near the bottom of the
list.

Re: [performance/benchmark] printing techniques

[Matt Sergeant]

On Wed, 7 Jun 2000, Eric Cholet wrote:

> > > So if you want a better performance, you know what technique to use.
> >
> > I think this last line is misleading. The reality is that you're doing
> > 500,000 iterations here. Even for the worst case scenario of multi_print
> > with no buffering you're managing nearly 22,000 outputs a second. Now
> > granted, the output isn't exactly of normal size, but I think what it
> > comes down to is that the way you choose to print is going to make almost
> > zero difference in any real world mod_perl application. The overhead of
> > URL parsing, resource location, and actually running your handler is going
> > to take far more overhead by the looks of things.
> 
> I don't understand what you're getting at. Does this mean that something
> shouldn't be optimized because there's something else in the process that
> is taking more time? For example I have a database powered site, the slowest
> part of request processing is fetching data from the database. Should I
> disregard any optimization not dealing with the database fetches ? These
> things add up, so don't you think that whatever can be optimized, should ?
> Of course the slowest stuff should be optimized first, but that doesn't
> mean that other optimisations are useless.

Of course you can optimize forever, but some optimizations aren't going to
make a whole lot of difference. This is one of those optimizations,
judging by these benchmarks. Let Stas re-write this benchmark test as a
handler() and see what kind of difference it makes. I'm willing to
bet: barely any between averages.

Perhaps I was a little strong: Lets not deprecate this part of the guide,
just provide some realism in the conclusion.

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Re: [performance/benchmark] printing techniques

[Eric Cholet]

>From: "Eric Strovink" <[EMAIL PROTECTED]>
> > Of course the slowest stuff should be optimized first...
>
> Right.  Which means the Guide, if it is not already so doing, ought to
> rank-order the optimizations in their order of importance, or better,
their
> relative importance.  This one, it appears, should be near the bottom of
the
> list.

>From: "Matt Sergeant" <[EMAIL PROTECTED]>
>
> Of course you can optimize forever, but some optimizations aren't going to
> make a whole lot of difference. This is one of those optimizations,
> judging by these benchmarks. Let Stas re-write this benchmark test as a
> handler() and see what kind of difference it makes. I'm willing to
> bet: barely any between averages.
>
> Perhaps I was a little strong: Lets not deprecate this part of the guide,
> just provide some realism in the conclusion.

Agreed, all optimizations should be put under perspective, and the guide
(and book :-) should put forward those that count most.

This said, i hurry back to s/"constant strings"/'constant strings'/g;

--
Eric

[Advocacy] apachetoday.com

[Geoffrey Young]

apachetoday.com was launched sometime last week (I think), and today
features Stas and mod_perl on the front page :)

--Geoff

Re: [performance/benchmark] printing techniques

[Matt Sergeant]

On Wed, 7 Jun 2000, Eric Cholet wrote:

> This said, i hurry back to s/"constant strings"/'constant strings'/g;

Those two are equal.

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org

Apache::ASP

[Clement Law]

How do I make it so when it sees the extension .asp it does the asp thing?
instead of putting this

SetHandler perl-script
PerlHandler Apache::ASP
PerlSetVar Global /tmp
 

Re: [Advocacy] apachetoday.com

[___cliff rayman___]

yeah - but why the young guy's picture next to Stas's column.
i have him pictured as middle forties, slightly overweight, with grey
flecks in his black hair.

time for a picture change.

Geoffrey Young wrote:

> apachetoday.com was launched sometime last week (I think), and today
> features Stas and mod_perl on the front page :)
>
> --Geoff

--
___cliff [EMAIL PROTECTED]

Re: Apache::ASP

[Joshua Chamas]

Clement Law wrote:
> 
> How do I make it so when it sees the extension .asp it does the asp thing?
> instead of putting this
> 
> SetHandler perl-script
> PerlHandler Apache::ASP
> PerlSetVar Global /tmp
> 

The .htaccess file which activates the sample files
in the distribution's ./site/eg has entries like:


SetHandler perl-script
PerlHandler Apache::ASP
PerlSetVar NoState 1
PerlSetVar BufferingOn 1
PerlSetVar NoCache 1
PerlSetVar DebugBufferLength 250


-- Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks >> free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

RE: Apache::ASP

[Geoffrey Young]

well, I don't use Apache::ASP, but a quick glance of the README yielded the
apropriate instructions you are looking for...

:)

--Geoff

> -Original Message-
> From: Clement Law [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 07, 2000 1:54 PM
> To: [EMAIL PROTECTED]
> Subject: Apache::ASP
> 
> 
> How do I make it so when it sees the extension .asp it does 
> the asp thing?
> instead of putting this
> 
> SetHandler perl-script
> PerlHandler Apache::ASP
> PerlSetVar Global /tmp
>  
> 

Re: [Advocacy] apachetoday.com

[Stas Bekman]

> yeah - but why the young guy's picture next to Stas's column.
> i have him pictured as middle forties, slightly overweight, with grey
> flecks in his black hair.
> 
> time for a picture change.

Come'n Cliff, I'm only 26!!! The picture is about 3 years old. 

I don't have any grey flecks, as of overweighting blame the Guide/Book
I promise to correct this once I will finish it :)

> 
> Geoffrey Young wrote:
> 
> > apachetoday.com was launched sometime last week (I think), and today
> > features Stas and mod_perl on the front page :)
> >
> > --Geoff
> 
> --
> ___cliff [EMAIL PROTECTED]
> 
> 
> 



_
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: [performance/benchmark] printing techniques

[Barrie Slaymaker]

Eric Cholet wrote:
> 
> These
> things add up, so don't you think that whatever can be optimized, should ?

Wrong question, IMHO: it's what you optimize for that counts.  Several things
come to mind that are often more important than performance and often mean not
optimizing for performance (these are interrelated, of course):

  Stability / reliability
  Maintainability
  Development time
  Memory usage
  Clarity of design (API, data structures, etc)

There's a related rule of thumb that says don't optimize until you can test it
to see what the slow parts are.  Humans are pretty bad at predicting where the
bottlenecks are.

I think of it this way: if your process spends 80% of it's time in 20% of your
code, then you should only be thinking of performance optimizing that 20%, and
then only if you identify a problem there.  Of course, there are critical sections
that may need to operate lightening quick, but they're pretty few and far between
outside of real-time, embedded, or kernel hacking.

- Barrie

Re: Apache::ASP in virtual hosts

[Joshua Chamas]

"Mercer, Ty" wrote:
> 
> How would one go about adding the Apache::ASP function to the virtual hosts?
> I have the defunct ASP setting in my httpd.conf file and it works fine for
> the default site, but nothing for any of the virtuals.
> 
> Need more specifics?
> 
> Any info is better than what I have, thanx.

Just put your config defs in your VirtualHost tags.

-- Joshua

Re: Apache::ASP

[Joshua Chamas]

He Ding wrote:
> 
> [Sun Jun 4 15:15:12 2000] [error] Undefined subroutine
> &Apache::Symbol::undef called at
> /usr/lib/perl5/site_perl/5.005/Apache/ASP.pm line 1103.
> 
> [Sun Jun 4 15:15:12 2000] [error] [asp] [937] [debug] destroying - asp:
> Apache::ASP=HASH(0x8f6c8e4);
> 
> Eric He

You should not be getting this error.  Try intalling
Devel::Symdump.

-- Joshua
_
Joshua Chamas   Chamas Enterprises Inc.
NodeWorks >> free web link monitoring   Huntington Beach, CA  USA 
http://www.nodeworks.com1-714-625-4051

Re: [performance/benchmark] printing techniques

[Stas Bekman]

> > I don't understand what you're getting at. Does this mean that something
> > shouldn't be optimized because there's something else in the process that
> > is taking more time? For example I have a database powered site, the slowest
> > part of request processing is fetching data from the database. Should I
> > disregard any optimization not dealing with the database fetches ? These
> > things add up, so don't you think that whatever can be optimized, should ?
> > Of course the slowest stuff should be optimized first, but that doesn't
> > mean that other optimisations are useless.
> 
> Of course you can optimize forever, but some optimizations aren't going to
> make a whole lot of difference. This is one of those optimizations,
> judging by these benchmarks. Let Stas re-write this benchmark test as a
> handler() and see what kind of difference it makes. I'm willing to
> bet: barely any between averages.
> 
> Perhaps I was a little strong: Lets not deprecate this part of the guide,
> just provide some realism in the conclusion.

here we go, the benchmark holds for all but list_print!!!

query | avtime completed failedrps 
---
here_print|109  5000  0894 
single_print  |110  5000  0883 
list_print|111  5000  0877 
multi_print   |118  5000  0817 
---


Here is the module used in benchmarking:

package MyPrint;
use Apache::Constants qw(:common);
use Apache::URI ();

my %callbacks = (
  list_print   => \&list_print,
  multi_print  => \&multi_print,
  single_print => \&single_print,
  here_print   => \&here_print,
);

sub handler{
  my $r = shift;
  $r->send_http_header('text/plain');
  my $uri = Apache::URI->parse($r);
  my $query = $uri->query;

  return DECLINED unless  $callbacks{$query};
  &{$callbacks{$query}};
  return OK;
}

  sub multi_print{
print "\n";
print "\n";
print "  \n";
print "\n";
print "  Test page\n";
print "\n";
print "  \n";
print "  \n";
print " \n";
print "  Test page \n";
print "\n";
print "foo\n";
print "\n";
print "  \n";
print "\n";
  }
  
  sub single_print{
print qq{

  

  Test page

  
  
 
  Test page 

foo

  

};
  }
  
  sub here_print{
print <<__EOT__;


  

  Test page

  
  
 
  Test page 

foo

  

__EOT__
  }
  
  sub list_print{
print "\n",
  "\n",
  "  \n",
  "\n",
  "  Test page\n",
  "\n",
  "  \n",
  "  \n",
  " \n",
  "  Test page \n",
  "\n",
  "foo\n",
  "\n",
  "  \n",
  "\n";
  }

1;


_
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: [performance/benchmark] printing techniques

[Eric Cholet]

> > These
> > things add up, so don't you think that whatever can be optimized, should
?
>
> Wrong question, IMHO: it's what you optimize for that counts.  Several
things
> come to mind that are often more important than performance and often mean
not
> optimizing for performance (these are interrelated, of course):
>
>   Stability / reliability
>   Maintainability
>   Development time
>   Memory usage
>   Clarity of design (API, data structures, etc)

I never advocated optimizing at the expense of the above criteria, we were
discussing optimizations only. I certainly believe a program is a
compromise,
and have often chosen some of those criteria as being more important than
performance savings.

> There's a related rule of thumb that says don't optimize until you can
test it
> to see what the slow parts are.  Humans are pretty bad at predicting where
the
> bottlenecks are.

Neither did I say that optimizations should be carried out without first
determining whether they're worth it or not. Run benchmarks, optimize what
the benchmark shows to be slow. The point of the discussion was, is it worth
it to save a few microseconds here when milliseconds are being spent there.
My point was, yes it's worth it, every microsecond counts on a busy site.

> I think of it this way: if your process spends 80% of it's time in 20% of
your
> code, then you should only be thinking of performance optimizing that 20%,
and
> then only if you identify a problem there.  Of course, there are critical
sections
> that may need to operate lightening quick, but they're pretty few and far
between
> outside of real-time, embedded, or kernel hacking.

I don't see, provided I have the time and the need (ie my server's resources
are
strained) why I should not, once I have optimized that 20%, turn to the
other 80%
and see what I can do there too.

> - Barrie
>

--
Eric

Re: [performance/benchmark] printing techniques

[Stas Bekman]

On Wed, 7 Jun 2000, Jeff Norman wrote:

> 
> 
> Frequently, it's hard to build up an entire output segment without
> code in-between the different additions to the output.  I guess you could
> call this the "append, append, append... output" technique.
> 
> I think it would be an interesting addition to the benchmark:
> 
>sub gather_print{
>  my $buffer = '';
>  $buffer .= "";
>  $buffer .= ""; 
>  $buffer .= "  ";   
>  $buffer .= "";
>  $buffer .= "  Test page";
>  $buffer .= "";
>  $buffer .= "  ";
>  $buffer .= "  ";
>  $buffer .= " ";
>  $buffer .= "  Test page ";
>  $buffer .= "";
>  $buffer .= "foo";
>  $buffer .= ""; 
>  $buffer .= "  ";
>  $buffer .= "";
>  print $fh $buffer;
>}

Per your request:

The handler:

query | avtime completed failedrps 
---
single_print  |110  5000  0881 
here_print|111  5000  0881 
list_print|111  5000  0880 
concat_print  |111  5000  0873 
multi_print   |119  5000  0820 
---

The benchmark unbuffered:
single_print:  2 wallclock secs ( 2.44 usr +  0.31 sys =  2.75 CPU)
here_print:4 wallclock secs ( 2.34 usr +  0.54 sys =  2.88 CPU)
list_print:8 wallclock secs ( 7.06 usr +  0.43 sys =  7.49 CPU)
concat_print:  9 wallclock secs ( 8.95 usr +  0.66 sys =  9.61 CPU)
multi_print:  22 wallclock secs (16.94 usr +  5.74 sys = 22.68 CPU)

The benchmark unbuffered:
single_print:  1 wallclock secs ( 1.70 usr +  0.02 sys =  1.72 CPU)
here_print:1 wallclock secs ( 1.78 usr +  0.01 sys =  1.79 CPU)
list_print:7 wallclock secs ( 6.44 usr +  0.05 sys =  6.49 CPU)
concat_print:  9 wallclock secs ( 8.04 usr +  0.06 sys =  8.10 CPU)
multi_print:  10 wallclock secs (10.56 usr +  0.09 sys = 10.65 CPU)

The interesting thing is that list_print and concat_print are quite bad in
the benchmark but very good in the handler. The rest holds.


> 
> 
> 
> On Wed, 7 Jun 2000, Stas Bekman wrote:
> 
> > Following Tim's comments here is the new benchmark. (I'll address the
> > buffering issue in another post)
> > 
> 
> 



_
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: [performance/benchmark] printing techniques

[Jeff Norman]

Frequently, it's hard to build up an entire output segment without
code in-between the different additions to the output.  I guess you could
call this the "append, append, append... output" technique.

I think it would be an interesting addition to the benchmark:

   sub gather_print{
 my $buffer = '';
 $buffer .= "";
 $buffer .= ""; 
 $buffer .= "  ";   
 $buffer .= "";
 $buffer .= "  Test page";
 $buffer .= "";
 $buffer .= "  ";
 $buffer .= "  ";
 $buffer .= " ";
 $buffer .= "  Test page ";
 $buffer .= "";
 $buffer .= "foo";
 $buffer .= ""; 
 $buffer .= "  ";
 $buffer .= "";
 print $fh $buffer;
   }



On Wed, 7 Jun 2000, Stas Bekman wrote:

> Following Tim's comments here is the new benchmark. (I'll address the
> buffering issue in another post)
> 

Re: [performance/benchmark] printing techniques

[___cliff rayman___]

Stas Bekman wrote:

>
>
> Per your request:
>
> The handler:
>
> query | avtime completed failedrps
> ---
> single_print  |110  5000  0881
> here_print|111  5000  0881
> list_print|111  5000  0880
> concat_print  |111  5000  0873
> multi_print   |119  5000  0820
> ---

not very much difference once stuck in a handler.
obviously multi_print is both ugly and slow, but the rest should be used by the
discretion of the programmer based on the one that is easiest to maintain in
the code.

>
>
> The benchmark unbuffered:
> single_print:  2 wallclock secs ( 2.44 usr +  0.31 sys =  2.75 CPU)
> here_print:4 wallclock secs ( 2.34 usr +  0.54 sys =  2.88 CPU)
> list_print:8 wallclock secs ( 7.06 usr +  0.43 sys =  7.49 CPU)
> concat_print:  9 wallclock secs ( 8.95 usr +  0.66 sys =  9.61 CPU)
> multi_print:  22 wallclock secs (16.94 usr +  5.74 sys = 22.68 CPU)
>
> The benchmark unbuffered:

should this say "The benchmark buffered"??

>
> single_print:  1 wallclock secs ( 1.70 usr +  0.02 sys =  1.72 CPU)
> here_print:1 wallclock secs ( 1.78 usr +  0.01 sys =  1.79 CPU)
> list_print:7 wallclock secs ( 6.44 usr +  0.05 sys =  6.49 CPU)
> concat_print:  9 wallclock secs ( 8.04 usr +  0.06 sys =  8.10 CPU)
> multi_print:  10 wallclock secs (10.56 usr +  0.09 sys = 10.65 CPU)
>
> The interesting thing is that list_print and concat_print are quite bad in
> the benchmark but very good in the handler. The rest holds.

--
___cliff [EMAIL PROTECTED]

Re: [performance/benchmark] printing techniques

[Perrin Harkins]

On Wed, 7 Jun 2000, Stas Bekman wrote:
> And the results are:
> 
>   single_print:  1 wallclock secs ( 1.74 usr +  0.05 sys =  1.79 CPU)
>   here_print:3 wallclock secs ( 1.79 usr +  0.07 sys =  1.86 CPU)
>   list_print:7 wallclock secs ( 6.57 usr +  0.01 sys =  6.58 CPU)
>   multi_print:  10 wallclock secs (10.72 usr +  0.03 sys = 10.75 CPU)

Never mind the performance, that multi_print and list_print are just
U-G-L-Y!  Here doc rules.  Great for SQL too.
- Perrin

[performance posts] disclaimer

[Stas Bekman]

Folks, all the benchmarks and conclusions that I post are not coming as a
bite flame. Let me summarize it in two words: 

  I want people to be able to optimize their code when they want to. I
  just show how to do it and what are the good places to look at.

If you don't want/need to optimize, that's fine. I post these benchmarks
so you'd check for the possible fairness flaws/mistakes in my benchmarks.
So far Tim Bunce and a few other folks were of the biggest help, pointing
out the flaws. 

As for Barrie's comment about 20-80 rule of thumb (how they call it in the
university :) that's where the Profiling sections comes to help and all
the benchmarks of course...

Have a nice mod_perl :)

_
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: [performance/benchmark] printing techniques

[Stas Bekman]

On Wed, 7 Jun 2000, ___cliff rayman___ wrote:

> 
> 
> Stas Bekman wrote:
> 
> >
> >
> > Per your request:
> >
> > The handler:
> >
> > query | avtime completed failedrps
> > ---
> > single_print  |110  5000  0881
> > here_print|111  5000  0881
> > list_print|111  5000  0880
> > concat_print  |111  5000  0873
> > multi_print   |119  5000  0820
> > ---
> 
> not very much difference once stuck in a handler.
> obviously multi_print is both ugly and slow, but the rest should be used by the
> discretion of the programmer based on the one that is easiest to maintain in
> the code.

absolutely. I'd also love to know why is it different under the handler.
(talking about relative performance!)

> > The benchmark unbuffered:
> > single_print:  2 wallclock secs ( 2.44 usr +  0.31 sys =  2.75 CPU)
> > here_print:4 wallclock secs ( 2.34 usr +  0.54 sys =  2.88 CPU)
> > list_print:8 wallclock secs ( 7.06 usr +  0.43 sys =  7.49 CPU)
> > concat_print:  9 wallclock secs ( 8.95 usr +  0.66 sys =  9.61 CPU)
> > multi_print:  22 wallclock secs (16.94 usr +  5.74 sys = 22.68 CPU)
> >
> > The benchmark unbuffered:
> 
> should this say "The benchmark buffered"??

oops, buffered of course (copy-n-paste typo)

> > single_print:  1 wallclock secs ( 1.70 usr +  0.02 sys =  1.72 CPU)
> > here_print:1 wallclock secs ( 1.78 usr +  0.01 sys =  1.79 CPU)
> > list_print:7 wallclock secs ( 6.44 usr +  0.05 sys =  6.49 CPU)
> > concat_print:  9 wallclock secs ( 8.04 usr +  0.06 sys =  8.10 CPU)
> > multi_print:  10 wallclock secs (10.56 usr +  0.09 sys = 10.65 CPU)
> >
> > The interesting thing is that list_print and concat_print are quite bad in
> > the benchmark but very good in the handler. The rest holds.
> 
> --
> ___cliff [EMAIL PROTECTED]
> 
> 
> 



_
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

ApacheCon 2000 Europe: Call for Participation (fwd)

[Stas Bekman]

FYI

-- Forwarded message --
Date: Wed, 07 Jun 2000 15:24:42 -0400
From: Rodent of Unusual Size <[EMAIL PROTECTED]>
To: ApacheCon Announcements <[EMAIL PROTECTED]>,
Apache Announcements <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Apache Developers <[EMAIL PROTECTED]>
Subject: ApacheCon 2000 Europe: Call for Participation
Newsgroups: comp.infosystems.www.servers.unix,comp.infosystems.www.servers.ms-windows

Just a quick reminder: the deadline for submitting session proposals
for the ApacheCon 2000 Europe conference (23-25 October, London,
England) is 16 JUNE 2000.  That's less than two weeks away!

To submit a proposal, go to

http://ApacheCon.Com/2000/EU/html/cfp.html>

For more information about the conference, see

http://ApacheCon.Com/>.

There will only be one more reminder about this deadline..
-- 
#kenP-)}

Ken Coar
Apache Software Foundation  
"Apache Server for Dummies" 
"Apache Server Unleashed"   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Segmentation Fault

[Pierre Laplante]

I am using RH 6.2, mod-perl 1.24, apache 1.3.12 with the following
program with Apache/registry:

#!/usr/bin/perl -w
use strict;

my $p = new xyz;
for(my $i=0; $i < 10; ++$i) {
 for(my $j=1;$j<100;++$j) {
 my $file = "../xml/$j.xml";
 my $t = $p -> loadxml($file);
 }
}
print "Content-type: text/html\n\nallo\n";

package xyz;
use XML::Parser;
sub new { bless {}; }

sub loadxml {
my($self, $file)=@_;
my $p = new XML::Parser(Style => 'Tree');
my $t = $p -> parsefile($file);
return $t;
}

After a few run, I got a segmentation fault with apache.

Any idea?

thanks.

-- 
Pierre Laplante
SedNove Inc.

Re: [performance/benchmark] printing techniques

[Frank Wiles]

 .--[ Jeff Norman wrote (2000/06/07 at 14:27:29) ]--
 | 
 |  Frequently, it's hard to build up an entire output segment without
 |  code in-between the different additions to the output.  I guess you could
 |  call this the "append, append, append... output" technique.
 |  
 |  I think it would be an interesting addition to the benchmark:
 |  
 | sub gather_print{
 |   my $buffer = '';
 |   $buffer .= "";
 |   $buffer .= ""; 
 |   $buffer .= "  ";   
 |   $buffer .= "";
 |   $buffer .= "  Test page";
 |   $buffer .= "";
 |   $buffer .= "  ";
 |   $buffer .= "  ";
 |   $buffer .= " ";
 |   $buffer .= "  Test page ";
 |   $buffer .= "";
 |   $buffer .= "foo";
 |   $buffer .= ""; 
 |   $buffer .= "  ";
 |   $buffer .= "";
 |   print $fh $buffer;
 | }
 |  
 `-

What the other programmer here and I do is setup an array and push()
our lines of output onto it throughout all our code, and print it at
the very end.  I'd be interested in seeing benchmarks of this vs.
the other methods.  I'll try to find the time to run them. 

 ---
  Frank Wiles <[EMAIL PROTECTED]>
  http://frank.wiles.org
 ---

[performance/benchmark] $|=1 doesn't matter ?!

[Stas Bekman]

Ok, you'd get surprised on this one. I cannot make benchmark show me
unbuffered output worse than buffered. Anyone can tell me why? there is
ap_flash call after each print in the unbuffered case, how comes the
results are the same?

name | avtime completed failedrps 
--
buffering|324  5000  0151 
unbuffering  |325  5000  0150 
--

I've tried to print the average page size of about 64k to make as close as
possible to the real world test, but certainly using a way too many print
calls... still it doesn't change the results. I'm probably missing
something... can you see what it is?

The code:

package UnBuffered;
use Apache::Constants qw(:common);
local $|=1;
sub handler{
  my $r = shift;
  $r->send_http_header('text/plain');
  my $string = "a" x 128;
  for (1..512){
print $string,"\n";
  }
  return OK;
}

1;

package Buffered;
use Apache::Constants qw(:common);
sub handler{
  my $r = shift;
  $r->send_http_header('text/plain');
  my $string = "a" x 128;
  for (1..512){
print $string,"\n";
  }
  return OK;
}

1;


Thanks!


_
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

[OT] Re: [performance/benchmark] printing techniques

[Perrin Harkins]

On Wed, 7 Jun 2000, Matt Sergeant wrote:

> On Wed, 7 Jun 2000, Eric Cholet wrote:
> 
> > This said, i hurry back to s/"constant strings"/'constant strings'/g;
> 
> Those two are equal.

Yes, although it's counter-intutive there's no real performance hit
from double-quoting constant strings.

The one that bugs me is when I see people doing this:

$hash{"$key"}

instead of this:

$hash{$key}

That one is actually in the perlfaq man page, but I still see it all the
time.  The performance difference is very small but it does exist, and you
can get unintended results from stringifying some things.

- Perrin

RE: [performance/benchmark] printing techniques

[Jerrad Pierce]

What about heredoc with the magical @{} technique for interpolating
functions?
or Text::iPerl ? I'd be interested in knwing how they stack up
  o _
 /|/ |   Jerrad Pierce \ | __|_ _|
 /||/   http://pthbb.org  .  | _|   |
 \||  _.-~-._.-~-._.-~-._@"  _|\_|___|___|

Re: [performance/benchmark] printing techniques

[Stas Bekman]

> What the other programmer here and I do is setup an array and push()
> our lines of output onto it throughout all our code, and print it at
> the very end.  I'd be interested in seeing benchmarks of this vs.
> the other methods.  I'll try to find the time to run them. 

handler:
query   | avtime completed failedrps 
-
single_print|108  5000  0890 
here_print  |110  5000  0887 
concat_print|111  5000  0876 
aggrlist_print  |113  5000  0862 
list_print  |113  5000  0861 
multi_print |118  5000  0820 
-


unbuffered benchmark

single_print:2 wallclock secs ( 2.29 usr +  0.46 sys =  2.75 CPU)
here_print:  2 wallclock secs ( 2.42 usr +  0.50 sys =  2.92 CPU)
list_print:  7 wallclock secs ( 7.26 usr +  0.53 sys =  7.79 CPU)
concat_print:9 wallclock secs ( 8.90 usr +  0.60 sys =  9.50 CPU)
aggrlist_print: 32 wallclock secs (32.37 usr +  0.71 sys = 33.08 CPU)
multi_print:21 wallclock secs (16.47 usr +  5.84 sys = 22.31 CPU)

buffered benchmark

single_print:3 wallclock secs ( 1.69 usr +  0.02 sys =  1.71 CPU)
here_print:  3 wallclock secs ( 1.76 usr +  0.01 sys =  1.77 CPU)
list_print:  7 wallclock secs ( 6.41 usr +  0.03 sys =  6.44 CPU)
concat_print:8 wallclock secs ( 8.23 usr +  0.05 sys =  8.28 CPU)
multi_print:10 wallclock secs (10.70 usr +  0.01 sys = 10.71 CPU)
aggrlist_print: 30 wallclock secs (31.06 usr +  0.04 sys = 31.10 CPU)

Ouch :( Someone to explain this phenomena? and it's just fine under the
handler puzzled, what can I say...


here is the code delta...

  sub aggrlist_print{
my @buffer = ();
push @buffer,"\n";
push @buffer,"\n";
push @buffer,"  \n";
push @buffer,"\n";
push @buffer,"  Test page\n";
push @buffer,"\n";
push @buffer,"  \n";
push @buffer,"  \n";
push @buffer," \n";
push @buffer,"  Test page \n";
push @buffer,"\n";
push @buffer,"foo\n";
push @buffer,"\n";
push @buffer,"  \n";
push @buffer,"\n";
print @buffer;
  }


_
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

Fwd: Re: [ID 20000527.001] Carp::Heavy - Bizarre copy of HASH in aassign

[Jeremy Howard]

You might remember the 'Bizarre copy of HASH in aassign' when using
CGI::Carp I posted a workaround for... Here's an update from Perl 5
Porters--it's being fixed in the next release:

- Original message -
From: Gurusamy Sarathy <[EMAIL PROTECTED]>
To: Jeremy Howard <[EMAIL PROTECTED]>
Date: 2000-06-07 11:04:22
Subject: Re: [ID 2527.001] Carp::Heavy - Bizarre copy of HASH in
aassign

On Wed, 07 Jun 2000 16:00:57 +0200, Richard Foley wrote:
>The following causes a 'Bizarre copy of HASH in aassign' error
>perl -MCGI::Carp -d -e 'print croak(1)'
>
>
>It only occurs in debug mode.
[...]
>I don't know if there's any reason the DB package was used in
>Carp::Heavy... If so, this fix may break something.

Yes, that will break things.

The real problem should be fixed in 5.6.1 (coming sometime before
mid-July, I hope).


Sarathy
[EMAIL PROTECTED]

-- 
  Jeremy Howard
  [EMAIL PROTECTED]

Re: Big pages and gzip

[Ken Williams]

[EMAIL PROTECTED] (Stas Bekman) wrote:

>On Wed, 7 Jun 2000, Mark Hewis wrote:
>
>> it would seem to be quite straight forward to implement a handler to gzip
>> all output html files depending on the allowed mime-types and/or user_agent.
>> This would reduce many pages by up to a factor of 10 in size. 
>> 
>> 1) Is anyone already doing?
>> 2) If not why not?
>> 3) what borwsers would accept html files in a gzipped format
>
>it's there for a long time:
>Apache::Gzip
>Apache::GzipChain

Actually, as far as I know there's no Apache::Gzip.  But that's a lie
too - I've been harboring a new Apache::Gzip that seems to work, and
plays well with Apache::Filter too.  As if you couldn't guess that based
on my other modules. =)

I think I'll have a version of Apache::Gzip up on CPAN within a couple
of days.  Eager-worts can look at
http://mathforum.com/~ken/modules/Apache-Gzip/ in the meantime.


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum

Re: Big pages and gzip

[Stas Bekman]

On Wed, 7 Jun 2000, Ken Williams wrote:

> [EMAIL PROTECTED] (Stas Bekman) wrote:
> 
> >On Wed, 7 Jun 2000, Mark Hewis wrote:
> >
> >> it would seem to be quite straight forward to implement a handler to gzip
> >> all output html files depending on the allowed mime-types and/or user_agent.
> >> This would reduce many pages by up to a factor of 10 in size. 
> >> 
> >> 1) Is anyone already doing?
> >> 2) If not why not?
> >> 3) what borwsers would accept html files in a gzipped format
> >
> >it's there for a long time:
> >Apache::Gzip
> >Apache::GzipChain
> 
> Actually, as far as I know there's no Apache::Gzip.  But that's a lie
> too - I've been harboring a new Apache::Gzip that seems to work, and
> plays well with Apache::Filter too.  As if you couldn't guess that based
> on my other modules. =)

Ouch, that's the module I was refering to. I thought you are going to
release it :) it worked for me...

> I think I'll have a version of Apache::Gzip up on CPAN within a couple
> of days.  Eager-worts can look at
> http://mathforum.com/~ken/modules/Apache-Gzip/ in the meantime.
> 
> 
>   ------
>   Ken Williams Last Bastion of Euclidity
>   [EMAIL PROTECTED]The Math Forum
> 
> 
> 



_
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

Apache, Mod_Perl and Custom Access/Authentication

[Steffers]

hello,
first let me apologise for jst jumping straight into asking 
questions on the mailing list, but this is really puzzling me. First
some background.

I have been using perl for the past 3 years. I think (note
+think+) that I understand perl quite well, so when the job came up
at work here to tie the programs into Apache using mod_perl I 
figured it wouldnt be that hard. (Apache 1.3.12 and latest mod_perl)

I am still trying to get out of my 'cgi' ways (exit and $| and
such forth), so the code attached my look a tad strange. apologies
again for that.

The problem is, that I want to first have the access working
so that if someone doesnt have a cookie with 'sessionID' set in it,
then we know that they are a 'new user'.  In this case, no other checks
are needed (we require valid-user). 

IF the sessionid is valid, then we move onto authentication
which in this case is simply firing off the username and password to
PostgreSQL. The way that PostgreSQL is setup, it uses encrypted 
passwords for connection, so simply getting a valid connection is
'good enough' to prove the user (in my eyes for the moment).

So once they have connected up succesfully, I cache the
DBI connection (by using Apache::DBI) and then creating a sessionID
cookie for the user. 

This then means that the user will only have to 're-authenticate'
when the cookie times out. I dont know if i need to use the 'ping function'
to keep PostgreSQL alive, but thats a 'todo' for sure.

So what am I doing wrong ? There is probably a hundred things
here, and I +have+ read the faqs and even the oreilly book, i dont see 
anything glaring, but then this is why its a learning process. (oh and 
for what its worth the database and apache are working fine. its my code
that has the 'features' (okay okay, bugs ;))

Feel free to critisce my code/offer guidance/nudge improvments
or jst hit me with a large pointed stick ;)
many thanks
Stefs.


.htaccess
---
PerlAccessHandler Apache::ResAcc
PerlAuthenHandler Apache::ResAuth
require valid-user



ResAcc.pm

package Apache::ResAcc;
use strict;
use Apache::Constants qw(:common);
use Safe();

my $Safe=Safe->new;

use vars qw(@EXPORT $USE_THREAD $USE_SFIO $PERL_DIR);
use Exporter ();
use Config;
use FileHandle ();
*import = \&Exporter::import;

@EXPORT = qw(handler); 

use subs @EXPORT;


# This module will check for the presence of a sessionid and if found will
# allow access, otherwise it will print out the login screen with two inputs
# one for username and the other for password
sub handler 
{   my $r = shift;
my $login = "\n\n\n#Imagine a password
form here\n\n";


my $header_ID=$r->header_in('sessionID');
if ($header_ID ne "")
{ # check the value in the database
  # return declined if bad
  # else return ok
  return OK;
}
else
{ $r->custom_response(FORBIDDEN, $login);
  return FORBIDDEN; 
}
}
1;



ResAuth.pm

package Apache::ResAuth;

use strict;
use Apache::Constants qw(:common);
use Apache::Registry;
use CGI qw(:standard);
use DBI;

use vars qw(@EXPORT $USE_THREAD $USE_SFIO $PERL_DIR);
use Exporter ();
use Config;
use FileHandle ();
*import = \&Exporter::import;

@EXPORT = qw(handler); 

use subs @EXPORT;

sub handler {
my $r = shift;

# get user's authentication credentials
my ($username,$password) = map { param($_) } qw(user pass);

my $reason = authenticate($r, $username, $password);
 
if($reason) {
$r->note_basic_auth_failure;
$r->log_reason($reason, $r->filename);
return AUTH_REQUIRED;
}
 my $query=CGI::new(); 
 my $my_cookie=$query->cookie(-name=>'sessionID',
  -value=>'1',
  -path=>'/',
  -expires=>'+30m');
 $r->header_out->add("Set-cookie"=>$my_cookie);
return OK;
}

sub authenticate {
my($r, $username, $password) = @_;

$username && $password or return 'empty user names and passwords
disallowed';
my $db_dsn=$r->dir_config('ResAuth') || 'dbi:Pg:host=legion
dbname=mms_post';
my $databh = DBI->connect($db_dsn,$username,$password) || return
"couldn't open database";

# if we get here, all is well
return "";
}

1;

ANNOUNCE: mod_perl Guide 1.24

[Stas Bekman]

mod_perl Guide Version 1.24 Jun 7, 2000 has been released.

The online version:
http://perl.apache.org/guide/

The PDF version: 631pages (1,810KB compressed)
http://perl.apache.org/guide/mod_perl_guide.pdf.gz

The sources at CPAN:

  file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.24.tar.gz
  size: 526902 bytes
   md5: 0df696c91cf252254f2b442ff506b662

The CVS sources, the latest snapshots at:
http://www.stason.org/guide-snapshots/

The Changes:

New 2 search engines and splitted version of the Guide. Vivek's version is
almost up to date, Randy's is not. So please use Vivek's version for
search. The search form is at http://perl.apache.org/guide/.

If any of corrections/notes didn't enter this version, I promise to put
it in on the next release.

06.07.2000 ver 1.24

* perl: "catching exceptions" -- a few corrections (Matt Sergeant)

* modules: added Apache::Gzip (Ken Williams)

* guide's design

  o put back the links underlining

  o background-color: #ee;

  o added (jump) menus to reach search/download/index from everywhere
  
  o added the two new search engines (both working on the split
version of the guide)

* guide's build: 

  o The build code was completely rewritten, html2ps is now bundled
with the guide so one can create PS version, and if there is
ps2pdf the PDF version.

  o It can produce the split version of the Guide.

  o One can easily reuse the package to build his own docs, since the
look-n-feel has been moved into the templates from the code.

  o Once I feel confident I'll probably separate the build code from
the Guide to give it its own life and make it easier to reuse by
other developers. I need testers who want to use this package
before I release it a separate module.

* performance: 

  o old sections rewritten/improved:
- Are My Variables Shared?
- Preloading Registry Scripts
- Calculating Real Memory Usage
- Preloading Perl Modules at Server Startup 
-  Preloading Registry Scripts at Server Startup 
- Forking and Executing Subprocesses from mod_perl 
  = Spawning a Detachable Sub-Process
  = Gory Details About fork()
  = Executing system() in the Right Way
  = Avoiding Zombie Processes

  o new sections:
- Apache/mod_perl Build Options
  = mod_perl Process Size as a Function of Compiled in C Modules and
   mod_perl Features
- Modules Initializing at Server Startup
  = Initializing DBI.pm (corrections by Tim Bunce)
  = Initializing CGI.pm

* control: 

  o These sections were rewritten and extended:
- Server Maintenance Chores 
= Handling Log Files 
  + Log Rotation 
  + Non-Scheduled Emergency Log Rotation 

  o 'cyclog' is now called multilog (from daemontools package)

  o Moved from debug and rewritten "Speeding up the Apache Termination
and Restart"

  o Rewritten and extended "SUID Start-up Scripts" with: 
"Introduction to SUID Executables"
"Apache Startup SUID Script's Security"
"Sample Apache Startup SUID Script"

* hardware: partly rewritten and improved.

* reconstruction process: obvious.pod has been disassembled and merged
  into debug.pod.

* debug: update: Apache::DumpHeaders (Ask Bjoern Hansen)

* troubleshooting: PerlFreshRestart is irrelevant for DSO (Vivek
  Khera, Doug)

* review: 

  o Drew Taylor has reviewed these chapters: scenario and strategy
chapters.

  o Mark Summerfield has reviewed these chapters: scenario, perl and
strategy chapters.

  o Eric Cholet has reviewed the porting chapter.

* Minor corrections: 
  o download (Salve J Nilsen)
  o performance (w trillich) 
  o perl (Scott Holdren) 
  o snippets+download (Ask Bjoern Hansen) 
  o debug (Robert Mathews) 
  o scenario (Tuomas Salo)


Enjoy!

_
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

regular cgis and mod_include and/or Apache::SSI

[Alex Menendez]

Hello, all

I have a very simple problem for which I am sure (hope) there is a very
simple solution.
I basically want to pipe cgi output to mod_include or rather the
equivalent mod_perl module, Apache::SSI.

I do not want to make the cgis mod_perl modules nor Apache::Registery
scripts. Just want to take their output and
run it through an include type module that will parse server side
includes if they exist.

I looked into chaining modules (tying file handles) where one module is
a fake module that just executes the cgi and the second would be the
virtual include mod that takes the first ones output as input and does
the actual work. However, this seems rather cumbersome to get such a
simple thing done.

Any ideas?

thanx in advance,
-amen

Apache::ASP

[Clement Law]

I get a 500 Internal Server Error when I try to run a ASP file.
I'm using Windows NT Server. And the webserver I'm using is Apache V1.3.12
with Mod_perl
Perl: c:\usr\perl\bin
ASP.PM: c:\usr\perl\site\lib\apache\asp.pm
Other: c:\usr\perl\lib
I'm using Virtual Hosts in Apache too.
I have no clue what's the problem right now.

this was the asp script I was trying to run, count.asp
-= START =-

<%IF IsEmpty(Session("TotalCount")) THEN
  Call MakeCount
End IF

Sub MakeCount()
  Dim FSO   ' FileSystemObject
  Dim TS' TextStreamObject
  Dim CountFileName ' Count File Name
  Dim OldCount, NewCount' Counting Variables
  Dim I 
  Dim Create

  Create = True 
  MyCountFile = Server.MapPath("Counter.txt")
  Set FSO = Server.CreateObject("Scripting.FileSystemObject")
  Set TS = FSO.OpenTextFile(MyCountFile, 1, Create)

  IF Not TS.AtEndOfStream Then
OldCount = TS.ReadAll
  Else
OldCount = 0
  End If
  TS.Close

  NewCount = OldCount + 1

  Session("TotalCount")= NewCount
  Set TS = FSO.CreateTextFile(MyCountFile, Create)
  TS.Write NewCount
  TS.Close
  Set FSO = Nothing
  Set TS = Nothing
End Sub
%>

-= END =-

my HTTPD.CONF is as follows:
-= START =-

ServerType standalone
ServerRoot "C:/Program Files/Apache"
PidFile logs/httpd.pid
ScoreBoardFile logs/apache_status
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MaxRequestsPerChild 0
ThreadsPerChild 50
Port 80
ServerAdmin [EMAIL PROTECTED]
DirectoryIndex index.html index.shtml index.htm index.shtm
AccessFileName .htaccess

Order allow,deny
Deny from all

UseCanonicalName On
TypesConfig conf/mime.types
DefaultType text/plain

MIMEMagicFile conf/magic

HostnameLookups Off

ErrorLog logs/error.log
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog logs/access.log common
ServerSignature On
Alias /icons/ "/Apache/icons/"
IndexOptions FancyIndexing
AddIconByEncoding (CMP,/icons/small/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/small/text.gif) text/*
AddIconByType (IMG,/icons/small/image2.gif) image/*
AddIconByType (SND,/icons/small/sound2.gif) audio/*
AddIconByType (VID,/icons/small/movie.gif) video/*
AddIcon /icons/small/binary.gif .bin .exe
AddIcon /icons/small/binhex.gif .hqx
AddIcon /icons/small/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/small/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/small/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/small/uu.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/small/text.gif .tex
AddIcon /icons/small/burst.gif core
AddIcon /icons/small/back.gif ..
AddIcon /icons/small/text.gif README
AddIcon /icons/small/dir.gif ^^DIRECTORY^^
AddIcon /icons/small/blank.gif ^^BLANKICON^^
DefaultIcon /icons/small/unknown.gif
AddDescription "GZIP compressed document" .gz
AddDescription "tar archive" .tar
AddDescription "GZIP compressed tar archive" .tgz
AddDescription "ZIP archive" .zip
AddDescription "CAB archive" .cab
AddDescription "Win32 Executable" .exe
ReadmeName README
HeaderName HEADER
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
AddEncoding x-compress Z
AddEncoding x-gzip gz
AddLanguage en .en
AddLanguage de .de
AddLanguage fr .fr
LanguagePriority en de fr
ScriptAlias /phpexecutable/ "/usr/php/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/phpexecutable/php.exe"
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
AddType text/html .shtml
AddType text/html .shtm
AddHandler server-parsed .shtml
AddHandler server-parsed .shtm
AddHandler server-parsed .html
AddHandler server-parsed .htm
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
LoadModule perl_module modules/ApacheModulePerl
ScriptAlias /advertisments/ "C:/Program Files/Apache/cgi-bin/"

SetHandler perl-script
PerlHandler Apache::ASP
PerlSetVar Global /temp


-= END =-

Any suggestions or help, Thanks

[Hui Zhu]

Hi Everybody:

I got big problems. Same query and same script. Sometimes it works fine
but sometimes i get the following
errors (i am so frustrated, have no idea what i need to do):

DBD::mysql::db do failed: MySQL server has gone away at cnznetmod.pm
line 151.
DBD::mysql::st execute failed: MySQL server has gone away at
cnznetmod.pm line 159.
DBD::mysql::st execute failed: MySQL server has gone away at
cnznetmod.pm line 130.
DBD::mysql::st fetchrow failed: fetch() without execute() at
cnznetmod.pm line 131.

I remember that i had a same problem when our system upgrated last time.
Once i reinstalled ApacheDBI-0.87,
it works fine. But this time, i did so but it still doesn't work. Thank
you for your help.

Steven.

BTW: Linux redhat6.2, ApacheDBI-0.87, DBI-1.13, Modperl-1.21,
Msql-Mysql-modules-1.22
  Mysql3.22

Re: Apache::ASP

[___cliff rayman___]

i've never used Apache::Asp, but i thought it was used to embed perl using asp
constructs.  what you have looks like visual basic which is microsoft ONLY
stuff.  it should say this in the intro to the docs somewhere.


--
___cliff [EMAIL PROTECTED]

Clement Law wrote:

> I get a 500 Internal Server Error when I try to run a ASP file.
> I'm using Windows NT Server. And the webserver I'm using is Apache V1.3.12
> with Mod_perl
> Perl: c:\usr\perl\bin
> ASP.PM: c:\usr\perl\site\lib\apache\asp.pm
> Other: c:\usr\perl\lib
> I'm using Virtual Hosts in Apache too.
> I have no clue what's the problem right now.
>
> this was the asp script I was trying to run, count.asp
> -= START =-
>
> <%IF IsEmpty(Session("TotalCount")) THEN
>   Call MakeCount
> End IF
>
> Sub MakeCount()
>   Dim FSO   ' FileSystemObject

Apache::ASP

[Clement Law]

I get a 500 Internal Server Error when I try to run a ASP file.
I'm using Windows NT Server. And the webserver I'm using is Apache V1.3.12
with Mod_perl
Perl: c:\usr\perl\bin
ASP.PM: c:\usr\perl\site\lib\apache\asp.pm
Other: c:\usr\perl\lib
I'm using Virtual Hosts in Apache too.
I have no clue what's the problem right now.

this was the asp script I was trying to run, count.asp
-= START =-

<%IF IsEmpty(Session("TotalCount")) THEN
  Call MakeCount
End IF

Sub MakeCount()
  Dim FSO   ' FileSystemObject
  Dim TS' TextStreamObject
  Dim CountFileName ' Count File Name
  Dim OldCount, NewCount' Counting Variables
  Dim I 
  Dim Create

  Create = True 
  MyCountFile = Server.MapPath("Counter.txt")
  Set FSO = Server.CreateObject("Scripting.FileSystemObject")
  Set TS = FSO.OpenTextFile(MyCountFile, 1, Create)

  IF Not TS.AtEndOfStream Then
OldCount = TS.ReadAll
  Else
OldCount = 0
  End If
  TS.Close

  NewCount = OldCount + 1

  Session("TotalCount")= NewCount
  Set TS = FSO.CreateTextFile(MyCountFile, Create)
  TS.Write NewCount
  TS.Close
  Set FSO = Nothing
  Set TS = Nothing
End Sub
%>

-= END =-

my HTTPD.CONF is as follows:
-= START =-

ServerType standalone
ServerRoot "C:/Program Files/Apache"
PidFile logs/httpd.pid
ScoreBoardFile logs/apache_status
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MaxRequestsPerChild 0
ThreadsPerChild 50
Port 80
ServerAdmin [EMAIL PROTECTED]
DirectoryIndex index.html index.shtml index.htm index.shtm
AccessFileName .htaccess

Order allow,deny
Deny from all

UseCanonicalName On
TypesConfig conf/mime.types
DefaultType text/plain

MIMEMagicFile conf/magic

HostnameLookups Off
ErrorLog logs/error.log
LogLevel warn
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""
combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
CustomLog logs/access.log common
ServerSignature On
Alias /icons/ "/Apache/icons/"
IndexOptions FancyIndexing
AddIconByEncoding (CMP,/icons/small/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/small/text.gif) text/*
AddIconByType (IMG,/icons/small/image2.gif) image/*
AddIconByType (SND,/icons/small/sound2.gif) audio/*
AddIconByType (VID,/icons/small/movie.gif) video/*
AddIcon /icons/small/binary.gif .bin .exe
AddIcon /icons/small/binhex.gif .hqx
AddIcon /icons/small/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/small/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/small/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/small/uu.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/small/text.gif .tex
AddIcon /icons/small/burst.gif core
AddIcon /icons/small/back.gif ..
AddIcon /icons/small/text.gif README

AddIcon /icons/small/dir.gif ^^DIRECTORY^^
AddIcon /icons/small/blank.gif ^^BLANKICON^^
DefaultIcon /icons/small/unknown.gif
AddDescription "GZIP compressed document" .gz
AddDescription "tar archive" .tar
AddDescription "GZIP compressed tar archive" .tgz
AddDescription "ZIP archive" .zip
AddDescription "CAB archive" .cab
AddDescription "Win32 Executable" .exe
ReadmeName README
HeaderName HEADER
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
AddEncoding x-compress Z
AddEncoding x-gzip gz
AddLanguage en .en
AddLanguage de .de
AddLanguage fr .fr
LanguagePriority en de fr
ScriptAlias /phpexecutable/ "/usr/php/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/phpexecutable/php.exe"
AddHandler cgi-script .cgi
AddHandler cgi-script .pl
AddType text/html .shtml
AddType text/html .shtm
AddHandler server-parsed .shtml
AddHandler server-parsed .shtm
AddHandler server-parsed .html
AddHandler server-parsed .htm
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
LoadModule perl_module modules/ApacheModulePerl
ScriptAlias /advertisments/ "C:/Program Files/Apache/cgi-bin/"

SetHandler perl-script
PerlHandler Apache::ASP
PerlSetVar Global /temp


-= END =- 

Re: ANNOUNCE: mod_perl Guide 1.24

[Stas Bekman]

This is notify you that Randy's guide search engine's content is up to
date, and Vivek's version is almost up-todate, so you can use both now. 

Enjoy!

_
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

still can't find mod_perl for win9x/NT

[Walter Hissink]

Hello,
I still can't find the mod_perl for win32.
On the mod_perl website now no mention is even made about that specific
port.

Does anyone know where i can get me a mod_perl which works in the win32
version of apache ??

Hope someone can help.

Walter

PerlTransHandler and CGI.pm

[Eric Jain]

When processing the url
http://biodoc.ch/de/search?query=%2Btest+%2Bdna+-xyz ,
$cgi->param('query') correctly returns '+test +dna -xyz'.

But if I use http://biodoc.ch/de/search;query=%2Btest+%2Bdna+-xyz
instead, I get ' test  dna -xyz'. If I include a %3F (=?) in the url,
I even get a 404 error. Slashes too only work if they are not encoded.

There must be something wrong in my PerlTransHandler, approximatly
here:

my $uri = $r->uri();

if ( my($u1,$u2) = $uri =~ / ^ ([^?]+?) ; ([^?]*) $ /x )
{
$r->uri($u1);
$r->args($u2);
}

But what?

--
Eric Jain

Re: still can't find mod_perl for win9x/NT

[Aaron Johnson]

 ftp://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-0.6.exe

That is the full URL for the file.
It contains Perl Apache and mod_perl + tons of other modules.

As for mod_perl by itself, I haven't seen that yet, and that is very ify
because you have to use the same compiler for the modules as you did Perl.

Aaron Johnson

Walter Hissink wrote:

> Hello,
> I still can't find the mod_perl for win32.
> On the mod_perl website now no mention is even made about that specific
> port.
>
> Does anyone know where i can get me a mod_perl which works in the win32
> version of apache ??
>
> Hope someone can help.
>
> Walter

RE: PerlTransHandler and CGI.pm

[Eric Jain]

Got it... Seems like the query string is decoded twice: Therefore

http://biodoc.ch/de/search;query=%252Btest+%252Bdna+-xyz

works perfectly, since all the '%' are encoded. Then it even works
with slashes :-)


--
Eric Jain


> When processing the url
> http://biodoc.ch/de/search?query=%2Btest+%2Bdna+-xyz ,
> $cgi->param('query') correctly returns '+test +dna -xyz'.
>
> But if I use http://biodoc.ch/de/search;query=%2Btest+%2Bdna+-xyz
> instead, I get ' test  dna -xyz'. If I include a %3F (=?)
> in the url,
> I even get a 404 error. Slashes too only work if they are
> not encoded.
>
> There must be something wrong in my PerlTransHandler, approximatly
> here:
>
>   my $uri = $r->uri();
>
>   if ( my($u1,$u2) = $uri =~ / ^ ([^?]+?) ; ([^?]*) $ /x )
>   {
>   $r->uri($u1);
>   $r->args($u2);
>   }
>
> But what?
>
> --
> Eric Jain
>