Re: dbm locking info in the guide
Stas Bekman wrote: > So basically what you are saying is that sync() is broken and shouldn't be > used at all. Something fishy is going on. The purpose of sync() is to > flush the modifications to the disk. Saving changes to disk isn't the problem. The issue is that some of the database gets cached in memory when you open the database (even if you don't actually read anything from it), so changes made in other processes will not be seen. To get around this, you would have to somehow reload the cached data from disk just after getting a write lock but before making any changes. > Unless you are talking about a process that wants to read after some other > process had changed the database, and there is a hazard that the former > process has the data cached and will not know that dbm has been modified. Exactly. Keeping the database open is fine as long as you have a read-only app. For read/write, you have to tie/untie every time. Or use BerkeleyDB. - Perrin
Re: [OT] ApacheCon BOF
On Mon, 19 Mar 2001, Drew Taylor wrote: > snip.. > won't be there this year. Speaking of which, will the mod_perl classes have > the handouts available over the web? > i know doug's been updating his: http://perl.apache.org/~dougm/modperl_2.0.html sterling
Re: please help with perl script
thank you Mr Boyle for the help. i have been able to
gain access to the directory, but i still cannot get
any HTML output from the script. the browser just
hangs when i try to access it. i figure the problem
might have to do with the code, and i was wondering if
anyone could help me debug. the script takes an INFILE
which i have created in the same directory and after
processing the file it goes into a sleep mode for 1
minute. somehow no HTML output is piped out. here is
what the script looks like:
should i remove the infinite loop construct to stop
the hang? please help
===
#!/usr/bin/perl
#test4.pl
# Number of Sample points to make running average of
is supplied as a command line argumnt
$num_samples= 15;
# Set minimum and maximum to arbitrarily high and low
values respectively
$min_temp = 100.0;
$max_temp = -100.0;
@minimum=split(/ +/,localtime());
$min_temp_time=$minimum[3];
$min_temp_date=$minimum[1]." ".$minimum[2];
@maximum=split(/ +/,localtime());
$max_temp_time=$maximum[3];
$max_temp_date=$maximum[1]." ".$maximum[2];
# Infinite Loop to run as a daemon
for(;;)
{
# Open temperature.dat for input (contains
$num_samples lines of the format
# temperature Tue 28 00:00:00 2001
open(INFILE,";
close(INFILE);
# $num_lines contains number of lines in the file
$num_lines=@inputs;
# Check to see if the number of lines is greater than
number of sample points to average over
if ($num_lines >= $num_samples)
{
# If true then average over the temperature field and
also find the minimum and maximum values for
temperature.
# Initialize counter,sum and average
$counter = 1;
$sum = 0.0;
$average = 0.0;
while($counter <= $num_samples)
{
# Split each element of input array on whitespace
@data = split(/ +/,$inputs[$num_lines-$counter]);
# Extract the first field as temperature
$temperature = $data[0];
$data_time = $data[4];
$data_date= $data[2]." ".$data[3];
if ($data_date ne $min_temp_date)
{
$min_temp_date=$data_date;
$min_temp=$temperature;
$min_temp_time=$data[4];
$max_temp_date=$data_date;
$max_temp=$temperature;
$max_temp_time=$data[4];
}
# Find the minimum and maximum temperature of
num_sample points
if ($temperature < $min_temp)
{ $min_temp = $temperature;
$min_temp_time=$data_time;
$min_temp_date=$data_date;
}
if ($temperature > $max_temp)
{ $max_temp = $temperature;
$max_temp_time=$data_time;
$max_temp_date=$data_date;
}
$sum += $temperature;
$counter++;
}
# Compute average
$average = $sum/($counter-1);
$current_time=localtime;
print <<"Tempstuff";
Content-type: text/html
Weather
TEMPERATURE
DATA
Average Temperature for
the past $num_samples
minutes: $average
Tempstuff
}
else
{
sleep(1*60);
}
# End of If $numlines < $numsamples condition
sleep(1*60);
}
===
--- Owen Boyle <[EMAIL PROTECTED]> wrote:
> Keletso Mokgethi wrote:
> > i am a novice trying to run a perl script on
> apache
>
> > i created
> > a directory under httpd called "perl" in which i
> > stored the script. according to redhat's linux 6.2
> > apache/ssl documentation, mod_perl is ready to run
> > once the server is launced and there is no need
> for
> > any changes in httpd.conf
>
> Hold it right there! If you created a directory, you
> had better tell
> apache about it - for that you *need* to edit
> httpd.conf... let's
> proceed.
>
> > hoping to run the script i entered the URL:
> > http://localhost/perl/Read_dat.perl/
> >
> > and got the reponse: Forbidden
> >
> > "you don't have permission to access
> > /perl/Read_dat.perl/ on this server.
>
> There are a few reasons why you might get this... In
> short, apache has
> to be able to find the program and access to the
> directory has to be
> "allowed".
>
> Before doing anything else, look in httpd.conf until
> you find the
> ErrorLog directive, then find the file it is
> pointing to and tail that
> file while you run your prog to see what errors you
> are getting ($ tail
> -f /home/apache/logs/error_log)
>
> Back to the problem: I think you are trying to run
> your script using the
> Apache::Registry. To do this:
>
> - let's assume your ServerRoot is "/home/apache"
> - check mod-perl is compiled into apache ($
> /home/apache/bin/httpd -l
> and look for mod_perl)
> - put your script in /home/apache/perl (already
> done)
> - check it is executable ($ chmod +x Read_dat.perl)
> - its first output has to be the script-header
> (print "Content-type:
> text/html\n\n"; - NB note the two "\n").
> - in httpd.conf, you need the following
>
> # this "allows"
> apache into the directory
> Allow from all
>
>
> Alias /perl/ /home/apache/perl/ # this lets it find
> the script
> # this tells it
> what to do
> Se
RE: dbm locking info in the guide
On Tue, 20 Mar 2001, David Harris wrote: > > Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: > > I think you'll still have problems with this technique, unless you > > tie/untie every time. I'm looking at the perldoc for DB_File version > > 1.76, at the section titled "Locking: the trouble with fd". At the very > > least, you'd have to call sync after acquiring a write lock but before > > writing anything. > > Here is more information from the original discovery of the bug. This > contains the test cases that actually show the database corruption. Also > some documentation on the details such as systraces that show reading > happens before the flock system call. > >http://www.davideous.com/misc/dblockflaw-1.2.tar.gz >http://www.davideous.com/misc/dblockflaw-1.2/ > > Sync may or may not work, depending on how the low level buffering is > implemented. So basically what you are saying is that sync() is broken and shouldn't be used at all. Something fishy is going on. The purpose of sync() is to flush the modifications to the disk. > If it re-reads all information from disk I don't think you have > any advantage over simply closing the DB_File and opening it again. Why should it re-read the file, when it's suppose to *write* it down to the disk. That's the benefit of using dbm, is that only some blocks of the file are read into a memory. Unless you are talking about a process that wants to read after some other process had changed the database, and there is a hazard that the former process has the data cached and will not know that dbm has been modified. > It's also worthwhile to use an external lock file because that properly > locks for database creation. That's for sure. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Perrin Harkins wrote: > On Wed, 21 Mar 2001, Stas Bekman wrote: > > > You mean with DB_File? There's a big warning in the current version > > > saying not to do that, because there is some initial buffering that > > > happens when opening a database. > > > > The warning says not to lock on dbm fd but an external file! > > I think you'll still have problems with this technique, unless you > tie/untie every time. I'm looking at the perldoc for DB_File version > 1.76, at the section titled "Locking: the trouble with fd". At the very > least, you'd have to call sync after acquiring a write lock but before > writing anything. Of course, you always call sync. The sync was always there, even with the flawed locking scheme. The DB_File doc was updated as a follow up of the research done by David Harris. This should work: flock SH tie() read... flock EX <= start critical section write... sync() flock SH <= end critical section read... untie() flock UN notice that the locking is done on the *external* file (or fd). The only problem in this approach is a possible writing starvation as explained: http://perl.apache.org/guide/dbm.html#Locking_dbm_Handlers_and_Write_L _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: dbm locking info in the guide
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: > I think you'll still have problems with this technique, unless you > tie/untie every time. I'm looking at the perldoc for DB_File version > 1.76, at the section titled "Locking: the trouble with fd". At the very > least, you'd have to call sync after acquiring a write lock but before > writing anything. Here is more information from the original discovery of the bug. This contains the test cases that actually show the database corruption. Also some documentation on the details such as systraces that show reading happens before the flock system call. http://www.davideous.com/misc/dblockflaw-1.2.tar.gz http://www.davideous.com/misc/dblockflaw-1.2/ Sync may or may not work, depending on how the low level buffering is implemented. If it re-reads all information from disk I don't think you have any advantage over simply closing the DB_File and opening it again. It's also worthwhile to use an external lock file because that properly locks for database creation. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
Re: understanding memory via ps -ely | grep http
On Tue, 20 Mar 2001, Tim Gardner wrote: > I have been trying to reduce/tune the memory requirements of an > online game which uses mod_perl (Apache::Registry). I have read the > suggestions at http://perl.apache.org/tuning/ and am trying to follow > them. The first suggestion is to preload the modules by including > > Perlrequire /var/www/perllib/startup.perl > > in httpd.conf and then in startup.perl doing: > > #! /usr/local/bin/perl > use strict; > use lib "/var/www/perllib"; > use Apache::DBI (); > use mymodules (); > 1; > > According to the web page: > >What this does is pull in all of the code used by the programs (but > >does not import any of the module methods) into the main HTTPD > >process, which then creates the child processes with the code > >already in place. > > I have been monitoring memory usage with the command: > ps -ely | grep http > > and getting output that looks something like this. > > S UID PID PPID C PRI NI RSS SZWCHAN TTY TIME CMD > S 1003 318 1 0 40 18 4432 40960? ?4:37 cshttpd > S 1003 345 318 0 40 18 3320 40920? ?0:02 cshttpd > S 0 2835 1 0 41 20 8776 10344? ?0:34 httpd > S 60001 4895 2835 0 41 20 13272 18872? ?0:06 httpd > S 60001 4894 2835 0 41 20 13280 18872? ?0:07 httpd > > I understand that the RSS is the resident size in KB and the SZ > column is the size of the process, but what should I be seeing in the > way of reduced memory? The 13MB/18MB is not much different from when > I don't preload anything. Should I be seeing something else? I > probably am not understanding what to look for. Any suggestions or > observations would be appreciated. You want to read the first sections of: http://perl.apache.org/guide/performance.html particularly: http://perl.apache.org/guide/performance.html#Know_Your_Operating_System _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
On Wed, 21 Mar 2001, Stas Bekman wrote: > > You mean with DB_File? There's a big warning in the current version > > saying not to do that, because there is some initial buffering that > > happens when opening a database. > > The warning says not to lock on dbm fd but an external file! I think you'll still have problems with this technique, unless you tie/untie every time. I'm looking at the perldoc for DB_File version 1.76, at the section titled "Locking: the trouble with fd". At the very least, you'd have to call sync after acquiring a write lock but before writing anything. - Perrin
RE: no-cache headers?
On Tue, 20 Mar 2001, Geoffrey Young wrote:
> > For normally generated response use:
> >
> > $r->header_out("Pragma","no-cache");
> > $r->header_out("Cache-control","no-cache");
> > $r->no_cache(1);
>
> $r->no_cache(1) sets these headers for you - no need to set them yourself.
>
> >
> > If for some reason you need to use them in Error control code
> > (i.e. when sending some non-2xx response code) use:
> >
> > $r->err_header_out("Pragma","no-cache");
> > $r->err_header_out("Cache-control","no-cache");
> > $r->no_cache(1);
>
> I don't think this is necessary
>
> http://archive.covalent.net/perl/dev/2000/09/0042.xml
In fact it's well covered in here:
http://perl.apache.org/guide/correct_headers.html
Sometimes I myself get lost in all the amount of information the guide
includes... so I've removed this duplication section. Andreas Koenig's doc
is the right one to stick too.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
JOBS with CNET.com in Illinois
CNET is hiring in Itasca Illinois Let me introduce myself, my name is sean lally and I am the Director of Corporate Recruiting for CNET in San Francisco. We now have 11 positions open in Itasca. Here are the positions I hope to tempt you with: Director IT-IS Data Manager SR Software Engineer Software Engineer (2 positions) Associate Engineer Sys/Network Administrator Support Engineer (Q/A) Support Engineer Technical Support (2 positions) Required skills for the software engineering and support positions include strong Linux or Unix with extensive Perl experience. SQL and OO experience a significant plus. Experience developing or maintaining ASP products or services is also beneficial. We have an established team in Itasca of twenty people that we are expanding. These are all new positions. If anyone would like job descriptions or additional info please let me know. Want info about the Itasca group? See http://www.cnetchannel.com/about.htm sean [EMAIL PROTECTED] Sean Lally Executive Director, Corporate Recruiting CNET Networks Inc http://www.cnet.com/jobs Sean Lally Executive Director, Corporate Recruiting CNET Networks Inc http://www.cnet.com/jobs Sean Lally Executive Director, Corporate Recruiting CNET Networks Inc http://www.cnet.com/jobs
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Perrin Harkins wrote: > On Tue, 20 Mar 2001, Stas Bekman wrote: > > > Is anyone aware of a safe to way to do multi-process read/write access > > > through a dbm module other than BerkeleyDB.pm without tie-ing and > > > untie-ing every time? I thought that was the only safe thing to do > > > because of buffering issues, but this seems to be implying that careful > > > use of sync calls or something similar would do the trick. Maybe this is > > > just left over from before the problem with the old technique described in > > > the DB_File docs was discovered? Any comments? > > > > Well, I wrote this based on my experience. I've used the code that does > > locking coupled with sync() and it worked fine. > > You mean with DB_File? There's a big warning in the current version > saying not to do that, because there is some initial buffering that > happens when opening a database. The warning says not to lock on dbm fd but an external file! That's where the problem happens. http://perl.apache.org/guide/dbm.html#Flawed_Locking_Methods_Which_Mus If you lock before you tie, and flush before you untie (or change the lock type), it should be safe. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Joshua Chamas wrote: > I know the tie/untie MLDBM::Sync strategy with DB_File is > slow, but what size data are you caching? I'm not. Well, actually I am, but I use BerkeleyDB which handles its own locking. I just noticed this in the Guide and figured that either it was out of date or I missed something interesting. > It may be that you can use MLDBM::Sync with SDBM_File, with records < > 100 bytes would be good, or MLDBM::Sync with MLDBM::Sync::SDBM_File > which faster through around 5000-1 byte records with > Compress::Zlib installed. Generally, the tie/untie with a SDBM_File > is pretty fast. I'll update the Guide to mention your module in the dbm section. - Perrin
Re: notes() from registry->php->registry
Ahh. Thanks much.
darren chamberlain wrote:
>
>
> Nor should it be. You need to set the note in the subrequest, or
> access the parent's notes table.
>
> Try replacing the first piece with:
>
> my $subr = $r->lookup_uri('test.php3');
> $subr->notes('seen' => $seen);
> $subr->run;
>
> And the note "seen" will be present. You can't, as far as I know,
> access the parent request from a PHP script, just like you can't
> for normal CGI scripts that are run as subrequests. That's just a
> limitation of the model, and probably a good reason to rewrite
> the whole piece in mod_perl, by the way.
>
> (darren)
--
Daniel Bohling
Re: dbm locking info in the guide
Perrin Harkins wrote: > > Is anyone aware of a safe to way to do multi-process read/write access > through a dbm module other than BerkeleyDB.pm without tie-ing and > untie-ing every time? I thought that was the only safe thing to do > because of buffering issues, but this seems to be implying that careful > use of sync calls or something similar would do the trick. Maybe this is > just left over from before the problem with the old technique described in > the DB_File docs was discovered? Any comments? > I don't know how to do it safely, which is why I do the tie/untie in MLDBM::Sync in a locked critical section. I know the tie/untie MLDBM::Sync strategy with DB_File is slow, but what size data are you caching? It may be that you can use MLDBM::Sync with SDBM_File, with records < 100 bytes would be good, or MLDBM::Sync with MLDBM::Sync::SDBM_File which faster through around 5000-1 byte records with Compress::Zlib installed. Generally, the tie/untie with a SDBM_File is pretty fast. Otherwise, DeWitt Clinton's Cache::Cache might also do it for you, as the file based cache is probably faster than DB_File with tie/untie per access for large records. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: [OT] ApacheCon BOF shirts
> "Dave" == Dave Rolsky <[EMAIL PROTECTED]> writes: Dave> So as not to be a total spoilsport, I would like to point out that I Dave> thought Randal's idea (Mcmod_perl?) was rather clever and I think it'd be Dave> cool (though I don't know if there are trademark issues). Remember. It's a Parody. Safe harbor. 2 Live Crew bought us that (or was it some other rap-ish group... I can't recall). And it wouldn't be "mc". Just the golden m. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: understanding memory via ps -ely | grep http
On Tue, 20 Mar 2001, Tim Gardner wrote: > I understand that the RSS is the resident size in KB and the SZ > column is the size of the process, but what should I be seeing in the > way of reduced memory? The 13MB/18MB is not much different from when > I don't preload anything. Should I be seeing something else? You have to look at SHARE. Subtract SHARE from RSS. - Perrin
RE: [OT] ApacheCon BOF
> -Original Message- > From: Dave Rolsky [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 3:19 PM > To: Geoffrey Young > Cc: '[EMAIL PROTECTED]' > Subject: RE: [OT] ApacheCon BOF > > > On Tue, 20 Mar 2001, Geoffrey Young wrote: > > > > If you get a really good artist, put the lamp/bottle into > the hands of > > > a well-built Native American figure (a warrior-type is > great, but an > > > "indian princess" has subliminal appealok, ok, but > think about it, > > > lol!) > > > > I think the graphics house we'll be using is pretty capable :) > > I for one would appreciate a design that doesn't fetishize a > culture and > people that have already had enough abuse at the hands of 'American' > people. > > Can we please keep the design more focused on technology and > geekiness? fair enough. don't know if you got my latest response, but looking at it I was probably not as sensitive to the issue as I should have been... my apologies in advance. --Geoff > > > -dave > > /*== > www.urth.org > We await the New Sun > ==*/ > >
Re: [OT] ApacheCon BOF
> "Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes: Geoffrey> sorry Randal - I guess I just found it so funny that I Geoffrey> didn't think you were really serious about it (I saw the big Geoffrey> glowing M and nearly snarfed my coffee :) As a professional comedian, I *demand* that my name may or may not be Randal. No, no, I demand that my jokes be treated with RESPECT! :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
RE: [OT] ApacheCon BOF
On Tue, 20 Mar 2001, Geoffrey Young wrote: > > If you get a really good artist, put the lamp/bottle into the hands of > > a well-built Native American figure (a warrior-type is great, but an > > "indian princess" has subliminal appealok, ok, but think about it, > > lol!) > > I think the graphics house we'll be using is pretty capable :) I for one would appreciate a design that doesn't fetishize a culture and people that have already had enough abuse at the hands of 'American' people. Can we please keep the design more focused on technology and geekiness? -dave /*== www.urth.org We await the New Sun ==*/
RE: [OT] ApacheCon BOF
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 2:59 PM > To: Geoffrey Young > Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > Subject: Re: [OT] ApacheCon BOF > > > > "Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes: > > >> > still need more suggestions for a theme that aren't > tongue-in-cheek, > >> > >> lol! Why, I thought that was the idea!!! > > Geoffrey> well, of course - but much folly leaves the list > innundated with (albeit > Geoffrey> funny) postings but not much for me to work with... > > Geoffrey> (it's all Randall's fault ;) > > I actually was seriously suggesting mine. You didn't specify any > design criterion that would rule mine out. What was wrong with mine? > > /me feels hurt that his idea wasn't taken seriously... sorry Randal - I guess I just found it so funny that I didn't think you were really serious about it (I saw the big glowing M and nearly snarfed my coffee :) actually, we may have a winner with the Native American and lamp idea. A coworker suggested a peace pipe (picture an indian smoking perl) instead of a lamp, since you don't see warriors holding lamps often. maybe some smoke signals? if anyone out there can suggest some mod_perl code (obfuscated or not) that could go in the smoke that would be great... --Geoff
RE: [OT] ApacheCon BOF
On Tue, 20 Mar 2001, Dave Rolsky wrote: > On Tue, 20 Mar 2001, Geoffrey Young wrote: > > > > If you get a really good artist, put the lamp/bottle into the hands of > > > a well-built Native American figure (a warrior-type is great, but an > > > "indian princess" has subliminal appealok, ok, but think about it, > > > lol!) > > > > I for one would appreciate a design that doesn't fetishize a culture > and people that have already had enough abuse at the hands of > 'American' people. > Hear, hear. Personally I find the very name Apache a little uncomfortabl. I get the joke about it being a patchy server (although now the ratio of original NCSA code to `new' code is so miniscule as to invalidate the patch theme anyway, imho), but the relevance of an http server to the Apache nation escapes me (and the symbolizing of the Apache nation with a feather strikes me as stereotypical at best). > Can we please keep the design more focused on technology and geekiness? I concur wholeheartedly. -- nick
[OT] FileHandle and forking
I've encounted what I believe to be an error in either a) FileHandle.pm, b) Perl, or c) Linux 2.2.17. I'm writing a bulkmailer (for legitimate resons). I dump all the emails to a file sorted by domain. My parent process begins reading the file and forks a "domain processor" whenever it encounter a '--mlm:', which seperates the domains. The domain processor then begins reading where the parent stopped, since it in herited the parents filehandle. Meanwhile the parent process beings looking for the next '--mlm:' line. This is where the error occurs... The "domain processor", which is reading the data from the filehandle line by line, seems to skip 2048, 4096, or 8192 bytes at seemingly random intervals. I think that when I fork, I'm getting a copy of the file descriptor, but not a copy of the buffer. Then, when my parent process moves on to the next 2k, 4k, or 8k block, the kernel cleans up that memory even though my "domain processor" is still reading from it. I'd think that this would cause a core dump, but I'm not seeing any core files and my exit codes all look clean. Does anyone have any suggestions as to what might be the problem? In the short term, I will open a new file handle within the "domain processor" and use tell and seek which should work just as well... Thanks, Rob -- Warning: The contents of this message are made of bits which may or may not be an accurate representation of my thoughts.
RE: book recommendations?
Paul, You certainly are correct about the book being a bit dated. But it is still a great reference, especially for beginners. Even with the book you still must read the perldocs. -- Dave Davisson [EMAIL PROTECTED] > -Original Message- > From: Paul Evad [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 9:40 AM > To: [EMAIL PROTECTED] > Subject: book recommendations? > > > I know a lot of the good O'Rielly books are showing some age (1999 > publishing date). Anyone out there have a copy of "Writing Apache > Modules with Perl and C", is it still relevant enough with the > current apache mod_perl distro's to be worthwhile getting? > > Suggestions on good reference books to get? (I have most of the Perl > library already). > > - paul > -- > > - Kudosnet Technologies Inc. - > Support: [EMAIL PROTECTED] > Accounts: [EMAIL PROTECTED] > Sales: [EMAIL PROTECTED] > 1-877-885-8367 --
Re: Problem with Tie::DBI and DBI in modperl
On Tue, 20 Mar 2001, John Mulkerin wrote: > There is no error message returned, it just goes back to the httpd 403 > error screen. What about in the error log? Have you read the DBI docs on how to get your error message to print? You should either have RaiseError on or be checking return codes from every DBI call. If you haven't turned PrintError off, DBI will issue a warning that goes to your log when it fails to connect. - Perrin
Re: book recommendations?
Paul Evad <[EMAIL PROTECTED]> writes: > I know a lot of the good O'Rielly books are showing some age (1999 > publishing date). Anyone out there have a copy of "Writing Apache > Modules with Perl and C", is it still relevant enough with the > current apache mod_perl distro's to be worthwhile getting? Absolutely. > > Suggestions on good reference books to get? (I have most of the Perl > library already). Effective Perl Damian Conway's Object Oriented Perl Data Munging in Perl -- Dave Hodgkinson, http://www.hodgkinson.org Editor-in-chief, The Highway Star http://www.deep-purple.com Interim CTO, web server farms, technical strategy
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Stas Bekman wrote: > > Is anyone aware of a safe to way to do multi-process read/write access > > through a dbm module other than BerkeleyDB.pm without tie-ing and > > untie-ing every time? I thought that was the only safe thing to do > > because of buffering issues, but this seems to be implying that careful > > use of sync calls or something similar would do the trick. Maybe this is > > just left over from before the problem with the old technique described in > > the DB_File docs was discovered? Any comments? > > Well, I wrote this based on my experience. I've used the code that does > locking coupled with sync() and it worked fine. You mean with DB_File? There's a big warning in the current version saying not to do that, because there is some initial buffering that happens when opening a database. - Perrin
[OT] ApacheCon BOF shirts
So as not to be a total spoilsport, I would like to point out that I thought Randal's idea (Mcmod_perl?) was rather clever and I think it'd be cool (though I don't know if there are trademark issues). -dave /*== www.urth.org We await the New Sun ==*/
Re: book recommendations?
Paul Evad wrote: > I know a lot of the good O'Rielly books are showing some age (1999 > publishing date). Anyone out there have a copy of "Writing Apache > Modules with Perl and C", is it still relevant enough with the > current apache mod_perl distro's to be worthwhile getting? Yeah, it still mostly is. Apache 2.0 and the accompanying mod_perl 2.0 will be a whole new ball of wax though, but they're not here yet anyway (hey Doug, going to make a second edition for 2.0 I hope?). It's a great book. I found the O'Reilly mod_perl quick reference booklet quite useful at time. Easy to carry around, packed with all the information (no fluff or explanation, like the man pages), useful. -- "Whip me. Beat me. Make me maintain AIX." -- Stephan Zielinski
Re: book recommendations?
> Suggestions on good reference books to get? (I have most of the Perl > library already). Diving into mod_perl with this new job of mine was certinaly made much easier with 'Apache modules with perl / C' ... I'd pick it up for reference at the very least. _Thomas - This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/
Re: notes() from registry->php->registry
daniel ([EMAIL PROTECTED]) said something to this effect on 03/19/2001:
> hello all,
>
> i've got a registry script that issues a subrequest for a php page that
> issues a subrequest on another registry script.
>
> registry->php->registry
>
> the initial registry script sets:
>
> $r->notes("seen"=> $seen);
> my $subr = $r->lookup_uri("test.php3");
> $subr->run;
*snip*
>
> The note is not available in the php or subsequent subrequests.
> If the subrequest is for another registry script the note works fine.
Nor should it be. You need to set the note in the subrequest, or
access the parent's notes table.
Try replacing the first piece with:
my $subr = $r->lookup_uri('test.php3');
$subr->notes('seen' => $seen);
$subr->run;
And the note "seen" will be present. You can't, as far as I know,
access the parent request from a PHP script, just like you can't
for normal CGI scripts that are run as subrequests. That's just a
limitation of the model, and probably a good reason to rewrite
the whole piece in mod_perl, by the way.
(darren)
--
It is wrong always, everywhere and for everyone to believe anything upon
insufficient evidence.
-- W. K. Clifford
Re: [OT] ApacheCon BOF
> "Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes: >> > still need more suggestions for a theme that aren't tongue-in-cheek, >> >> lol! Why, I thought that was the idea!!! Geoffrey> well, of course - but much folly leaves the list innundated with (albeit Geoffrey> funny) postings but not much for me to work with... Geoffrey> (it's all Randall's fault ;) I actually was seriously suggesting mine. You didn't specify any design criterion that would rule mine out. What was wrong with mine? /me feels hurt that his idea wasn't taken seriously... -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: [OT] ApacheCon BOF
Randal> 42 billion has the right sound to it. It's "the answer", after all, Randal> a billion times over. :) I like it! Maybe a big round pearl with a smiley-face and a headband with feather sticking up in the back with the words "Don't Panic" in large friendly letters printed below :) Ken Creason - [EMAIL PROTECTED] C @,@ Web Development/Server Administration \ -/ Fischer Computer Systems
understanding memory via ps -ely | grep http
I have been trying to reduce/tune the memory requirements of an online game which uses mod_perl (Apache::Registry). I have read the suggestions at http://perl.apache.org/tuning/ and am trying to follow them. The first suggestion is to preload the modules by including Perlrequire /var/www/perllib/startup.perl in httpd.conf and then in startup.perl doing: #! /usr/local/bin/perl use strict; use lib "/var/www/perllib"; use Apache::DBI (); use mymodules (); 1; According to the web page: >What this does is pull in all of the code used by the programs (but >does not import any of the module methods) into the main HTTPD >process, which then creates the child processes with the code >already in place. I have been monitoring memory usage with the command: ps -ely | grep http and getting output that looks something like this. S UID PID PPID C PRI NI RSS SZWCHAN TTY TIME CMD S 1003 318 1 0 40 18 4432 40960? ?4:37 cshttpd S 1003 345 318 0 40 18 3320 40920? ?0:02 cshttpd S 0 2835 1 0 41 20 8776 10344? ?0:34 httpd S 60001 4895 2835 0 41 20 13272 18872? ?0:06 httpd S 60001 4894 2835 0 41 20 13280 18872? ?0:07 httpd I understand that the RSS is the resident size in KB and the SZ column is the size of the process, but what should I be seeing in the way of reduced memory? The 13MB/18MB is not much different from when I don't preload anything. Should I be seeing something else? I probably am not understanding what to look for. Any suggestions or observations would be appreciated. Thanks, Tim
RE: [OT] ApacheCon BOF
> -Original Message- > From: Paul [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 12:58 PM > To: Geoffrey Young > Subject: RE: [OT] ApacheCon BOF > > > > --- Geoffrey Young <[EMAIL PROTECTED]> wrote: > > still need more suggestions for a theme that aren't tongue-in-cheek, > > lol! Why, I thought that was the idea!!! well, of course - but much folly leaves the list innundated with (albeit funny) postings but not much for me to work with... (it's all Randall's fault ;) > > Seriously, though > > How about this: > > A graphis of an old-style oil-lamp or some baroque bottle, with smoke > seeping out into a little cloud. Make the smoke out of > snippets of perl > code, particularly mod_perl/Apache specific calls when possible. I like this whole idea lots... > > If you get a really good artist, put the lamp/bottle into the hands of > a well-built Native American figure (a warrior-type is great, but an > "indian princess" has subliminal appealok, ok, but think about it, > lol!) I think the graphics house we'll be using is pretty capable :) --Geoff > > Worst case, embed the bottle in some sort of "net" graphic. > It could work > > __ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ >
RE: no-cache headers?
> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 11:44 AM
> To: mod_perl list
> Subject: no-cache headers?
>
>
> I've a note in the guide to check the correctness of the following
> section. I have these 2 questions:
>
> 1. Should all three headers be always sent?
> 2. Should $r->no_cache(1) be used for non-2xx responses?
>
> Thanks!
>
> =head1 Cache Control for Regular and Error Modes
>
> To disable the client response caching these HTTP headers should be
> used:
>
> Pragma: no-cache
> Cache-control: no-cache
> Expires: Wed, 21 Mar 2001 00:28:13 GMT
>
> where the I field is set to the same date and time as the
> original request.
>
> For normally generated response use:
>
> $r->header_out("Pragma","no-cache");
> $r->header_out("Cache-control","no-cache");
> $r->no_cache(1);
$r->no_cache(1) sets these headers for you - no need to set them yourself.
>
> If for some reason you need to use them in Error control code
> (i.e. when sending some non-2xx response code) use:
>
> $r->err_header_out("Pragma","no-cache");
> $r->err_header_out("Cache-control","no-cache");
> $r->no_cache(1);
I don't think this is necessary
http://archive.covalent.net/perl/dev/2000/09/0042.xml
--Geoff
>
>
>
>
> _
> Stas Bekman JAm_pH -- Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
>
>
book recommendations?
I know a lot of the good O'Rielly books are showing some age (1999 publishing date). Anyone out there have a copy of "Writing Apache Modules with Perl and C", is it still relevant enough with the current apache mod_perl distro's to be worthwhile getting? Suggestions on good reference books to get? (I have most of the Perl library already). - paul -- - Kudosnet Technologies Inc. - Support: [EMAIL PROTECTED] Accounts: [EMAIL PROTECTED] Sales: [EMAIL PROTECTED] 1-877-885-8367 --
Re: perl5.6 (was: Shared variables, inner subs and "our")
Unfortunately it is a requirement for this project. We need to parse utf8 XML and munge other XML using that data. I seem to have everything working now although I had to fix some stuff in XML::DOM. --Jauder On Sun, 18 Mar 2001, Bogomolnyi Constantin wrote: > Hi , > Unicode is a way of pain . don't go this way . > specialy in 5.7.0 were it is broken . > 5.6.0 is well you know what . > There is many other systems to hold multilingual apps , that not require any > unicode . > > I use 5.7.0 in production (i386 , BSD 4.2) and it runs perfectly . Except > unicode > support. 5.6.0 has a lot of bugs (witch were fixed in 5.7.0) > > Best > Cb > > - Original Message - > From: "Jauder Ho" <[EMAIL PROTECTED]> > To: "Bogomolnyi Constantin" <[EMAIL PROTECTED]> > Sent: Monday, March 19, 2001 8:44 AM > Subject: Re: perl5.6 (was: Shared variables, inner subs and "our") > > > > > > Hello there, could you detail a little more about your Unicode experience > > with perl? I am currently evaluating what the best verion of perl to use > > for a multilingual application. Thanks. > > > > --Jauder > > > > On Fri, 16 Mar 2001, Bogomolnyi Constantin wrote: > > > > > Hi , > > > > > > You should probably try 5.7.0 witch is much more stable than 5.6.0 (you > > > should not try unicode stuff , whitch is quite buggy) > > > > > > I use 5.7.0 on all my production servers without any problems . > > > > > > Best > > > - Original Message - > > > From: "Wim Kerkhoff" <[EMAIL PROTECTED]> > > > To: "modperl" <[EMAIL PROTECTED]> > > > Sent: Saturday, March 17, 2001 6:20 AM > > > Subject: Re: perl5.6 (was: Shared variables, inner subs and "our") > > > > > > > > > > Stas Bekman wrote: > > > > > > > > > our() and other perl5.6 new APIs are too early to be endorsed, as > 5.6 is > > > > > not yet considered as a stable version for mod_perl production > sites, > > > > > therefore the guide barely touches on it. > > > > > > > > Would you recommend the use of perl5.6 with mod_perl? What you are > > > > saying is making me queasy. > > > > > > > > I'm asking because I've been having bad luck with Apache::Session and > > > > some other modules in some mod_perl aware applications. Things aren't > > > > comming out the data source properly, things are hanging, things > aren't > > > > locking/unlocking properly, etc. It could well be that the > applications > > > > I'm working with aren't using Sessions, Tie::Cache, etc properly. I > may > > > > downgrade to perl5.005 and give that a whirl... > > > > > > > > -- > > > > > > > > Regards, > > > > > > > > Wim Kerkhoff > > > > > > > > > > > > > >
[ANNOUNCE] Cache-Cache-0.05
Summary:
The Perl Cache package provides Cache::Cache, a generic interface
for creating persistent data stores. This interface is implemented
by the Cache::MemoryCache, Cache::SharedMemoryCache, Cache::FileCache,
Cache::SizeAwareFileCache, Cache::SizeAwareMemoryCache, and
Cache::SizeAwareSharedMemoryCache classes. This work replaces
File::Cache and IPC::Cache.
Release Notes:
This release replaces IPC::Shareable with IPC::ShareLite as the
backend for the SharedMemoryCache and updates external module
dependencies to the latest versions.
Project Homepage:
http://sourceforge.net/projects/perl-cache/
Tar/GZ:
http://ftp1.sourceforge.net/perl-cache/Cache-Cache-0.05.tar.gz
Changelog:
http://sourceforge.net/project/shownotes.php?release_id=27936
CVS tree (cvsweb):
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi?cvsroot=perl-cache
The following is the Cache-Cache-0.05 README file:
Copyright (C) 2001 DeWitt Clinton All Rights Reserved
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 1, or (at your option)
any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
NAME
Cache::Cache
DESCRIPTION
The Perl Cache package provides Cache::Cache, a generic interface
for creating persistent data stores. This interface is implemented
by the Cache::MemoryCache, Cache::SharedMemoryCache, Cache::FileCache,
Cache::SizeAwareFileCache, Cache::SizeAwareMemoryCache, and
Cache::SizeAwareSharedMemoryCache classes. This work replaces
File::Cache and IPC::Cache.
REQUIREMENTS
Digest::MD5
File::Spec
File::Path
IPC::ShareLite
Storable
INSTALLATION
perl Makefile.PL
make
make test
make install
USAGE
First, choose the best type of cache implementation for your needs.
The simplest cache is the MemoryCache, which is suitable for
applications that are serving multiple sequential requests, and
which to avoid making redundant expensive queries, such as an
Apache/mod_perl application talking to a database. If you wish to
share that data between processes, then perhaps the
SharedMemoryCache is appropriate, although its behavior is tightly
bound to the underlying IPC mechanism, which varies from system to
system, and is unsuitable for large objects or large numbers of
objects. When the SharedMemoryCache is not acceptable, then
FileCache offers all of the same functionality with similar
performance metrics, and it is not limited in terms of the number of
objects or their size. If you wish to maintain a strict limit on
the size of a file system based cache, then the SizeAwareFileCache
is the way to go. Similarly, the SizeAwareMemoryCache and the
SizeAwareSharedMemoryCache add size management functionality
to the MemoryCache and SharedMemoryCache classes respectively.
Using a cache is simple. Here is some sample code for instantiating
and using a MemoryCache:
use Cache::Cache qw( $EXPIRES_NEVER $EXPIRES_NOW );
use Cache::MemoryCache;
my $options_hash_ref = { 'default_expires_in' => '10 seconds' };
my $cache = new Cache::MemoryCache( $options_hash_ref );
my $expires_in = '10 minutes';
$cache->set( 'Key', 'Value', $expires_in );
# if the next line is called within 10 minutes, then this
# will return the cache value
my $value = $cache->get( 'Key' );
Please refer to the perldoc for Cache::Cache and the related
implementations for complete documentation.
SEE ALSO
File::Cache and IPC::Cache
AUTHOR
Original author: DeWitt Clinton <[EMAIL PROTECTED]>
Last author: $Author: dclinton $
Copyright (C) 2001 DeWitt Clinton
Re: [OT] ApacheCon BOF
Hi ( 01.03.20 10:36 -0500 ) Geoffrey Young: > still need more suggestions for a theme that aren't tongue-in-cheek, > though :) But those are the best ones! And puns and other word play are a part of perl culture! Also, just for my information, who decides on the theme and how do they do it? -- \js The teacher was discussing the creation of the world, Adam & Eve and their expulsion from the paradise. At the end of the class the teacher asks: "So students, Can you tell me who were Adam & Eve ?". One student answered: "They were russians". "Why ?" asked the teacher. "Because they didn't have clothes, house or car and they thought they were in paradise".
no-cache headers?
I've a note in the guide to check the correctness of the following
section. I have these 2 questions:
1. Should all three headers be always sent?
2. Should $r->no_cache(1) be used for non-2xx responses?
Thanks!
=head1 Cache Control for Regular and Error Modes
To disable the client response caching these HTTP headers should be
used:
Pragma: no-cache
Cache-control: no-cache
Expires: Wed, 21 Mar 2001 00:28:13 GMT
where the I field is set to the same date and time as the
original request.
For normally generated response use:
$r->header_out("Pragma","no-cache");
$r->header_out("Cache-control","no-cache");
$r->no_cache(1);
If for some reason you need to use them in Error control code
(i.e. when sending some non-2xx response code) use:
$r->err_header_out("Pragma","no-cache");
$r->err_header_out("Cache-control","no-cache");
$r->no_cache(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://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT]Re: my()speed (was: [DIGEST] mod_perl digest 03/17/01)
[the benchmark snipped] > What can we conclude from all of this? That Lexicals and globals run > at (roughly) the same speed, and that tmtowtdi... ... but that doesn't mean that we should endorse using globals. This would probably be different if globals were significantly faster. Fortunately this is not the case... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: [OT] ApacheCon BOF
> It would also be easy enough to upload the artwork from last year. I'd use the same artwork, but change mod_perl to mod_perl 2.0. Alas, with all the latest development Doug has done for mod_perl 2.0, it seems that the release of Apache 2.0 will be the main show stopper. So let's keep the folks on the cutting edge... Anyway, Doug rules!!! Oh, we can also ask Doug to pose enface with a snowboard and notebook for the artwork :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT]Re: my()speed (was: [DIGEST] mod_perl digest 03/17/01)
At 11:27 AM +0800 3/20/01, Stas Bekman wrote:
>On Mon, 19 Mar 2001, Paul wrote:
>
>>
>> --- Geoffrey Young <[EMAIL PROTECTED]> wrote:
>> > mod_perl digest
>> >March 11, 2001 - March 17, 2001
>> > Recent happenings in the mod_perl world...
>> > . . .
>> > mailing list highlights
>> > . . .
>> > o There was an OT but interesting thread on whether lexical
>> > variables are faster than global variables [10]. This
>> > response in particular may be of interest to those who
>> > want to know more about perlguts [11]
>>
>> As one more installment on that thread, I got an email using Benchmark
>> to test it. It had the my() inside the test function, which was slower
>> than package globals, but I moved it out and it was faster.
>>
>> Here's the test synopsis:
>> ===
>> C:\users\default>type tmp.pl
> > use Benchmark;
>> my $o; # packagewide deep-bound my() var
>> sub outMY{
>> $o = 0; # packagewide deep-bound my() var
>> $o++ while ($o < 1000);
>> };
>> sub inMY{
>> my $i = 0; # function-internal my() var
>> $i++ while ($i < 1000);
>> };
>> sub gPK{
>> $g = 0; # package global var
>> $g++ while ($g < 1000);
>> };
>> timethese(5000, { 'External' => \&outMY,
>> 'Internal' => \&inMY,
> > 'Global' => \&gPK} );
>>
>> C:\users\default>perl -w tmp.pl
>> Benchmark: timing 5000 iterations of External, Global, Internal...
>> External: 5 wallclock secs ( 4.96 usr + 0.00 sys = 4.96 CPU)
>> Global: 5 wallclock secs ( 5.01 usr + 0.00 sys = 5.01 CPU)
>> Internal: 4 wallclock secs ( 5.07 usr + 0.00 sys = 5.07 CPU)
>>
>> ===
>> Notice that a deep-bound my() variable was fastest, while a re-scoped
>> my() was slowest, the package global being pretty close to halfway
>> between in actual CPU usage.
>>
>> Hope that's useful to somebody. =o)
>
>Unfortunately it's not very useful when the results are so close, unless
>you specify the platform, compiler args, which malloc version was used and
>much more. And others use the same or a similar setup.
>
>I've run the same benchmark on linux(k2.2.17), perl 5.6.1-PATCH2 and there
>are all the other details that I'm not telling here. But just to make a
>point, I get results with 'global' always being faster and
>external/internal giving relatively inconsistent results (see the
>variations on CPU cycles). For example, your code executed four times:
>
>[snip]
Normally, a stash in the average program contains hundreds of entries
from different packages. That must have some impact on the speed of
the globals, right?
Well... I tested it (sort of) and created 1000 fake subs to populate
the stash with extra entries.
for my $i (1..1000) {
*{"x$i"} = sub {
print $i."\n";
};
}
Then continued to run the code above with the following results
Benchmark: timing 5000 iterations of External, Global, Internal...
External: 3 wallclock secs ( 3.07 usr + 0.01 sys = 3.08 CPU) @
Global: 3 wallclock secs ( 3.07 usr + 0.00 sys = 3.07 CPU) @
Internal: 4 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @
Benchmark: timing 5000 iterations of External, Global, Internal...
External: 9 wallclock secs ( 3.25 usr + 0.00 sys = 3.25 CPU) @
Global: 6 wallclock secs ( 3.08 usr + 0.01 sys = 3.09 CPU) @
Internal: 3 wallclock secs ( 3.10 usr + 0.00 sys = 3.10 CPU) @
Again, the globals were fastest, even with 1000 extra sybols in the stash.
And then I thought that perhaps the stash was ordered alphanumercally
to improve performance. So I renamed my 1000 subs with a "d$i"
instead of the "x$i" and ran the test again, but I came up with the
exact same numbers...
Then, I tried upping the number of symbols... first to 1 then to
10 and ran again with the EXACT same times.
What can we conclude from all of this? That Lexicals and globals run
at (roughly) the same speed, and that tmtowtdi...
Rob
--
Warning: The contents of this message are made of bits which may or may not
be an accurate representation of my thoughts.
RE: [OT] ApacheCon BOF
> -Original Message- > From: David Harris [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, March 20, 2001 10:24 AM > To: Geoffrey Young; [EMAIL PROTECTED] > Subject: RE: [OT] ApacheCon BOF > > > > Geoffrey Young [mailto:[EMAIL PROTECTED]] wrote: > > o unfortunately, we can't get into the biz of selling any. the > logistics > > of that is just too much. > > What about using a service like www.cafepress.com where you upload the > artwork and they take care of all the logistics: order > taking, payment, > manufacturing, shipping, and customer service. You can > increase your price > over their "base" and donate the money to perl somehow, or > just sell at the > base price. > > It would also be easy enough to upload the artwork from last year. Hi David... yeah, I hadn't heard of this until you and Kenny mentioned it. I asked around - apparently the quality isn't the best. At any rate, we'll probably end up doing this since it doesn't cost anything and gives the sponsor some more eyeballs... still need more suggestions for a theme that aren't tongue-in-cheek, though :) --Geoff > > David Harris > President, DRH Internet Inc. > [EMAIL PROTECTED] > http://www.drh.net/ > >
RE: [OT] ApacheCon BOF
Geoffrey Young [mailto:[EMAIL PROTECTED]] wrote: > o unfortunately, we can't get into the biz of selling any. the logistics > of that is just too much. What about using a service like www.cafepress.com where you upload the artwork and they take care of all the logistics: order taking, payment, manufacturing, shipping, and customer service. You can increase your price over their "base" and donate the money to perl somehow, or just sell at the base price. It would also be easy enough to upload the artwork from last year. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
Re: 1 Billion Bug 1BB - [OT] UNIX timestamp hits 1,000,000,000 thisyear!
At 03:19 AM 3/20/01 -0800, Ask Bjoern Hansen wrote: >On Fri, 9 Mar 2001, Gerd Kortemeyer wrote: > >[bugs and design fu^H^Hchoices waiting to happen] > > > I will open my consulting business on Mon, Jan 18th, 2038. > >funny, I thought we all worked so hard to have a chance of retiring >before that. Yeah all that tech stock I have... :) Later, Gunther
RE: LimitRequestBody
> -Original Message- > From: Victor Michael Blancas [mailto:[EMAIL PROTECTED]] > Sent: Monday, March 19, 2001 10:57 PM > To: [EMAIL PROTECTED] > Subject: LimitRequestBody > > > The httpd documentation says that the default LimitRequestBody > configuration is 0. However, i'm only able to upload files of > size less > than 1.0MB. Any ideas, thanks. any chance that you changed the default behavior of LimitRequestBody at compile time? maybe the read is timing out? There was a thread recently that talked about read timeouts over a proxy server causing problems because the backend was timing out before the proxy (or somesuch)... not much help, but maybe something to chew on? --Geoff > > -- > Mike >
Re: [NQ] Newbie Question about mod_perl
> "Differentiated Software Solutions Pvt. Ltd.," wrote:
> I have written two mod_perl programs whose output is same (through
> browser).
> I want to know what are the difference between them! If there is any
> difference then what are the pros and cons in using both of them?
The second program is taking advantage of the PerlSendHeader feature.
This is mostly a compatibility feature, I would tend to think that it
might be slightly slower (because mod_perl has to watch for the empty
line).
The first program should be a very small amount faster, as far as I
know, but the second has a partial advantage of portability to
non-mod_perl regular CGI environment. I say "partial", because you test
for $ENV{MOD_PERL}, which you don't need to do.
--
"The number of Unix installations has grown to 10, with more expected."
-- The Unix Programmer's Manual, 2nd Edition, June 1972
RE: [OT] ApacheCon BOF
> > o unfortunately, we can't get into the biz of selling any. the logistics >of that is just too much. Maybe using a service like Cafe Press to sell the shirts would work? http://www.cafepress.com/ I know I'd be interested in purchasing a shirt.
Re: Problem with Tie::DBI and DBI in modperl
Searched this list, dbiusers, and a bunch more.I'm not sure if its something so dump it's never discussed or what. There is no error message returned, it just goes back to the httpd 403 error screen. I've added a print statement in the middle of the connect and had it print to the screen and it looks the same rather I'm in Perl or via Mod_perl. Here is the result from the print: "dbi:mysql:its,helpman,secret01,HASH(0xaf798b4)" Looks like it should work, but nothing seems to be returned from the "return DBI->connect($dsn,$user,$password,$options)" statement. John - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "John Mulkerin" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, March 19, 2001 11:34 PM Subject: Re: Problem with Tie::DBI and DBI in modperl > On Mon, 19 Mar 2001, John Mulkerin wrote: > > I'm trying to use the plain vanilla TicketTool.pm from O'Reilly's mod > > perl book, Apache Modules with Perl and C. It uses Tie::DBI to create > > a hash of the mysql connection. When I run just the authentication > > subroutine with Perl -d "authenticate.pm" it runs fine. Whe I run it > > as part of the web server, it fails in the connect statement in the > > Tie:DBI routine. > > What is the exact error message? Have you tried searching the mailing > list archive for that message? Are you using PHP in your server? > > - Perrin >
RE: [OT] ApacheCon BOF
well, thanks everyone for your suggestions (maybe :) I just thought I'd sum up some of the issues that we dealt with last year: o the Eagle and Apache feather are off limits - we didn't get permission to use them last year and don't expect that to change. o the shirt is going to have a corporate sponsor, so we don't want to go dousing MS or whatever which might get them into trouble o while there may be some *cough* friendly competition between perl and ? we don't want to pick on any one particular programming demographic (though they guy who is forking over the $$ loves python and we pick on eachother all the time - that one made me chuckle) o unfortunately, we can't get into the biz of selling any. the logistics of that is just too much. anyway, here is last years image (well almost, the background is skewed in this one, but I couldn't find the actual one). http://morpheus.laserlink.net/~gyoung/apachecon.jpg the image was on the back and the corporate logo on the breast pocket (except there wasn't a pocket). It will probably be some similar arrangement this year (the company has to get its moneys worth :) Keep the ideas coming... thanks all --Geoff
Re: [OT] ApacheCon BOF
On 19 Mar 2001, Randal L. Schwartz wrote: > >> "mod_perl: 20 billion hits served" > >> And turn the "m" into a stylized arch. :) > > Nick> er, maybe 20 trillion ... ? seeing as how ValueClick alone has done a bit > Nick> over 42 billion since 6/98 ... :) > > yeah, I was hoping valueclick would jump out and give me a better number. actually, then it should probably be more like 55 billion[1]. And in the busy hours. we add more 3000 to that. Per second. :) - ask [1] Nick only included numbers from one of the ValueClick divisions running the system with mod_perl. :-) -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
RE: [OT] unsubscribing was Re: Varaible scope & memory under mod_perl
On Wed, 14 Mar 2001, Steven Zhu wrote: [...] > another user (having different user email account). Now I got those emails > from the alias of my original account. If I just send mail to > [EMAIL PROTECTED], I believe that it does not help because [...] well, you could at least have tried. then the friendly mailinglist manager would have replied back within seconds with this message: "To see what address you used to subscribe, look at the messages you are receiving from the mailing list. Each message has your address hidden inside its return path; for example, [EMAIL PROTECTED] receives messages with return path: [EMAIL PROTECTED]" and just to make it really easy the message would also have included specific, easy to follow instructions on how to unsubscribe an alternate address. Cool, huh? - ask (the slightly sarcastic assistant to the friendly mailinglist manager). -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: 1 Billion Bug 1BB - [OT] UNIX timestamp hits 1,000,000,000thisyear!
On Fri, 9 Mar 2001, Gerd Kortemeyer wrote: [bugs and design fu^H^Hchoices waiting to happen] > I will open my consulting business on Mon, Jan 18th, 2038. funny, I thought we all worked so hard to have a chance of retiring before that. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: please help with perl script
Keletso Mokgethi wrote: > i am a novice trying to run a perl script on apache > i created > a directory under httpd called "perl" in which i > stored the script. according to redhat's linux 6.2 > apache/ssl documentation, mod_perl is ready to run > once the server is launced and there is no need for > any changes in httpd.conf Hold it right there! If you created a directory, you had better tell apache about it - for that you *need* to edit httpd.conf... let's proceed. > hoping to run the script i entered the URL: > http://localhost/perl/Read_dat.perl/ > > and got the reponse: Forbidden > > "you don't have permission to access > /perl/Read_dat.perl/ on this server. There are a few reasons why you might get this... In short, apache has to be able to find the program and access to the directory has to be "allowed". Before doing anything else, look in httpd.conf until you find the ErrorLog directive, then find the file it is pointing to and tail that file while you run your prog to see what errors you are getting ($ tail -f /home/apache/logs/error_log) Back to the problem: I think you are trying to run your script using the Apache::Registry. To do this: - let's assume your ServerRoot is "/home/apache" - check mod-perl is compiled into apache ($ /home/apache/bin/httpd -l and look for mod_perl) - put your script in /home/apache/perl (already done) - check it is executable ($ chmod +x Read_dat.perl) - its first output has to be the script-header (print "Content-type: text/html\n\n"; - NB note the two "\n"). - in httpd.conf, you need the following # this "allows" apache into the directory Allow from all Alias /perl/ /home/apache/perl/ # this lets it find the script # this tells it what to do SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI - restart apache - hit the URL; http://localhost/perl/Read_dat.perl By the way, in case you don't actually have mod_perl, bear in mind that you don't need to use mod_perl to get apache to execute a perl program. You can just use plain old-fashioned CGI. A simple configuration that might get you running quicker is: - create a directory /home/apache/cgi and put Read_dat.perl into it - make sure it is executable - its first output has to be the script-header (print "Content-type: text/html\n\n"; - NB note the two "\n"). - in httpd.conf: Allow from all DocumentRoot /home/apache/html ScriptAlias /cgi /home/apache/cgi - restart apache - hit the URL; http://localhost/cgi/Read_dat.perl Now you should get some output. Check the error_log to see if anything goes wrong (this will log apache-level errors). If you need to debug your program, switch on script-logging: ScriptLog logs/script_log and this will log STDERR from the script. best regards, Owen Boyle.
