Re: APR::Brigade::destroy (re: talk @sophos)

2004-07-15 Thread Stas Bekman
dorian taylor wrote:
Thanks for the idea, dorian. Patches are more than welcome. Look at 
APR::Pool for an example of how to do it in XS. It should be just 2 
lines of code :)
well, it was indeed just a few lines of code (see the patch attached at 
the end), but we can't do that in a simple alias of destroy to DESTROY. 
I've implemented it and all the filters went broken. The reason is that 
the $bb argument passed to the input filters is special [1], the caller 
expects the callee to fill it in. With implicit DESTROY it gets 
destroyed before the caller gets it, wrecking havoc. So unless we 
somehow tag $bb's passed as an argument as special and not eligible for 
DESTROY, we can't add this change. We already do a similar thing for 
APR::Pool objects, where native pools like $r->pool, in no way can be 
destroyed.

[1] http://perl.apache.org/docs/2.0/user/handlers/filters.html#Input_Filters
The simple (not acceptable patch):
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.413
diff -u -r1.413 Changes
--- Changes 15 Jul 2004 06:23:21 -  1.413
+++ Changes 15 Jul 2004 08:03:52 -
@@ -12,6 +12,9 @@
 =item 1.99_15-dev
+add APR::Brigade::DESTROY so now there is no need to call an explicit
+$bb->destroy, $bb gets destroyed at the end of the scope [Stas]
+
 fix an old outstanding bug in the APR::Table's TIE interface with
 each()/values() over tables with multi-values keys. Now the produced
 order is correct and consistent with keys(). Though, values() works
Index: xs/APR/Brigade/APR__Brigade.h
===
RCS file: /home/cvs/modperl-2.0/xs/APR/Brigade/APR__Brigade.h,v
retrieving revision 1.13
diff -u -r1.13 APR__Brigade.h
--- xs/APR/Brigade/APR__Brigade.h   9 Jun 2004 14:46:22 -   1.13
+++ xs/APR/Brigade/APR__Brigade.h   15 Jul 2004 08:03:56 -
@@ -159,3 +159,5 @@
 {
 MP_RUN_CROAK(apr_brigade_destroy(bb), "APR::Brigade::destroy");
 }
+
+#define mpxs_APR__Brigade_DESTROY(bb) mpxs_APR__Brigade_destroy(aTHX_ bb)
Index: xs/maps/apr_functions.map
===
RCS file: /home/cvs/modperl-2.0/xs/maps/apr_functions.map,v
retrieving revision 1.83
diff -u -r1.83 apr_functions.map
--- xs/maps/apr_functions.map   15 Jul 2004 06:23:21 -  1.83
+++ xs/maps/apr_functions.map   15 Jul 2004 08:03:56 -
@@ -82,6 +82,7 @@
  apr_brigade_create | mpxs_ | SV *:CLASS, p, list | new
 ~apr_brigade_destroy
  mpxs_APR__Brigade_destroy
+void:DEFINE_DESTROY | | apr_bucket_brigade *:bb
 !apr_brigade_partition
 !apr_brigade_printf
 -apr_brigade_putstrs
and the doc:
Index: src/docs/2.0/api/APR/Brigade.pod
===
RCS file: /home/cvs/modperl-docs/src/docs/2.0/api/APR/Brigade.pod,v
retrieving revision 1.10
diff -u -r1.10 Brigade.pod
--- src/docs/2.0/api/APR/Brigade.pod12 Jul 2004 23:13:22 -  1.10
+++ src/docs/2.0/api/APR/Brigade.pod15 Jul 2004 08:05:29 -
@@ -146,6 +146,20 @@

+=head2 C
+
+Same as Cdestroy()|/C_destroy_>>, but invoked implicitly at
+the end of the scope of the bucket brigade object. Normally you should
+rely on C, and only when you really need to destroy the
+bucket brigade explicitly call Cdestroy()|/C_destroy_>>.
+
+=over 4
+
+=item since: 1.99_15
+
+=back
+
+
 =head2 C
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Re: Problem with Apache::Session::MySQL

2004-07-15 Thread Pascal Robert
Le 04-07-14, à 18:03, Perrin Harkins a écrit :
On Wed, 2004-07-14 at 17:45, Pascal Robert wrote:
I have a strange problem with Apache::Session::MySQL.  It create a
session just fine, but it can't update itself.
Usually this means that either your session object isn't going out of
scope or the values you are writing are not at the top level.  However,
$session{'lang'} would be top-level.
What happens if you explicitly untie the session at the end of the
request?
It works, thanks!
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


mod_perl regex conundrum

2004-07-15 Thread Simon Miner








Hello,

 

