Re: APR::Brigade::destroy (re: talk @sophos)
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
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
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
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
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
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
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
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
> > 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
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