Re: Email (mod_perl) Apache module?
On Fri Dec 15 11:28:03 2000 -0800 brian moseley wrote: On Fri, 15 Dec 2000, Perrin Harkins wrote: Is there a reason you don't want to just hack on WING? It's a pretty powerful system and it was designed for mod_perl. Look it up on CPAN. it's an option, but it's got a large amount of dependencies, which makes it a tremendous effort for me to install on my system. for instance: 'On the frontend, install PostgreSQL. You may be able to use another SQL database, but (1) it must support transactions (this rules out MySQL unless someone rewrites Wing::Login in a way which doesn't require transactions). This rewriting doesn't take much effort, I have done it for one company. You will need much more effort adding other things to make it full-featured web-mail system. Installing postgres doesn't take much effort either. It even compiles well on systems that mysql will not because of older libraries. [EMAIL PROTECTED]
ANNOUNCE: Apache::VMonitor 0.5
The uploaded file Apache-VMonitor-0.5.tar.gz has entered CPAN as file: $CPAN/authors/id/S/ST/STAS/Apache-VMonitor-0.5.tar.gz size: 18767 bytes md5: 69d0dbc52e45b2670ae4feab35a9ee44 please allow a few hours for the mirrors to pick up the new file ... Changes: =head1 ver 0.5 - Sat Dec 16 20:06:14 CET 2000 * now mod_perl processes report can be sorted by any of the columns in the report (new variable: SORT_BY) * Documented the required ExtendedStatus to be On in httpd.conf * Removed the ifconfig(1) emulation section which actually has never properly worked, because of the broken underlying implementation in libgtop C library. * On the front page added the count of served requests by child. * the count of mod_perl procs now starts from 1 (and not 0) (Bill Marrs) * correctly reporting the number of processes (some were counted even when they were in the process of death) * removed the presentation of the real memory used for other non-modperl processes since it didn't handle correctly threaded processes like mysql. Currently I don't see how can get to this info from libgtop. Suggestions are welcome. * corrected a bug where user dynamic settings (like refresh rate) were affecting global variables, thus making it hard for two admins to monitor the same site. Now dynamic setting (triggered by clicks on the interface) don't affect the preset values. * changed the number formats in the system section to always use b/K/M if applicable (using Apache::Util::size_string) _ 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: Why I Hate Advocacy at www.perl.com
On Thu, 14 Dec 2000, Stas Bekman wrote: So far Matt has asked whether someone is interested to help him to keep take23 up to date, I doubt whether anybody has contacted Matt and offered help. Actually thats not true - the response has been great. For those who did reply, I'm firefighting right now, so don't expect a fast reply, but maybe one of the other editors will take care of those replies. Mostly we just need articles now though, rather than more editors. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
Linux Hello World Benchmarks: +PHP,JSP,ePerl
Hey, Still very rough, the hello world benchmark suite is available for download at: http://www.chamas.com/bench/hello.tar.gz You may run it like: # to get started, see what tests will run, note you # may need some CPAN modules installed to get this far perl ./bench.pl -test # to run tests for 1 minute ... shut down your programs # and walk away for best results. perl ./bench.pl -time=60 Here are my latest results, having added Resin/caucho/JSP with a J2RE 1.3.0 IBM java engine, which other benchmarks say is the fastest java on linux overall, from previous testing resin seems the fastest JSP. I changed the SSI tests to look more like the others, which also sped them considerably. Finally, I added tests for PHP, mine is 4.0.3, ePerl. Test Name Test File Hits/sec Total Hits Total Time sec/Hits Bytes/Hit -- -- -- -- -- -- Apache::ASP hello.asp 414.3 24857 hits 60.00 sec 0.002414 179 bytes Apache::Dispatch handler hello/worl 689.5 41375 hits 60.01 sec 0.001450 134 bytes Apache::Registry CGI Raw hello_raw. 725.2 43514 hits 60.00 sec 0.001379 52 bytes Apache::Registry CGI.pm hello.reg 491.5 29492 hits 60.00 sec 0.002035 154 bytes Apache::SSI hello.shtm 584.6 35080 hits 60.01 sec 0.001711 137 bytes Apache::ePerl hello.eper 359.8 21588 hits 60.00 sec 0.002780 155 bytes HTML static hello.html 1195.2 5 hits 41.83 sec 0.000837 249 bytes HTML::Embperl hello.epl 510.8 30647 hits 60.00 sec 0.001958 158 bytes HTML::Mason hello.mas 383.8 23030 hits 60.00 sec 0.002605 134 bytes Template Toolkit hello.tt553.6 33221 hits 60.01 sec 0.001806 136 bytes mod_caucho JSPhello.jsp 859.9 5 hits 58.15 sec 0.001163 156 bytes mod_include SSI hello.shtm 1008.0 5 hits 49.60 sec 0.000992 136 bytes mod_perl handler hello.benc 886.3 5 hits 56.42 sec 0.001128 134 bytes mod_php PHP hello.php 750.8 45050 hits 60.00 sec 0.001332 163 bytes As has been noted, my static html is probably slower than yours relatively. I have a dual CPU system have most apache modules enabled by default, thus creating huge headers for static html. I think the dual CPU nature of my system means my system will spend more time waiting on SMP network locking as the request rate gets faster, but I don't know much about these things, so if there is something to be gained here, please feel free to clarify how this might impact the results. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Why I Hate Advocacy at www.perl.com
On Thu, 14 Dec 2000, Stas Bekman wrote: So far Matt has asked whether someone is interested to help him to keep take23 up to date, I doubt whether anybody has contacted Matt and offered help. Actually thats not true - the response has been great. For those who did reply, I'm firefighting right now, so don't expect a fast reply, but maybe one of the other editors will take care of those replies. Mostly we just need articles now though, rather than more editors. That's what I was looking for :) Indication of what's going on... Thanks! _ 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: Linux Hello World Benchmarks: +PHP,JSP,ePerl
For the raw benchmarks... OK, I finally got a little time to download and read some the hello.tar.gz. It's good to see TT is fairly fast. But it's a shame that the only way to get faster than PHP is to write a raw Mod_perl handler according to the benchmarks. All the other mod_perl tools seem slower. JSP seems to also blow away mod_perl and PHP (except being almost equivalent to mod_perl handler speed). I assume Resin is precompiling JSP to Java classes and that maybe the JRE you are using does some very good hotspot on-the-fly machine-code compiling type technology? How does this benchmark stuff compare to the tests run at http://www.chamas.com/bench/ I notice that JSPs take quite a beating there but are running on a lower end machine on that set of tests. I presume the below tests are intended to replace the tests run on these various disparate machines. You also seem to have taken out tests? So you are no longer testing servlets only? It would be interesting to see if Servlet - JSP dispatching (with is the recommended model of coding Java Servlets/JSPs these days) results in any slow down. At 02:15 PM 12/16/2000 -0800, Joshua Chamas wrote: Hey, Still very rough, the hello world benchmark suite is available for download at: http://www.chamas.com/bench/hello.tar.gz You may run it like: # to get started, see what tests will run, note you # may need some CPAN modules installed to get this far perl ./bench.pl -test # to run tests for 1 minute ... shut down your programs # and walk away for best results. perl ./bench.pl -time=60 Here are my latest results, having added Resin/caucho/JSP with a J2RE 1.3.0 IBM java engine, which other benchmarks say is the fastest java on linux overall, from previous testing resin seems the fastest JSP. I changed the SSI tests to look more like the others, which also sped them considerably. Finally, I added tests for PHP, mine is 4.0.3, ePerl. Test Name Test File Hits/sec Total Hits Total Time sec/Hits Bytes/Hit -- -- -- -- -- -- Apache::ASP hello.asp 414.3 24857 hits 60.00 sec 0.002414 179 bytes Apache::Dispatch handler hello/worl 689.5 41375 hits 60.01 sec 0.001450 134 bytes Apache::Registry CGI Raw hello_raw. 725.2 43514 hits 60.00 sec 0.001379 52 bytes Apache::Registry CGI.pm hello.reg 491.5 29492 hits 60.00 sec 0.002035 154 bytes Apache::SSI hello.shtm 584.6 35080 hits 60.01 sec 0.001711 137 bytes Apache::ePerl hello.eper 359.8 21588 hits 60.00 sec 0.002780 155 bytes HTML static hello.html 1195.2 5 hits 41.83 sec 0.000837 249 bytes HTML::Embperl hello.epl 510.8 30647 hits 60.00 sec 0.001958 158 bytes HTML::Mason hello.mas 383.8 23030 hits 60.00 sec 0.002605 134 bytes Template Toolkit hello.tt553.6 33221 hits 60.01 sec 0.001806 136 bytes mod_caucho JSPhello.jsp 859.9 5 hits 58.15 sec 0.001163 156 bytes mod_include SSI hello.shtm 1008.0 5 hits 49.60 sec 0.000992 136 bytes mod_perl handler hello.benc 886.3 5 hits 56.42 sec 0.001128 134 bytes mod_php PHP hello.php 750.8 45050 hits 60.00 sec 0.001332 163 bytes As has been noted, my static html is probably slower than yours relatively. I have a dual CPU system have most apache modules enabled by default, thus creating huge headers for static html. I think the dual CPU nature of my system means my system will spend more time waiting on SMP network locking as the request rate gets faster, but I don't know much about these things, so if there is something to be gained here, please feel free to clarify how this might impact the results. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051 __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
load average: 24.07, 14.76, 9.20
Hi all, I've been having the following problem with my machine (400MHz, 192 MB RAM, 8.4 GB SCSI disk): 1:27am up 3 days, 7:33, 8 users, load average: 24.07, 14.76, 9.20 Every once in a while, the load average gets up to a very high level (at this point, programs start getting "Out of memory!" errors, etc.). I don't really know what to do to fix this, other than typing /sbin/reboot. Looking at "top" doesn't show any very big processes, so I suspect it might be being caused by a large number of small processes. This is a web server; one of the sites I have on it, animewallpapers.com, is much more popular than all the other sites. Since most of the activity on the server is from httpd, I'm guessing that this site (which runs Apache::ASP) is responsible. I can't tell for sure, though. Could someone point me in the right direction as to how to: (1) find out what is causing my server to become so slow (perhaps there's some sort of benchmarking tool I can use?) (2) fix it (if animewallpapers.com's ASP scripts is causing it, I would have to figure out how to recode them more efficiently) Thanks, -Philip Mak ([EMAIL PROTECTED])