My company has just upgraded our Apache/mod_perl and
supporting software versions, and we are now seeing a strange phenomenon. 
A piece of code which has always worked speedily up to this point, now
occasionally, but predictably, takes 10 times longer to execute.  The code
fragment in question is this.

 

-

my $quoted_link = qr{

    ((href|action)\s*=\s*)  # matching
a link in an href or action attribute ($1)

   
(["']) 
# starting link delimiter (' or ") ($3)

    (

  (https?://\w+?\.chr(istian)?book\.com)?  
# optional domain name (old or new) ($4)

 
/
# / separating domain from path

  (?![^\3\#\?>]+?\.(exe|sit|pdf|ra?m|mp3|wax|css|js))  
# skip non-HTML file types

 
[^\3\#\?>]+? 
# anything that can be in a path (no anchors, query strings, etc.

   
)  
# everything before the ticket

    (

 
[\?\#]   
# start of a query string or anchor reference

 
[^\3]+?  
# query string or anchor reference

   
)? 
# everything after the ticket ($8)

   
\3 
#
ending link delimiter

}six;

...

$$text_ref =~ s{$quoted_link}{$1$3$4/$ticket$8$3}gx;

---

The purpose of this code is to tag each URL on a web page
with a session ID.  The $text_ref variable is a scalar reference to the
page content, and the $ticket variable contains the ID.

 

In an effort to debug why the slow-down was occurring, I
replaced the substitution in the snippet above with the following.

---

use Time::HiRes qw(time);

my $start = time;

my $elapsed;

my $count = 0;

print "Text length = " . length(
$$text_ref ) . "";

while ( $$text_ref =~ /$quoted_link/g ) {

  $count += 1;

  $elapsed = time - $start;

  print "link_filter2: $count, $&
$elapsed";

}

---

This code prints out the cumulative time the regex is taking
to match as it encounters links on a web page.  The problem continued to
show itself with this change, but I still don't know how to pinpoint why
it's happening.

 

Here are some other noteworthy items pertaining to this
problem.

 

* This problem only occurs under Apache/mod_perl.  I
saved the HTML of a normal page and a slow web page to files, and copied the
code above into a small command line script.  When I executed the script
against the files, the slow page took about the right 

amount of time to process relative to the normal page (as
opposed to 10 times as long).  (BTW: the slow page is actually smaller
than the normal page, so it should be processed more quickly, which it did in
the command line script.)

 

* Our infrastructure upgrade made involved the following
software updates.

   -- Before upgrade: Apache 1.3.29, mod_perl
1.27, Perl 5.6.1, Solaris 5.8

   -- After upgrade: Apache 1.3.31, mod_perl 1.29,
Perl 5.8.3, Solaris 5.9

 

So, I am wondering...

 

* Can anyone suggest reasons why this code might be
executing so slowly?

* Can anyone suggest potential improvements to the regex so
it will execute faster?

* Does anyone know of changes between the software versions
mentioned above that could lead to this behavior?

 

Thanks in advance for your help.

 

- Simon

 

---

Simon Miner

Applications Engineer

Christianbook.com

E: [EMAIL PROTECTED]

T: (978) 573-2233

F: (978) 573-8233

---

 








Re: mod_perl regex conundrum

2004-07-15 Thread Stas Bekman
Simon Miner wrote:
My company has just upgraded our Apache/mod_perl and supporting software
versions, and we are now seeing a strange phenomenon.  A piece of code which
has always worked speedily up to this point, now occasionally, but
predictably, takes 10 times longer to execute.  The code fragment in
question is this.

my $quoted_link = qr{ ... }
The first thing I'd do is check whether some code doesn't try to use 
$`, $&, and $', which are known to cause this kind of slowdown. See:
http://search.cpan.org/dist/Devel-SawAmpersand/lib/Devel/SawAmpersand.pm
It may happen under mod_perl since you usually end up loading quite a 
few modules into the same interpreters, including those that you aren't 
using for this particular code in question.

--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Re: Problem with Apache::Session::MySQL

2004-07-15 Thread Perrin Harkins
On Thu, 2004-07-15 at 09:12, Pascal Robert wrote:
> > What happens if you explicitly untie the session at the end of the
> > request?
> 
> It works, thanks!

Good, but be careful -- this means you have a scoping problem.  You
might be putting your session into a global or accidentally creating a
closure.  It's worth figuring out what the problem is in order to make
sure it won't bite you later with some other variable that isn't going
out of scope when it should be.

- Perrin


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Re: mod_perl regex conundrum

2004-07-15 Thread Stas Bekman
Simon Miner wrote:
Thanks for the suggestion!
Between sawampersand and grep'ing my code, I did find an instance of $&.  I
removed it, but I am still seeing the problem.
Did you actually use Devel::SawAmpersand to test it? There are other 
modules that pull those in, e.g. if you do 'use English'.

I have also noticed that the size of our mod_perl processes has doubled
since the upgrade (from ~50M to ~100M).  Did Perl, Apache, and mod_perl
really get that much bigger between the versions I mentioned in my last
email?
Perl is getting bigger all the time but definitely not by this amount. 
Use Apache::Status coupled with all the goodies it invokes (B::Size etc) 
to figure out who eats your memory. If you have your perl built with 
ithreads (to check run: perl -V:useithreads), recompile it to not enable 
those (unless you plan to use them). You will find quite a few other 
performance/memory usage related tips in the "Practical mod_perl" book [1].

Also in your original report, the example of using Time::HiRes is highly 
unreliable. You need to count CPU clocks, not wallclocks. Use 
Benchmark.pm instead.

Also have you tried using some special purpose CPAN module to do the 
parsing for you? e.g. I remember Randal's WebTechniques articles [2] 
have plenty of examples of using modules like HTML::Filter, HTML::Tree, etc.

[1] http://modperlbook.org/
[2] http://www.stonehenge.com/merlyn/WebTechniques/
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


RE: mod_perl regex conundrum

2004-07-15 Thread Simon Miner
Thanks for the suggestion!

Between sawampersand and grep'ing my code, I did find an instance of $&.  I
removed it, but I am still seeing the problem.

I have also noticed that the size of our mod_perl processes has doubled
since the upgrade (from ~50M to ~100M).  Did Perl, Apache, and mod_perl
really get that much bigger between the versions I mentioned in my last
email?

Any other suggestions on diagnosing or improving the regex would be greatly
appreciated.

Thanks again.

- Simon

-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 15, 2004 12:55 PM
To: Simon Miner
Cc: mod_perl Mailing List ([EMAIL PROTECTED])
Subject: Re: mod_perl regex conundrum

Simon Miner wrote:

> My company has just upgraded our Apache/mod_perl and supporting software
> versions, and we are now seeing a strange phenomenon.  A piece of code
which
> has always worked speedily up to this point, now occasionally, but
> predictably, takes 10 times longer to execute.  The code fragment in
> question is this.

> my $quoted_link = qr{ ... }

The first thing I'd do is check whether some code doesn't try to use 
$`, $&, and $', which are known to cause this kind of slowdown. See:
http://search.cpan.org/dist/Devel-SawAmpersand/lib/Devel/SawAmpersand.pm
It may happen under mod_perl since you usually end up loading quite a 
few modules into the same interpreters, including those that you aren't 
using for this particular code in question.


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

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Re: Replicating mod_autoindex's behaviour with a modperl handler

2004-07-15 Thread Rando Christensen
Geoffrey Young wrote:
well, if there are absolutely no real files at all, then I don't think
DirectoryIndex will work - mod_dir only applies DirectoryIndex when
$r->filename ends up being a real directory (a $r->content_type of
DIR_MAGIC_TYPE).  but other than that it looks ok :)
so, if that doesn't work I might try using mod_perl to alter mod_dir's
behavior to set the ct to DIR_MAGIC_TYPE when you need it (over rewriting
mod_autoindex).
HTH
Yes, in order to make it work, I ended up making the handler be called 
/virtual/indexer, created a /virtual dir, did a global alias of /virtual 
to that dir, and created an empty file named indexer. DirectoryIndex 
said "oh hey there IS a file!", but the execution got properly handed 
off to mod_perl when it came time to actually call /virtual/indexer.

It's working very well now, though, thank you. :)
--
Rando Christensen
<[EMAIL PROTECTED]>
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


[OT] Re: mod_perl regex conundrum

2004-07-15 Thread Larry Leszczynski

> > Between sawampersand and grep'ing my code, I did find an instance of $&.
> > I removed it, but I am still seeing the problem.
>
> Did you actually use Devel::SawAmpersand to test it? There are other
> modules that pull those in, e.g. if you do 'use English'.

On a related note, it's possible to 'use English' *without* pulling in the
problematic regex match variables, like so:

 use English qw( -no_match_vars );  # Avoids regex performance penalty



Larry

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Re: [OT] Re: mod_perl regex conundrum

2004-07-15 Thread Stas Bekman
Larry Leszczynski wrote:
Between sawampersand and grep'ing my code, I did find an instance of $&.
I removed it, but I am still seeing the problem.
Did you actually use Devel::SawAmpersand to test it? There are other
modules that pull those in, e.g. if you do 'use English'.

On a related note, it's possible to 'use English' *without* pulling in the
problematic regex match variables, like so:
 use English qw( -no_match_vars );  # Avoids regex performance penalty
Thanks Larry, the Devel::SawAmpersand manpage documents that:
http://search.cpan.org/dist/Devel-SawAmpersand/lib/Devel/SawAmpersand.pm
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html