cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
stas2002/08/21 08:40:17
Modified:xs/APR/PerlIO apr_perlio.c
Log:
- try to go without the dup() in the non-perlio case, leave enough
comments to easily reconstruct the dupping code correctly if that proves
to be wrong.
- add some debug tracing code
Revision ChangesPath
1.23 +24 -7 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.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- apr_perlio.c 21 Aug 2002 04:46:44 - 1.22
+++ apr_perlio.c 21 Aug 2002 15:40:17 - 1.23
-525,15 +525,32
/* convert to the OS representation of file */
rc = apr_os_file_get(os_file, file);
if (rc != APR_SUCCESS) {
-croak(filedes retrieval failed!);
+Perl_croak(aTHX_ filedes retrieval failed!);
}
-
-fd = PerlLIO_dup(os_file);
-/* Perl_warn(aTHX_ fd old: %d, new %d\n, os_file, fd); */
-
-if (!(retval = PerlIO_fdopen(fd, mode))) {
+
+#ifdef PERLIO_APR_DEBUG
+Perl_warn(aTHX_ converting fd %d\n, os_file);
+#endif
+
+/* let's try without the dup, it seems to work fine:
+
+ fd = PerlLIO_dup(os_file);
+ Perl_warn(aTHX_ fd old: %d, new %d\n, os_file, fd);
+ if (!(retval = PerlIO_fdopen(fd, mode))) {
+ ...
+ }
+
+ in any case if we later decide to dup, remember to:
+
+ apr_file_close(file);
+
+ after PerlIO_fdopen() or that fh will be leaked
+
+*/
+
+if (!(retval = PerlIO_fdopen(os_file, mode))) {
PerlLIO_close(fd);
-croak(fdopen failed!);
+Perl_croak(aTHX_ fdopen failed!);
}
return retval;
cvs commit: modperl-2.0/xs/APR/PerlIO apr_perlio.c
stas2002/08/21 08:41:29
Modified:xs/APR/PerlIO apr_perlio.c
Log:
similar to the perlio case:
- 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.24 +4 -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.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- apr_perlio.c 21 Aug 2002 15:40:17 - 1.23
+++ apr_perlio.c 21 Aug 2002 15:41:29 - 1.24
-567,11 +567,14
switch (type) {
case APR_PERLIO_HOOK_WRITE:
-IoOFP(GvIOp(gv)) = apr_perlio_apr_file_to_FILE(aTHX_ file, type);
+IoIFP(GvIOp(gv)) = IoOFP(GvIOp(gv)) =
+apr_perlio_apr_file_to_FILE(aTHX_ file, type);
IoFLAGS(GvIOp(gv)) |= IOf_FLUSH;
+IoTYPE(GvIOp(gv)) = IoTYPE_WRONLY;
break;
case APR_PERLIO_HOOK_READ:
IoIFP(GvIOp(gv)) = apr_perlio_apr_file_to_FILE(aTHX_ file, type);
+IoTYPE(GvIOp(gv)) = IoTYPE_RDONLY;
break;
};
Re: process priorities and performance
Jim Helm [EMAIL PROTECTED] wrote: 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. -Original Message- Alexey Zvyagin has suggested a use of Unix process priorities to improve the performance of the web services during the peak hours: Alex writes: - [snip] The CPU priorities help to handle an increased traffic on the overloaded server. - I think the key here is the fact that the system is overloaded/overcommitted. Too many processes are competeing for CPU. Putting my SA hat on, I would say the processes need to be split across multiple pieces of hardware or a new machine needs to replace the current system. That's the only real long-term solution for a system in this state. The priorities as described help set a relative importance between the processes--the front-end is more important than the database with the larger server processes in the middle. This is not unreasonable. But a serious solution to the problem of an overloaded system is to put in more system. The priorities might be helpful for the few minutes/hours/days needed to get the new hardware on the floor. Imho, a web server should be designed for the expected peak normal usage plus a fudge factor thrown in for safety and multiplied by a small integer greater than one for growth (I'm optimistic). Conclusion of my thoughts: putting in a blurb about priorities being able to set relative importance of processes is fine, but don't cast it as a solution (just as swap space is not a solution to constrained memory). It's a bit of a band-aid that can help until the problem can be fixed. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
installing mod_perl on binar
hi guys, how can i install mod_perl under a pre-installed Apache 2 binary installation? all what i found through docs is installing via source copies. thanks -- Hytham Shehab
Re: Apache::Session - What goes in session?
On Tue, 20 Aug 2002 [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.. ;) IPC (for many definitions of that) has all sorts of odd limitations and isn't that fast. Don't go there. The disk is usually much faster than you think. Often overlooked for caching is a simple file based cache. Here's a story about that: A while ago Graham Barr and I spend some time going through a number of iterations for a self cleaning cache system. It would take lots of writes and fewer reads. In each cache entry a number of integers would be stored. Just storing the last thousand entries would be enough. We tried quite a few different approaches; the most noteworthy was a system of semaphores to control access to a number of slots in a BerkeleyDB. That should be pretty fast, right? It got a bit complicated as our systems didn't support that many semaphores, so we had to come up with a system for sharing the semaphores across multiple slots in the database. Designing and writing this implementation took a few days. It was really cool. Anyway, after fixing that and a few deadlocks we were benchmarking away. The system was so clever. We thought it was simple and neat. Okay, neat at least. And it was really slow. Slow. (~200 writes a second on a 400MHz Pentium II if I recall correctly). First we suspected we did something wrong with the semaphores, but further benchmarking showed that the BerkeleyDB just wasn't that fast for writing. 30 minutes thinking and 30 minutes typing code later we had a prototype for a simple filebased system. Now using good old Fcntl to control access to simple flat files. (Data serialized with pack(N*, ...); I don't think anything beats pack and unpack for serializing data). The expiration went into the data and purging the cache was a simple cronjob to find files older than a few minutes and deleting them. The performance? I don't remember the exact figure, but it was at least several times faster than the BerkeleyDB system. And *much* simpler. The morale of the story: Flat files rock! ;-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: installing mod_perl on binar
Hytham Shehab wrote: hi guys, how can i install mod_perl under a pre-installed Apache 2 binary installation? all what i found through docs is installing via source copies. You don't say what platform you are on. On Unix it's all the same, just skip the build/installation of the Apache stage. On win32 I don't know, probably the same too. __ 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: installing mod_perl on binar
On Wed, 21 Aug 2002, Stas Bekman wrote: Hytham Shehab wrote: hi guys, how can i install mod_perl under a pre-installed Apache 2 binary installation? all what i found through docs is installing via source copies. You don't say what platform you are on. On Unix it's all the same, just skip the build/installation of the Apache stage. On win32 I don't know, probably the same too. If it's ActivePerl Win32, one can also use the ppm utility to install a mod_perl-2 ppm package - this is described in the Win32 section of the docs. As always with binary packages, though, one should ensure the apache binary version matches that which mod_perl-2 was compiled under. -- best regards, randy
$r-path_info() getting confused
In my conf file, I have the following directives: Location /rms AuthType Apache::AuthCookieRMSDBI AuthName RMS PerlAuthenHandler Apache::AuthCookieRMSDBI-authenticate PerlAuthzHandler Apache::AuthCookieRMSDBI-authorize require valid-user /Location Location /rms/module SetHandler perl-script PerlHandler RMS::Control::Module-handler /Location When I call the URL /rms/module/foo, and in RMS::Control::Module-handler I examine $r-path_info, I get as a value '/module/foo' rather than the expected '/foo'. If apache recognized that /rms/module/foo was to go to RMS::Control::Module-handler then it knows that /rms/module is the script name and thus should know that path_info should be just /foo, right? Thanks, Fran
Re: installing mod_perl on binar
hi guys, while am using activeperl on XP, i have installed mod_perl v1.27_01-dev using ppm, but after getting the whole thing, some script runs and offer me to create apache/modules/, when i answere with yes, it bail out upnormally, telling me 'something' i didn't figure out about mod_perl.so, then i have tried to get this file from the normal tar.gz, but no good. in few words, it seems that i have a mod_perl module, but it is not complete/functioning correctly. thx v.much guys. -- Hytham Shehab
Re: $r-path_info() getting confused
Fran Fabrizio wrote: In my conf file, I have the following directives: Location /rms AuthType Apache::AuthCookieRMSDBI AuthName RMS PerlAuthenHandler Apache::AuthCookieRMSDBI-authenticate PerlAuthzHandler Apache::AuthCookieRMSDBI-authorize require valid-user /Location Location /rms/module SetHandler perl-script PerlHandler RMS::Control::Module-handler /Location When I call the URL /rms/module/foo, and in RMS::Control::Module-handler I examine $r-path_info, I get as a value '/module/foo' rather than the expected '/foo'. If apache recognized that /rms/module/foo was to go to RMS::Control::Module-handler then it knows that /rms/module is the script name and thus should know that path_info should be just /foo, right? we illustrate this in the cookbook on pp 156-157. I'm not exactly sure why this happens internally, but its an Apache thing and not a mod_perl thing. An Alias directive will probably set things straight for you. --Geoff
Re: $r-path_info() getting confused
* Fran Fabrizio [EMAIL PROTECTED] [2002-08-21 11:03]: Location /rms /Location Location /rms/module /Location When I call the URL /rms/module/foo, and in RMS::Control::Module-handler I examine $r-path_info, I get as a value '/module/foo' rather than the expected '/foo'. If apache recognized that /rms/module/foo was to go to RMS::Control::Module-handler then it knows that /rms/module is the script name and thus should know that path_info should be just /foo, right? I would hazard a guess that /rms exists under the document root, but /rms/modules does not. How path_info is created has more to do with what the filesystem looks like than what the Location blocks look like. (darren) -- What is ideology but the rationalisation of a vested interest?
Re: Apache::Session - What goes in session?
On 21 Aug 2002 at 2:09, Ask Bjoern Hansen wrote: Now using good old Fcntl to control access to simple flat files. (Data serialized with pack(N*, ...); I don't think anything beats pack and unpack for serializing data). The expiration went into the data and purging the cache was a simple cronjob to find files older than a few minutes and deleting them. The performance? I don't remember the exact figure, but it was at least several times faster than the BerkeleyDB system. And *much* simpler. The morale of the story: Flat files rock! ;-) If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Peter --- Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick
RE: Apache::Session - What goes in session?
Hi Peter -- The morale of the story: Flat files rock! ;-) If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Unlikely. Even with cached database connections you are probably not going to beat the performance of going to a flat text file. Accessing files is something the OS is optimized to do. The process of issuing a SQL query, having it parsed and retrieving results is probably more time-consuming than you think. One way to think about it is this: MySQL stores its data in files. There are many layers of code between DBI and those files, each of which add processing time. Going directly to files is far less code, and less code is most often faster code. The best way to be cure is to benchmark the difference yourself. Try out the Benchmark module. Quantitative data trumps anecdotal data every time. Warmest regards, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: installing mod_perl on binar
On Wed, 21 Aug 2002, Hytham Shehab wrote: hi guys, while am using activeperl on XP, i have installed mod_perl v1.27_01-dev using ppm, but after getting the whole thing, some script runs and offer me to create apache/modules/, when i answere with yes, it bail out upnormally, telling me 'something' i didn't figure out about mod_perl.so, then i have tried to get this file from the normal tar.gz, but no good. in few words, it seems that i have a mod_perl module, but it is not complete/functioning correctly. It sounds like the script to install mod_perl.so into your Apache modules/ directory failed. You could either try installing it again via ppm, and when prompted give the complete path to your Apache modules/ directory, or else just get mod_perl.tar.gz from http://theoryx5.uwinnipeg.ca/ppmpackages/x86/ and unpack it, upon which mod_perl.so appears in the top-level directory - you can then move it manually to the Apache modules/ directory. -- best regards, randy kobes
Re: Apache::Session - What goes in session?
Jesse Erlbaum [EMAIL PROTECTED] wrote: Hi Peter -- The morale of the story: Flat files rock! ;-) If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Unlikely. Even with cached database connections you are probably not going to beat the performance of going to a flat text file. Accessing files is something the OS is optimized to do. The process of issuing a SQL query, having it parsed and retrieving results is probably more time-consuming than you think. All depends on the file structure. A linear search through a thousand records can be slower than a binary search through a million (500 ave. compares vs. about 20 max [10 ave.] compares - hope the extra overhead for the binary search is worth the savings in comparisons). One way to think about it is this: MySQL stores its data in files. There are many layers of code between DBI and those files, each of which add processing time. Going directly to files is far less code, and less code is most often faster code. MySQL also stores indices. As soon as you start having to store data in files and maintain indices, you might as well start using a database. The best way to be cure is to benchmark the difference yourself. Try out the Benchmark module. Quantitative data trumps anecdotal data every time. Definitely. But before you do, make sure the proper indices are created on the MySQL side. Wrong database configurations can kill any performance gain. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
[mp1.2x] Intermittent code execution errors
[This is an update from my earlier posting which was entitled
mod_perl has Alzheimers?. Since then I've read through the
mod_perl guide, searched the mailing list archives, and done a
more thorough job of analyzing the debug output.]
I recently got a new server for our website, and installed RH7.2 on
it and shipped it off to the colo. Since then, I've been getting
lots of 404 server errors, so I added debugging code to the stacked
content handler (a modified version of Apache::NavBar).
Here's the debug output from a good process. There are snippets of
code down below so that you can understand the flow. The code itself is
attached to the email.
NavGraphics(30165): conf_file = /etc/httpd/etc/Sunset6.template
NavGraphics(30165) time=1025358762
NavGraphics(30165): exists
NavGraphics(30165): plate not cached
NavGraphics(30165): plate
NavGraphics(30165): before new
NavPlate(30165): new /etc/httpd/etc/Sunset6.template
NavPlate(30165): after fh
NavPlate(30165) ref: Text::Template
NavGraphics(30165): after new Apache::NavGraphics::NavTemplate=HASH(0x8270b7c)
NavGraphics plate(30165): Text::Template
30165:/home/httpd/html/index.html:Text::Template:
The handler sees that it's cache is empty (it was just spawned), so it
calls new to create a new entry in the cache, which calls new for
Text::Template to get the templating object. The template object is
returned to the handler and information from the page is used to
populate the object.
Here's the debug output from a newly spawned bad child.
Graphics(30166): conf_file = /etc/httpd/etc/Sunset6.template
NavGraphics(30166) time=1025358762
NavGraphics(30166): exists
NavGraphics(30166): plate not cached
NavGraphics(30166): plate
NavGraphics(30166): before new
NavGraphics(30166): after new Apache::NavGraphics::NavTemplate=HASH(0x82689a4)
NavGraphics plate(30166):
30166:/home/httpd/html/Ministries/index.html::
[Thu Aug 1 10:27:18 2002] [error] Can't call method fill_in without a package or
object reference at /usr/lib/perl5/site_perl/5.6.1/Apache/NavGraphics.pm line 48.
This is similar to the good child, except notice that there's no
output from the templating object code (which was prefaced NavPlate).
However, something is placed into the cache and is returned to the
handler, but it isn't a Text::Template object.
Here's the debug output from a bad child on it's second request:
NavGraphics(30166): conf_file = /etc/httpd/etc/Sunset6.template
NavGraphics(30166) time=1025358762
NavGraphics(30166): exists 1
NavGraphics(30166): plate not cached
NavGraphics(30166): plate Apache::NavGraphics::NavTemplate=HASH(0x8268adc)
NavGraphics(30166): before new Apache::NavGraphics::NavTemplate=HASH(0x8268adc)
NavGraphics(30166): after new Apache::NavGraphics::NavTemplate=HASH(0x82688a8)
NavGraphics plate(30166):
30166:/home/httpd/html/Web/WebPolicy.html::
[Thu Aug 1 11:03:41 2002] [error] Can't call method fill_in without a package or
object reference at /usr/lib/perl5/site_perl/5.6.1/Apache/NavGraphics.pm line 48.
As above, except now the object is cached. However, the caching code
correctly determines that the cache doesn't contain a Text::Template
object and tries to create a new object. However, it fails. There's
no debug output from the new method, and whatever is created by new
doesn't contain a Text::Template object. Interestingly though,
something different from last time is returned, which indicates that
the call to new did something. And if you print out what it did
return, you find the text of the template instead of the template
object.
As a stopgap, I tried making a second call to new if the first call to
new failed to return a Text::Template object, it also fails with no
debugging output so it appears that no calls to new will work in a
bad child process.
Here's the relevant sections of code from the module:
##The PRINT method for the Apache::OutputChain handler
sub PRINT {
my $self = shift;
my $r = $self-[0];
my $bar = load_nav($r);
my $plate = load_plate($r);
local $_ = join '', _;
my ($header, $content);
($header,$content) = m#HEAD(.+)/HEAD.*BODY.*?(.+)/BODY#si;
my $thash = {
'left_nav_java'= $bar-java,
'header' = $header,
'navigation_table' = $bar-table,
'content' = $content
};
warn join ':', $$, $r-filename, ref($plate), \n;
if (ref($plate) ne 'Text::Template') {
warn join '', NavGraphics($$) PRINT: , $plate, \n;
}
my $result = $plate-fill_in(HASH = $thash);
if (defined $result) {
$self-Apache::OutputChain::PRINT($result);
}
else {
warn ERROR: $Text::Template::ERROR\n;
}
return OK;
}
##The template object caching subroutine
##Note the warn statements and their order
sub load_plate {
my ($r) = _;
my $conf_file = $r-server_root_relative($r-dir_config('MyTemplate'));
my $mod_time;
if (-e $conf_file) {
$mod_time = (stat _)[9];
}
else {
$conf_file = '';
$mod_time = 0;
}
Re: [mp1.2x] Intermittent code execution errors
On Wed, Aug 21, 2002 at 10:55:35AM -0700, Colin Kuskie wrote: [This is an update from my earlier posting which was entitled mod_perl has Alzheimers?. Since then I've read through the mod_perl guide, searched the mailing list archives, and done a more thorough job of analyzing the debug output.] I forgot to attach the perl code. Colin Kuskie Apache-NavGraphics-1.2.tar.gz Description: application/tar-gz
RE: Apache::Session - What goes in session?
Hey James -- One way to think about it is this: MySQL stores its data in files. There are many layers of code between DBI and those files, each of which add processing time. Going directly to files is far less code, and less code is most often faster code. MySQL also stores indices. As soon as you start having to store data in files and maintain indices, you might as well start using a database. You bring up a really important point: Scale. If a custom file-based data storage system starts growing in both size and functionality it will sooner or latter reach a point where it is a far worse solution. Relational databases are optimized for two things: Ease of access and management of large data sets. If the data set is small and the functional requirements are very narrow then a custom system can outperform a database most of the time (not including poorly written systems!). Once you have to deal with large amounts of data, or you need to have an interface which allows customizable retrieval of sub-sets of data (a la SQL), a database is going to be the way to go. The trick is knowing which path to choose. Having an idea of the potential growth of the system and use of the data, combined with a few well chosen benchmarks come in handy here. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
WebSphere and mod_perl
Has anyone run mod_perl apps on websphere yet? --Jon R.
core on signal in multithread env
I have inherited a solution made up of an HP w/apache 1.3.26 and modperl 1.3.?? config. The modperl makes some C calls. One of the C calls spawns 2 pthreads. Seems when the apache process gets a signal to terminate it cores upon exit. If I do not spawn the two threads things seem much more stable. i even made sure the 2 pthreads mask out all signals. (I have to spawn these threads, it was just a test). The odd thing is that stack trace in the core shows that the main thread (1), is now one of the spawned threads, and the main thread is thread 3. I actually have one core where 2 threads stack traces go up to main. Seems apache is hijacking threads and strange things are going on. Any ideas? Are there certain things i should know or do in this multi-threaded env or is it not supported? Here is the stack of thread 3 of the core: #0 0xc01ecb88 in kill () from /usr/lib/libc.2 #1 0x179254 in sig_coredump (sig=10) at http_main.c:3081 #2 signal handler called #3 0xc0175160 in free () from /usr/lib/libc.2 #4 0x1e3d70 in Perl_safesysfree () #5 0x1c1a40 in perl_destruct () #6 0x632b8 in perl_shutdown (s=0x400640b8, p=0x409dec58) at mod_perl.c:294 #7 0x684a8 in perl_child_exit (s=0x400640b8, p=0x409dec58) at mod_perl.c:958 #8 0x67cfc in perl_child_exit_cleanup (data=0x409dee00 \006@\270\235\354X@\235\356) at mod_perl.c:926 #9 0x15cf14 in run_cleanups (c=0x409dee08) at alloc.c:1713 #10 0x15a060 in ap_clear_pool (a=0x409dec58) at alloc.c:538 #11 0x15a190 in ap_destroy_pool (a=0x409dec58) at alloc.c:568 #12 0x175690 in clean_child_exit (code=0) at http_main.c:512 #13 0x1792dc in just_die (sig=1) at http_main.c:3109 #14 signal handler called
ld warnings for Symbol already exported or Exported symbol not defined during make for server
I run into these warnings during the make on the apache-1.3.26: ld: 0711-415 WARNING: Symbol perl_alloc is already exported. ld: 0711-415 WARNING: Symbol Perl_amagic_call is already exported. .. ld: 0711-319 WARNING: Exported symbol not defined: perl_module ld: 0711-319 WARNING: Exported symbol not defined: mod_perl_sent_header .. The same warnings seem to reoccur though out the make on the Apache were it concerns *.exp files for perl or mod_perl. The httpd created seems to work fine. Perl modules are loading, I did the Apache::Hello from Writing Apache Modules with Perl and C with success. Make test on mod_perl reported nothing bad. So I'm wondering if the items above are bad?, and the mod_perl only 'kinda' works. System OS: AIX 4.3.3 Perl: *this had the 5.6.1 fix for AIX concerning the native dlopen. Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=aix, osvers=4.3.3.0, archname=aix uname='aix sbctss 3 4 000200554c00 ' config_args='' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -DUSE_NATIVE_DLOPEN -q32 -D_LARGE_FILES -qlonglong', optimize='-O', cppflags='-D_ALL_SOURCE -D_ANSI_C_SOURCE -D_POSIX_SOURCE -qmaxmem=16384 -DUSE_NATIVE_DLOPEN -q32 -D_LARGE_FILES -qlonglong' ccversion='4.4.0.3', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='ld', ldflags ='-brtl -b32' libpth=/lib /usr/lib /usr/ccs/lib libs=-lbind -lnsl -ldbm -ldl -lld -lm -lc -lcrypt -lbsd -lPW -liconv perllibs=-lbind -lnsl -ldl -lld -lm -lc -lcrypt -lbsd -lPW -liconv libc=/lib/libc.a, so=a, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_aix.xs, dlext=so, d_dlsymun=undef, ccdlflags='-bE:/usr/opt/perl5/lib/5.6.1/aix/CORE/perl.exp -bE:/usr/opt/perl5/lib/5.6.1/aix/CORE/perl.exp' cccdlflags=' ', lddlflags='-bhalt:4 -bM:SRE -bI:$(PERL_INC)/perl.exp -bE:$(BASEEXT).exp -b noentry -lc' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under aix Compiled at Mar 5 2002 14:17:17 @INC: /usr/opt/perl5/lib/5.6.1/aix /usr/opt/perl5/lib/5.6.1 /usr/opt/perl5/lib/site_perl/5.6.1/aix /usr/opt/perl5/lib/site_perl/5.6.1 /usr/opt/perl5/lib/site_perl . The option options were: perl Makefile.PL APACHE_SRC=../apache-1.3.26/src \ NO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 apache was: configure --prefix=/apache2 \ --activate-module=src/modules/perl/libperl.a \ --activate-module=src/modules/php/libphp4.a \ --enable-module=ststus \ --enable-module=so Thanks in advance! Todd E. O'Dell Network Services - TSS Staff Room 1118 500 E. 8th Kansas City, MO 64106 Office: (816)275-3626 Alpha Page: [EMAIL PROTECTED] [EMAIL PROTECTED]
LWP::Simple::get gets slower and slower
I have noticed something extremely baffling. We use the get() function of LWP::Simple within mod_perl scripts, and it seems for long running servers, it gets slower and slower. I have two servers here that would consistently take 8 seconds to process a get() call, when getting the same URL using the GET command would take about a second (very fast remote server). And the extra 8 second would show up for pretty much any URL regardless of the script. The really baffling part is that doing a soft restart of apache (apachectl restart) did not take care of the problem, but doing a hard restart (apachectl stop apachectl start) will make the performance go back to normal. I don't know how long a server has to run in order for this issue to surface, it might be months, since we only noticed this lately and we don't typically hard restart production servers on a regular basis. Anybody else noticed something like this? -Mathieu
Re: Apache::Session - What goes in session?
Ask Bjoern Hansen wrote: The performance? I don't remember the exact figure, but it was at least several times faster than the BerkeleyDB system. And *much* simpler. In my benchmarks, recent versions of BerkeleyDB, used with the BerkeleyDB module and allowed to manage their own locking, beat all available flat-file modules. It may be possible to improve the flat-file ones, but it even beat Tie::TextDir which is about as simple (and therefore fast) as they come. The only thing that did better was IPC::MM. - Perrin
Re: Apache::Session - What goes in session?
Peter J. Schoenster wrote: If I'm using Apache::DBI so I have a persistent connection to MySQL, would it not be faster to simply use a table in MySQL? Probably not, if the MySQL server is on a separate machine. If it's on the same machine, it would be close. Remember, MySQL has more work to do (parse SQL statement, make query plan, etc.) than a simple hash-based system like BerkeleyDB does. Best thing would be to benchmark it though. - Perrin
Re: installing mod_perl on binar
hi, i have installed the mod_perl at last, and the mod_perl.so is there at apache/modules, *BUT*: apache -k restart -- Syntax error on line 136 of c:/program files/apache group/apache/conf/httpd.conf: Cannot load c:/program files/apache group/apache/modules/mod_actions.so into server: (126) The specified module could not be found: line 136 was: LoadModule access_module modules/mod_access.so# it is there, but ? so i changed it to: LoadModule access_module C:\Program Files\Apache Group\apache\modules\mod_access.so# nothing good, yet. so, i say this mod_access.so may be doomed or something, so i comment its line to see other good *.so #LoadModule access_module modules/mod_access.so# it is there, but ? LoadModule alias_module modules/mod_alias.so Syntax error on line 137 of c:/program files/apache group/apache/conf/httpd.conf: Cannot load c:/program files/apache group/apache/modules/mod_alias.so into server: (126) The specified module could not be found: so i decide to see some wizard like Mr.Randy Kobes to figure out what is this damn curse is all about? :-) thx v.much -- Hytham Shehab
Re: NTLM module
All works fine for IE and Mozilla browsers but when I use Netscape, I am repeatedly promted for passwords. If I enter my password about 3 to 6 times I will eventually get the full page . If I enter password once, ( and cancel for any further password prompts ) I get only bit of the expected page. Maybe the requested files are in different directories? Normaly the browser will only send back the username/password to the same a or child directory. The other aspect I can not understand is that when the perl NTLM module is running, it will often exit from sub's other than the handler sub. ie the handler sub is always called first which calls other sub's but whilst executing these other sub''s , it appears that something seems to cut processing short passes control back to apache - the perl code never gets a chance to return to the handler module exit code with a 'return xx'. Apache has a timeout, so maybe you hit that and Apache itself kill your handler The other error I get is that the username/password is passed ok from the SMB server verification phase, but then in subsequent calls to the SMB server, the username/password fails - this occurs during the one entry of username/password but the SMB server is contacted several times for verification ( I also check the username password in the script before thay are submitted to the SMB server so I know they are correct.) Would this be because of timeout in the SMB to respond. Somebodyelese also reported this and I currently debugging it. It maybe releated to some problems of the underlying C library. I let you know when it is fixed. I would also expect the SMB server to only need to referred to once, but the perl module is calling the SMB module 3 times during the one username/password entry. Yes, as I said before it's a challange response cycle is taking place, which takes 3 steps Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: installing mod_perl on binar
On Thu, 22 Aug 2002, Hytham Shehab wrote: hi, i have installed the mod_perl at last, and the mod_perl.so is there at apache/modules, *BUT*: apache -k restart -- Syntax error on line 136 of c:/program files/apache group/apache/conf/httpd.conf: Cannot load c:/program files/apache group/apache/modules/mod_actions.so into server: (126) The specified module could not be found: line 136 was: LoadModule access_module modules/mod_access.so# it is there, but ? so i changed it to: LoadModule access_module C:\Program Files\Apache Group\apache\modules\mod_access.so# nothing good, yet. so, i say this mod_access.so may be doomed or something, so i comment its line to see other good *.so #LoadModule access_module modules/mod_access.so# it is there, but ? LoadModule alias_module modules/mod_alias.so Syntax error on line 137 of c:/program files/apache group/apache/conf/httpd.conf: Cannot load c:/program files/apache group/apache/modules/mod_alias.so into server: (126) The specified module could not be found: This sounds like a problem with a bad install of apache's default configuration file. Which apache version are you using? For apache-1.3.26, mod_alias.so and mod_actions.so (and others) are compiled into Apache.exe, which you can see via 'Apache.exe -l'. So the LoadModule directive for these modules isn't relevant - use it only for those that appear in the apache modules/ directory. -- best regards, randy kobes
