cvs commit: modperl-2.0/lib mod_perl.pm
dougm 2002/08/20 09:49:12
Modified:.Changes
lib mod_perl.pm
Log:
bump version
Revision ChangesPath
1.37 +2 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -r1.36 -r1.37
--- Changes 20 Aug 2002 16:45:00 - 1.36
+++ Changes 20 Aug 2002 16:49:11 - 1.37
-8,6 +8,8
=over 3
+=item 1.99_06-dev
+
=item 1.99_05 - August 20, 2002
fix PerlOptions +ParseHeaders to only parse once per-request
1.6 +1 -1 modperl-2.0/lib/mod_perl.pm
Index: mod_perl.pm
===
RCS file: /home/cvs/modperl-2.0/lib/mod_perl.pm,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- mod_perl.pm 21 Jun 2002 22:35:49 - 1.5
+++ mod_perl.pm 20 Aug 2002 16:49:12 - 1.6
-4,7 +4,7
use strict;
BEGIN {
-our $VERSION = 1.9905;
+our $VERSION = 1.9906;
}
1;
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
stas2002/08/20 21:44:14
Modified:xs/APR/PerlIO apr_perlio.c
Log:
improve errors handling
add extended debugging trace
Revision ChangesPath
1.21 +34 -11modperl-2.0/xs/APR/PerlIO/apr_perlio.c
Index: apr_perlio.c
===
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- apr_perlio.c 5 Jul 2002 05:05:36 - 1.20
+++ apr_perlio.c 21 Aug 2002 04:44:14 - 1.21
-268,13 +268,20
#ifdef PERLIO_APR_DEBUG
const char *new_path = NULL;
+apr_os_file_t os_file;
+
if (!PL_dirty) {
/* if this is called during perl_destruct we are in trouble */
apr_file_name_get(new_path, st-file);
}
-Perl_warn(aTHX_ PerlIOAPR_close obj=0x%lx, file=0x%lx, name=%s\n,
- (unsigned long)f, (unsigned long)st-file,
+rc = apr_os_file_get(os_file, st-file);
+if (rc != APR_SUCCESS) {
+Perl_croak(aTHX_ filedes retrieval failed!);
+}
+
+Perl_warn(aTHX_ PerlIOAPR_close obj=0x%lx, file=0x%lx, fd=%d, name=%s\n,
+ (unsigned long)f, (unsigned long)st-file, os_file,
new_path ? new_path : (UNKNOWN));
#endif
-415,9 +422,11
{
char *mode;
const char *layers = :APR;
+PerlIOAPR *st;
PerlIO *f = PerlIO_allocate(aTHX);
+
if (!f) {
-return NULL;
+Perl_croak(aTHX_ Failed to allocate PerlIO struct);
}
switch (type) {
-430,19 +439,33
};
PerlIO_apply_layers(aTHX_ f, mode, layers);
+if (!f) {
+Perl_croak(aTHX_ Failed to apply the ':APR' layer);
+}
-if (f) {
-PerlIOAPR *st = PerlIOSelf(f, PerlIOAPR);
+st = PerlIOSelf(f, PerlIOAPR);
-/* XXX: should we dup first? the timeout could close the fh! */
-st-pool = pool;
-st-file = file;
-PerlIOBase(f)-flags |= PERLIO_F_OPEN;
+#ifdef PERLIO_APR_DEBUG
+{
+apr_status_t rc;
+apr_os_file_t os_file;
-return f;
+/* convert to the OS representation of file */
+rc = apr_os_file_get(os_file, file);
+if (rc != APR_SUCCESS) {
+croak(filedes retrieval failed!);
+}
+
+Perl_warn(aTHX_ converting to PerlIO fd %d, mode '%s'\n,
+ os_file, mode);
}
+#endif
+
+st-pool = pool;
+st-file = file;
+PerlIOBase(f)-flags |= PERLIO_F_OPEN;
-return NULL;
+return f;
}
static SV *apr_perlio_PerlIO_to_glob(pTHX_ PerlIO *pio, apr_perlio_hook_e type)
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
stas2002/08/20 21:46:44
Modified:xs/APR/PerlIO apr_perlio.c
Log:
- IoIFP(io) *must* be always set on the valid io sv, otherwise it'll be
never closed and fh and memory leaked. as i saw from doio.c, the solution
is to simply copy IoOFP.
- add IoTYPE_WRONLY and IoTYPE_RDONLY flags to protect from wrong use
Revision ChangesPath
1.22 +5 -1 modperl-2.0/xs/APR/PerlIO/apr_perlio.c
Index: apr_perlio.c
===
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- apr_perlio.c 21 Aug 2002 04:44:14 - 1.21
+++ apr_perlio.c 21 Aug 2002 04:46:44 - 1.22
-478,11 +478,15
switch (type) {
case APR_PERLIO_HOOK_WRITE:
-IoOFP(GvIOp(gv)) = pio;
+ /* if IoIFP() is not assigned to it'll be never closed, see
+ * Perl_io_close() */
+IoIFP(GvIOp(gv)) = IoOFP(GvIOp(gv)) = pio;
IoFLAGS(GvIOp(gv)) |= IOf_FLUSH;
+IoTYPE(GvIOp(gv)) = IoTYPE_WRONLY;
break;
case APR_PERLIO_HOOK_READ:
IoIFP(GvIOp(gv)) = pio;
+IoTYPE(GvIOp(gv)) = IoTYPE_RDONLY;
break;
};
RE: HTML::Template
Greetings. On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. If (as I suppose) the /perl directory has PerlScript (or relatives) as handler, that is not strange at all... Moving vignette.gif elsewhere should make the problem disappear. Cheers, alf
Re: AutoLoader bypass?
At 06:24 PM 8/19/02 -0700, Randy J. Ray wrote:
Well, my Cuse AutoLoader would be _outside_ any of the loaded modules in
the mod_perl startup.pl script after all the modules necessary for proper
execution of _your_ mod_perl environment, are loaded.
I see... you mean to have a line like this:
use AutoLoader preload = { module = [qw(suba subb)] };
be responsible for both including module (into the caller's namespace) *and*
pre-loading the specified routines? That's different that what I had interpreted from
your first idea. I though that the preload specification would be when the target
module issues its call to use AutoLoader.
Actually only the preloading part. Since by default, the preload routine would look
at %INC, this Cuse AutoLoader should be _after_ any other Cuse commands.
,,, That's different that what I had interpreted from your first idea. I though that
the preload specification would be when the target module issues its call to use
AutoLoader.
No, I wouldn't want module authors to change their modules...
From this vantage point, it does make more sense, yes. Especially since module
authors would no be responsible for retro-fitting to their packages. I would be
interested to see if this can be done cleanly, without making AutoLoader.pm any
harder to read than it currently is :-).
Well, that's just a matter of documentation, really... ;-)
(OK, that might be asking a bit much...)
Not really, AutoLoader is not a really big module at all...
Liz
RE: Mod_perl Application Development
Greetings. People often seem to get bent out of shape about putting a few Location directives in httpd.conf, I suspect that it may be due to the intimidating length that httpd.conf has reached in these times. I found that separating customizations in breakaway 'Include'd .conf files - and putting all my Include-s at the end of httpd.conf makes maintainence much easier (and upgrading apache relatively painless even under RPM's .rpmnew thing). Having Location directives [...] etc. without inventing your own config system. Warmly seconded. Cheers, alf
Re: HTML::Template
Le mardi 20 août 2002, à 09:32 AM, Alessandro Forghieri a écrit : Greetings. On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. If (as I suppose) the /perl directory has PerlScript (or relatives) as handler, that is not strange at all... Moving vignette.gif elsewhere should make the problem disappear. Many Thanks !! My problem is fixed . Cheers, alf Pierre Vaudrey email [EMAIL PROTECTED]
Cache::Cache issues
Hi,
I've got a bit of an issue with Cache::Cache, and while I know it's a bit
off topic my e-mail to the module maintianer has dissapeared into the
nether regions of nowhere. I know that alot of people here use the module,
especially since it was the cookbook and Perrin's articles that put me onto
the module in the first place.
I can't seem to get the time-out on Cache objects to update, I'm not sure
if it's a bug in Cache::Cache or a bug in my understanding of Cache:Cache's
Cache::Object (much more likely).
I've written a small test script below that show's the issue I'm having.
Any clue's would be helpful.
package TestExpiresAt;
use strict;
use Cache::MemoryCache;
our $Cache = Cache::MemoryCache-new({
'namespace'=__PACKAGE__,
'default_expires_in' = 10,
});
$Cache-set('1', 'Yes', 1800);
$Cache-set('2', 'no');
my $timeout1 = $Cache-get_object('1')-get_expires_at();
my $timeout2 = $Cache-get_object('1')-get_expires_at();
print $timeout1\n; # this should be timeout2 + 1790
print $timeout2\n; # but it's not even different
$Cache-get_object('1')-set_expires_at(10 m);
$timeout1 = $Cache-get_object('1')-get_expires_at();
print $timeout1\n; # should be different again from timeout1 above
print $timeout2\n; # and from timeout 2
1;
__END__
Re: Cache::Cache issues
On Tue, 20 Aug 2002, Chris wrote:
my $timeout1 = $Cache-get_object('1')-get_expires_at();
my $timeout2 = $Cache-get_object('1')-get_expires_at();
... ETOOMUCHCUTNPASTE.
:-)
- ask
--
ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: Mod_perl Application Development
On Sun, 18 Aug 2002, Jonathan Lonsdale wrote: Here's a few approaches I thought of: In a previous life[1] I made a system that was configured like perl my $site1 = new Foo::Site(site = 'www.example.com'); $site1-register_handler( new Foo::ImageHandler(path = '/images/', format = 'png'); ); $site1-register_handler( new Foo::SomeOtherHandler(...); ); ... /perl VirtualHost ... PerlHandler $site1-take_request /VirtualHost (it wasn't quite like that; the site configurations were all in Perl modules dynamically utilizing perl_sections to configure Apache). When running register_handler, the Foo::Site object would call some method on the Handler object to figure out which namespace or which requests it wanted to handle. During take_request it would then just dispatch the right handler. This made it really easy to activate a subsystems when the customer needed them. The system also made it easy to customize the handlers for each customer. (Just inherit the base Foo::BarHandler into Customer::BarHandler and add the extra magic). - ask [1] okay, not quite a previous life; but it is more than 4 years ago. :-) -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Make test failure when installing mod_perl 2.0 on Solaris 8 with Apache 2
Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: ./configure --enable-layout=Solaris --enable-perl=shared --with-mpm=prefork (as normal user) make(as normal user) make test (as root user) make install (as root user) this seems to install fine. I have then configured mod_perl as follows: perl Makefile.PL MP_AP_PREFIX=/usr/apache MP_INST_APACHE2=1 (as normal user) make (as normal user) make test (as root user) And the 'make test' fails: Failed Test Stat Wstat Total Fail Failed List of Failed --- apache/cgihandler.t22 100.00% 1-2 apache/compat.t33 100.00% 1-3 apache/post.t 21 50.00% 2 apache/read.t 11 100.00% 1 apache/scanhdrs.t 29 7424 44 100.00% 1-4 api/send_fd.t 32 66.67% 2-3 api/sendfile.t 32 66.67% 2-3 directive/perlmodule.t 11 100.00% 1 directive/perlrequire.t11 100.00% 1 directive/setupenv.t 31 33.33% 2 filter/input_body.t22 100.00% 1-2 filter/lc.t11 100.00% 1 hooks/access.t 42 50.00% 2-3 hooks/trans.t 33 100.00% 1-3 modperl/getc.t 21 50.00% 2 modperl/readline.t 21 50.00% 2 modperl/sameinterp.t 29 742412 12 100.00% 1-12 modules/include.t 65 83.33% 1 3-6 protocol/echo.t 255 65280 32 66.67% 2-3 protocol/echo_filter.t 255 65280 32 66.67% 2-3 50 tests skipped. So, as you can see not very good. After looking at the recommended log file (t/logs/errorlog) I see the following: bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/home/software/apache _download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/lib/Apach e2 /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apache2 /export/home/software/apache_download_2_0_39/mod_perl -1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/software/apache_down load_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/p rotocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/perlmodule-vh /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irective/main /usr/local/lib/perl5/5.8.0/sun4-so laris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr /local/lib/perl5/site_perl) at (eval 15) line 3. [Tue Aug 20 15:01:20 2002] [error] failed to resolve handler `TestHooks::init::first' [Tue Aug 20 15:01:20 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in INC (INC contains: /export/h ome/software/apache_download_2_0_39/mod_perl-1.99_04/t /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/li b/Apache2 /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/arch/Apac he2 /export/home/software/apache_downl oad_2_0_39/mod_perl-1.99_04/Apache-Test/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/lib /export/home/s oftware/apache_download_2_0_39/mod_perl-1.99_04/blib/lib /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/blib/ arch /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/response /export/home/software/apache_download_2_0_39/m od_perl-1.99_04/t/protocol /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/hooks /export/home/software/apach e_download_2_0_39/mod_perl-1.99_04/t/filter /export/home/software/apache_download_2_0_39/mod_perl-1.99_04/t/htdocs/testd irec
Re: Apache::Session - What goes in session?
--- Perrin Harkins [EMAIL PROTECTED] wrote: There are a few ways to deal with this. The simplest is to use the sticky load-balancing feature that many load-balancers have. Failing that, you can store to a network file system like NFS or CIFS, or use a database. (There are also fancier options with things like Spread, but that's getting a little ahead of the game.) You can use MySQL for caching, and it will probably have similar performance to a networked file system. Unfortunately, the Apache::Session code isn't all that easy to use for this, since it assumes you want to generate IDs for the objects you store rather than passing them in. You could adapt the code from it to suit your needs though. The important thing is to leave out all of the mutually exclusive locking it implements, since a cache is all about get the latest as quick as you can and lost updates are not a problem (last save wins is good enough for a cache). I haven't looked at the cache modules docs yet...would it be possible to build cache on the separate load-balanced machines as we go along...as we do with template caching? By that I mean if an item has cached on machine one then further requests on machine one will come from cache where if on machine two the same item hasn't cached, it will be pulled from the db the first time and then cached? If this isn't possible, I'm not sure if I'll be able to implement any caching or not (some of the site configuration is out of my hands) and everything seems so user specific...I'll definitely reread your posts and go through my app for things that should be cached. I would be curious though that if my choice is simply that the data is stored in the session or comes from the database with each request, would it still be best to essentially only store the session id in the session and pull everything else from the db? It still seems that something trivial like a greeting name (a preference) could go in the session. The relationships to the features and pages differ by user, but there might be general information about the features themselves that is stored in the database and is not user-specific. That could be cached separately, to save some trips to the db for each user. The only thing I can think of right now is a calendar...that should probably be cached. The only gotcha would be that the calendar would need to update every day, at least on the current month's pages. But this is only on a feature page, not a users created page (that is a user can click a link on their daily page that takes them to a feature page where they can go through archives). You can cache the names too if you want to, but keeping them out of the session means that you won't be slowed down by fetching that extra data and de-serializing it with Storable unless the page you're on actually needs it. Even though there are some preset pages, the user can change the names and the user can also create a cutom page with its own name. So there could be thousands of unique page names, many (most) specific to unique users (like Jim's Sports Page, etc.). Not to mention that between the fact that the users' daily pages can have any number of user selected features per page and features themselves can have archive depths of anywhere from 3 to 20 years, there's a lot of info. It's also good to separate things that have to be reliable (like the ID of the current user, since without that you have to send them back to log in again) from things that don't need to be (you could always fetch the list of pages from the db if your cache went down). Very good advice. I've found that occasionally something happens to my session where the sesssion id is ok but some of the other data disapears (like current page id) which really screws things up until you log out and log back in again. This leads me to suspect that I've answered my own question from above. It's just whether I can cache or not. Thanks for all your time and help. __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Make test failure when installing mod_perl 2.0 on Solaris 8 withApache 2
Tom Hibbert wrote: Hi, I am running Solaris 8 and have installed Apache 2: bash-2.03# /usr/apache/bin/httpd -v Server version: Apache/2.0.39 Server built: Aug 20 2002 11:26:54 I also have installed perl 5.8.0: bash-2.03# perl -v This is perl, v5.8.0 built for sun4-solaris I am trying to install mod_perl 2 and I am having problems with the 'make test' command. I have built apache as follows: [...] bash-2.03# more t/logs/error_log END in modperl_extra.pl, pid=29543 [Tue Aug 20 15:01:19 2002] [notice] Apache/2.0.39 (Unix) mod_perl/1.99_04-dev Perl/v5.8.0 configured -- resuming normal oper ations [Tue Aug 20 15:01:19 2002] [info] Server built: Aug 20 2002 11:26:54 [Tue Aug 20 15:01:19 2002] [debug] prefork.c(1035): AcceptMutex: pthread (default: pthread) [Tue Aug 20 15:01:20 2002] [error] Can't locate TestHooks/init/first.pm in Try this patch: Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 20 Aug 2002 15:31:18 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second Base +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first /Base PerlResponseHandler TestHooks::init __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Session - What goes in session?
On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Re: Apache::Session - What goes in session?
We do see some slowdown on our langauge translation db calls since they are so intensive. Moving to a 'per child' cache for each string as it came out of the db sped page loads up from 4.5 seconds to .6-1.0 seconds per page which is significant. Currently we are working on a 'per machine' cache so all children can benefit for each childs initial database read of the translated string, the differential between children is annoying in the 'per child cache' strategy. John- On Tue, 20 Aug 2002 16:33:07 +0100 Tony Bowden [EMAIL PROTECTED] wrote: On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Re: Apache::Session - What goes in session?
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
Currently we are working on a 'per machine' cache so all
children can benefit for each childs initial database read
of the translated string, the differential between
children is annoying in the 'per child cache' strategy.
Sounds like you want BerkeleyDB.pm (not DB_File), which is quite fast and
handles locking/concurrent access internally (when set up properly).
See the Alzabo::ObjectCache::{Store,Sync}::BerkeleyDB modules for
examples.
For Alzabo, I also have a caching system that caches data in a database,
for cross-machine caching/syncing. I haven't really benchmarked it yet
but I imagine it could be a win in some situations. For example, you
could set up the cache as a separate machine running MySQL and still pull
your data from another machine, possibly running a different RDBMS.
-dave
/*==
www.urth.org
we await the New Sun
==*/
apache1.3(win32) - mod_perl 1.27 - activestate - path_info error
Hi, I'm new here so tell me if I'm doing something wrong :)
I posted a report to
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10820 but they said it
seems to be a mod_perl bug.
here goes:
-
If you run the following perl code (on Apache 1.3.2x (win32) - mod_perl
1.27_01-dev - activstate perl build 631/633):
- once with bla/test.pl/xx
- and then bla/test.pl
...the first foreach will have _NO_ PATH_INFO entry
...the hardcoded $ENV{'PATH_INFO'} will have it!!!
...and also the second foreach will have it!!!
The Path_info seems to be cached serverwide. Every time I use a
$ENV{'PATH_INFO'} it has contents even though it shouldn't. The
path_info isn't initialized correctly on win32 (linux apache/mod_perl
doesn't show this behavior).
#!/perl/bin/perl
use strict;
print content-type: text/html\n\n;
print 'htmlbody';
my $val;
foreach my $var (sort(keys(%ENV))) {
$val = $ENV{$var};
$val =~ s|\n|\\n|g;
$val =~ s||\\|g;
print ${var}=\${val}\br;
}
print 'br',$ENV{'PATH_INFO'},'brbr';
foreach my $var (sort(keys(%ENV))) {
$val = $ENV{$var};
$val =~ s|\n|\\n|g;
$val =~ s||\\|g;
print ${var}=\${val}\br;
}
print '/body/html';
what do you think?
cu
Stefan
--
homepage http://my.animeweb.org
Re: Apache::Session - What goes in session?
We are investigating using IPC rather then a file based
structure but its purely investigation at this point.
What are the speed diffs between an IPC cache and a
Berkely DB cache. My gut instinct always screams 'Stay Off
The Disk' but my gut is not always right.. Ok, rarely
right.. ;)
John-
On Tue, 20 Aug 2002 11:49:52 -0500 (CDT)
Dave Rolsky [EMAIL PROTECTED] wrote:
On Tue, 20 Aug 2002 [EMAIL PROTECTED] wrote:
Currently we are working on a 'per machine' cache so all
children can benefit for each childs initial database
read
of the translated string, the differential between
children is annoying in the 'per child cache' strategy.
Sounds like you want BerkeleyDB.pm (not DB_File), which
is quite fast and
handles locking/concurrent access internally (when set up
properly).
See the Alzabo::ObjectCache::{Store,Sync}::BerkeleyDB
modules for
examples.
For Alzabo, I also have a caching system that caches data
in a database,
for cross-machine caching/syncing. I haven't really
benchmarked it yet
but I imagine it could be a win in some situations. For
example, you
could set up the cache as a separate machine running
MySQL and still pull
your data from another machine, possibly running a
different RDBMS.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: Apache::Session - What goes in session?
md wrote:
I haven't looked at the cache modules docs yet...would
it be possible to build cache on the separate
load-balanced machines as we go along...as we do with
template caching?
Of course. However, if a user is sent to a random machine each time you
won't be able to cache anything that a user is allowed to change during
their time on the site, because they could end up on a machine that has
an old cached value for it. Sticky load-balancing or a cluster-wide
cache (which you can update when data changes) deals with this problem.
everything seems so user specific...
That doesn't mean you can't cache it. You can do basically the same
thing you were doing with the session: stuff a hash of user-specific
stuff into the cache. The next time that user sends a request, you
check the cache for data on that user ID (you get the user ID from the
session) and if you don't find any you just fetch it from the db.
Pseudo-code:
sub fetch_user_data {
my $user_id = shift;
my $user_data;
unless ($user_data = fetch_from_cache($user_id)) {
$user_data = fetch_from_db($user_id);
}
return $user_data;
}
I would be curious though that if my choice is simply
that the data is stored in the session or comes from
the database with each request, would it still be best
to essentially only store the session id in the
session and pull everything else from the db? It still
seems that something trivial like a greeting name (a
preference) could go in the session.
Your decision about what to put in the session is not connected to your
decision about what to pull from the db each time. You can cache all
the data if you want to, and still have very little in the session.
This might sound like an academic distinction, but I think it's
important to keep the concepts separate: a session is a place to store
transient state information that is irrelevant as soon as the user logs
out, and a cache is a way of speeding up access to a slow resource like
a database, and the two things should not be confused. You can actually
cache the session data if you need to (with a write-through cache that
updates the backing database as well). A cache will typically be faster
than session storage because it doesn't need to be very reliable and
because you can store and retrieve individual chunks of data (user's
name, page names) when you need them instead of storing and retrieving
everything on every request. Separating these concepts allows you to do
things like migrate the session storage to a transactional database some
day, and move your cache storage to a distributed multicast cache when
someone comes out with a module for that.
The only
gotcha would be that the calendar would need to update
every day, at least on the current month's pages.
The cache modules I mentioned have a concept of timeout so that you
can say cache this for 12 hours and then when it expires you fetch it
again and update the cache for another 12 hours.
Even though there are some preset pages, the user
can change the names and the user can also create a
cutom page with its own name.
No problem, you can cache data that's only useful for a single user, as
I explained above.
Not
to mention that between the fact that the users' daily
pages can have any number of user selected features
per page and features themselves can have archive
depths of anywhere from 3 to 20 years, there's a lot
of info.
No problem, disks are cheap. 400MB of disk space will cost you about as
much as a movie in New York these days.
- Perrin
ANNOUNCE: mod_perl-1.99_05
The URL http://perl.apache.org/dist/mod_perl-1.99_05.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_05.tar.gz size: 577620 bytes md5: ccf3b20a1e48b42750a66c8169cd0a36 Changes since 1.99_04: fix PerlOptions +ParseHeaders to only parse once per-request add external redirects Registry tests [Stas Bekman] get rid of the compat layer in ModPerl-Registry [Stas Bekman] ModPerl::RegistryLoader is now fully operational and tested [Stas Bekman] Registry method handlers are now working [Stas Bekman] core Registry packages all compile the scripts into ModPerl::RegistryROOT:: namespace and cache them in %ModPerl::RegistryCache. Both overridable by the sub-classes. [Stas Bekman] compat tests were split into groups by functionality, send_fd test moved to compat. [Stas Bekman] added $c-get_remote_host and a compat wrapper $r-get_remote_host + tests [Stas Bekman] adjust the build system to support mod_perl build from the source tree. [Stas Bekman] ModPerl::RegistryCooker syncs with mod_perl 1.0's registry: - prototypes defined checks in flush_namespace [Yair Lenga [EMAIL PROTECTED]] - set error-notes on error [Geoff Young [EMAIL PROTECTED]] - preserve status in Registry scripts [Geoff Young [EMAIL PROTECTED]] apr_table_t is now an opaque type, use apr_table_elts() to get the array record [Stas Bekman] add support for redirects with PerlOptions +ParseHeaders backport to 2.0.35 adjust to filter register api change added APR::ThreadMutex module --- Enjoy, -Doug
Re: Apache::Session - What goes in session?
Thanks...you've given me plenty to work with. Great explination. This is good pragmatic stuff to know! __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
Re: Apache::Session - What goes in session?
[EMAIL PROTECTED] wrote: We are investigating using IPC rather then a file based structure but its purely investigation at this point. What are the speed diffs between an IPC cache and a Berkely DB cache. My gut instinct always screams 'Stay Off The Disk' but my gut is not always right.. Ok, rarely right.. ;) Most of the shared memory modules are much slower than Berkeley DB. The fastest option around is IPC::MM, but data you store in that does not persist if you restart the server which is a problem for some. BerkeleyDB (the new one, not DB_File) is also very fast, and other options like Cache::Mmap and Cache::FileCache are much faster than anything based on IPC::Sharelite and the like. I have charts and numbers in my TPC presentation, which I will be putting up soon. - Perrin
Re: Apache::Session - What goes in session?
Thanks, you just saved us a ton of time. Off to change course ;) J On Tue, 20 Aug 2002 13:12:29 -0400 Perrin Harkins [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: We are investigating using IPC rather then a file based structure but its purely investigation at this point. What are the speed diffs between an IPC cache and a Berkely DB cache. My gut instinct always screams 'Stay Off The Disk' but my gut is not always right.. Ok, rarely right.. ;) Most of the shared memory modules are much slower than Berkeley DB. The fastest option around is IPC::MM, but data you store in that does not persist if you restart the server which is a problem for some. BerkeleyDB (the new one, not DB_File) is also very fast, and other options like Cache::Mmap and Cache::FileCache are much faster than anything based on IPC::Sharelite and the like. I have charts and numbers in my TPC presentation, which I will be putting up soon. - Perrin
Module dependency testing question
If module A depends on module B (uses methods or subroutines from module B), is there a good way to test that module A loads module B (i.e. has a use statement)? I frequently run into the following scenario: 1. Write one or more new modules plus a handler that uses them. 2. One or more of those modules is dependent on other existing modules. 3. One of those modules is missing a use statement for one of the existing modules that it makes method/sub calls to. 4. The handler works in the development environment because some other handler loaded that module previously in response to a previous http request. (The brunt of the handler code is require-ed on demand currently). 5. Promote code from development server to production server. 6. Restart apache on production server. 7. Handler fails on production server in response to an access that exercises the section of code where the missing use was needed (i.e.subroutine or method call to module that wasn't loaded). -- Matthew Pressly
Re: Module dependency testing question
Matthew Pressly wrote: If module A depends on module B (uses methods or subroutines from module B), is there a good way to test that module A loads module B (i.e. has a use statement)? I frequently run into the following scenario: 1. Write one or more new modules plus a handler that uses them. 2. One or more of those modules is dependent on other existing modules. 3. One of those modules is missing a use statement for one of the existing modules that it makes method/sub calls to. 4. The handler works in the development environment because some other handler loaded that module previously in response to a previous http request. (The brunt of the handler code is require-ed on demand currently). 5. Promote code from development server to production server. 6. Restart apache on production server. 7. Handler fails on production server in response to an access that exercises the section of code where the missing use was needed (i.e.subroutine or method call to module that wasn't loaded). there are a few things I could suggest (others may have more ideas) - use Apache::Test to write a test suite for your modules. Apache::Test is very easy to use and very convenient. I don't do any more module development without it. - always preload your modules with via PerlModule/startup.pl. if you're missing a use() somewhere the module probably won't load and the server won't start. it's a good idea anyway, for performance reasons. - $ perl -cw MyLib.pm HTH --Geoff
Re: Apache::Session - What goes in session?
Just to jump in here - as I understand it you can split a hash across multiple threads if you preload it before apache forks. So load it in your startup.pl and get it in memory prior to forking. It'll be part of the shared memory since you aren't writing to it. Or at least that's how I understand the theory to work anyway. Josh [EMAIL PROTECTED] 08/20/2002 10:54 AM To: Tony Bowden [EMAIL PROTECTED], md [EMAIL PROTECTED] cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Apache::Session - What goes in session? We do see some slowdown on our langauge translation db calls since they are so intensive. Moving to a 'per child' cache for each string as it came out of the db sped page loads up from 4.5 seconds to .6-1.0 seconds per page which is significant. Currently we are working on a 'per machine' cache so all children can benefit for each childs initial database read of the translated string, the differential between children is annoying in the 'per child cache' strategy. John- On Tue, 20 Aug 2002 16:33:07 +0100 Tony Bowden [EMAIL PROTECTED] wrote: On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Performance issue
Does any body has performance data regarding mod_perl 2.0 vs mod_perl 1.0? What is the stability of mod_perl 2.0? Any body using it in production? thanks.
Re: Apache::Session - What goes in session?
I havent had much luck with that but we will look at it again and see what we can get from it. We want to avoid preloading all data per child direct from the database but I wouldnt mind doing it on startup for the root process and then copying it to each child. J On Tue, 20 Aug 2002 16:39:45 -0500 [EMAIL PROTECTED] wrote: Just to jump in here - as I understand it you can split a hash across multiple threads if you preload it before apache forks. So load it in your startup.pl and get it in memory prior to forking. It'll be part of the shared memory since you aren't writing to it. Or at least that's how I understand the theory to work anyway. Josh [EMAIL PROTECTED] 08/20/2002 10:54 AM To: Tony Bowden [EMAIL PROTECTED], md [EMAIL PROTECTED] cc: Perrin Harkins [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Apache::Session - What goes in session? We do see some slowdown on our langauge translation db calls since they are so intensive. Moving to a 'per child' cache for each string as it came out of the db sped page loads up from 4.5 seconds to .6-1.0 seconds per page which is significant. Currently we are working on a 'per machine' cache so all children can benefit for each childs initial database read of the translated string, the differential between children is annoying in the 'per child cache' strategy. John- On Tue, 20 Aug 2002 16:33:07 +0100 Tony Bowden [EMAIL PROTECTED] wrote: On Mon, Aug 19, 2002 at 06:54:01PM -0700, md wrote: I can definitely get it all from the db, but that doesn't seem very efficient. Don't worry about whether it *seems* efficient. Do it right, and then worry about how to speed that up - if, and only if, it's too slow. Premature optimisation is the root of all evil, and all that .. At BlackStar the session was just a single hashed ID and all other info was loaded from the database every time. We thought about caching some info a few times, but always ran into problems with replication. In the end we discovered that fetching everything from the database on every request wasn't noticeably slower than anything else we could up with, and was a lot more flexible. Throwing more memory at the database servers was usually quicker, cheaper and more effective than micro-optimising our session vs caching strategy... Tony
Re: Apache::Session - What goes in session?
Not in the MS house that I am living in right now :^( On Tue, 20 Aug 2002, Perrin Harkins wrote: Ian Struble wrote: And just to throw one more wrench into the works. You could load up only the most popular data at startup and let the rest of the data get loaded on a cache miss. That is one technique that we have used for some customer session servers. It allowed each server to start up in well under a minute instead of in 15-30 minutes while pegging the DB. The 15-30 minutes was when we were dealing with ~5mil total entries and I would hate to see it now that the size of the table has doubled. Now we just need to do some batch processing to determine what subset gets loaded at startup. You could also just dump the whole thing into a Berkeley DB file every now and then. - Perrin
RE: process priorities and performance
Sorry for the late reply - been away for a bit. Everything I've read as an SA (for Solaris at least - though I would expect the other *nices to be similar) was to never set a user space (non O/S) process to less than -15. Other than that, it's another of those YMMV, measure before and after, and if it helps great. Trying to second guess process schedulers is a tricky business though, and you really need to intimately know how your system behaves before trying it. --Jim -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 06, 2002 9:55 PM To: [EMAIL PROTECTED]; Alexey Zvyagin Subject: process priorities and performance Alexey Zvyagin has suggested a use of Unix process priorities to improve the performance of the web services during the peak hours: Alex writes: - The Unix priorities help to improve perfomance : The MySQL server has a -20 Unix priority: /usr/bin/nice -n -20 /usr/local/bin/safe_mysqld --user=mysql The backend apache server has the -10 priority: /usr/bin/nice -n -10 /usr/local/apache_new/bin/apachectl start /dev/null The frontend apache server has the -5 priority /usr/bin/nice -n -5 /usr/local/accel/bin/apachectl start /dev/null The CPU priorities help to handle an increased traffic on the overloaded server. - Has any of you experimented with this technique and found it useful? If you do we could add the tip to the guide's performance chapter. But we need some meat to have a useful section. Thanks. __ 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
