Re: problems with Apache::Filter
Drox wrote: Hi I am having troubles trying to install the Apache module Apache::Filter I need this module installed, so I can use Apache::SSI with Apache::ASP I already have mod_perl installed. It seems to be installed ok. But when I try to install or test Apache::Filter, I get the following: Can't locate object method boot via package mod_perl at C:/Perl/site/lib/Apache/Constants.pm line 8 Right, so basically either Apache::Filter Apache::SSI need to be ported to mod_perl 2, or I need to bundle this functionality directly into Apache::ASP. I would prefer the former, but could do the latter ( its been requested before anyway ). Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checker http://www.nodeworks.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Carpout in mod_perl
Wojciech Pietron wrote:
...
use CGI qw(header param url_param url);
use CGI::Carp qw(fatalsToBrowser croak carp carpout);
my ($pwd, $errorlog, $fh);
BEGIN {
$pwd = qx|/bin/pwd|;
chop $pwd;
$errorlog = $pwd/myerror.log;
$fh = new FileHandle $errorlog;
carpout($fh);
}
# functions printing to STDERR
...
==
If I use CGI instead of mod_perl, it is OK. I have all my STDERR messages at
myerror.log. But when I put my script in mod_perl environment then I have some
of the messages in myerror.log and some in standard Apache error_log file. If
I run my script a few times, I can see that the message appears randomly either
in myerror.log or in error_log file.
I am not able to determine when messages are going to myerror.log and when they
are going to error_log. Is it a feature of mod_perl?
In mod_perl, you should be aware that BEGIN {} blocks only get executed the
first time a script is compiled, so is not a reliable place to execute code
that you want executed once per script. If you reall want the code execute
each request, put it into a subroutine, and call that routine each time.
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checker http://www.nodeworks.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Use of uninitialized valued in concatenation....
B. Fongo wrote: Hello I have a file (output_tab.pm) that I use to generate tables dynamically. Even though it serves its purpose, it goes on generating this error: Script_name.pl: Use of uninitialized value in concatenation (.) or string at output_tab.pm line 42. At line 42 of your output_tab.pm module, make sure all variables being used in that line have a value before being used. For example... $null_var ||= ''; The real problem may be that your logic to assign the variable in the first place doesn't work, but you can make the error message go away with the mentioned trick. For more info on this, check out the perldoc perldiag page and look up the error message for a better explanation. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checker http://www.nodeworks.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Interpreting HTML
js wrote: I have apache2 and mod_perl2 setup and running without any problems with .PL files. In apache2 I have my test directory setup like the following: Alias /test/ C:/apache2/htdocs/ Location /test/ SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location How do I stop .HTML files from being interpreted? You could always just match on .pl, like: Location ~ /test/*.pl SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI /Location For more on using Location, please see: http://httpd.apache.org/docs-2.0/mod/core.html#location Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checker http://www.nodeworks.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Interpreting HTML
Patrick Galbraith wrote: LocationMatch I think is what you want. Location ~ ... and LocationMatch ... do the same thing. The trick is the ~ after the Location. Please see http://httpd.apache.org/docs-2.0/mod/core.html#location for more information. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checker http://www.nodeworks.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[ANNOUNCE] Apache::ASP v2.55 released
Hi, The latest version of Apache::ASP v2.55 has been released. The biggest improvement is no longer loading Apache::compat for running under mod_perl2. For the rest of the changes in this release, please see below. To get the latest, install from your local CPAN, and also: http://www.cpan.org/modules/by-module/Apache/ For more information on the Apache::ASP project, please see: http://www.apache-asp.org Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com $VERSION = 2.55; $DATE=08/09/2003 - Bug fixes for running on standalone CGI mode on Win32 submitted by Francesco Pasqualini + Added Apache::ASP::Request::BINMODE for binmode() being called on STDIN after STDIN is tied to $Request object + New RequestBinaryRead configuration created, may be turned off to prevent $Request object from reading POST data ++ mod_perl 2 optmizations, there was a large code impact on this, as much code was restructured to reduce the differences between mod_perl 1 and mod_perl 2, most importantly, Apache::compat is no longer used + preloaded CGI for file uploads in the mod_perl environment - When XSLT config is set, $Response-Redirect() should work now Thanks to Marcus Zoller for pointing problem out + Added CookieDomain setting, documented, and added test to cover it in t/cookies.t . Setting suggested by Uwe Riehm, who nicely submitted some code for this.
Re: [ANNOUNCE] Apache::ASP v2.55 released
Perrin Harkins wrote: Josh Chamas wrote: The latest version of Apache::ASP v2.55 has been released. The biggest improvement is no longer loading Apache::compat for running under mod_perl2. Has this affected the performance measurements you made earlier in any way? Not really. I was working on the port away from Apache::compat during the benchmarking, so the results I posted before largely reflect the porting work. I do not believe there was much of a performance impact regardless, there is so much runtime overhead to Apache::ASP, that the difference was probably on the order of 5% or so if any. There might have also been a small amount of memory savings as well, but I remember it to be on the order of a 200-300K or so across 20 processes ( things preloaded as usual ). Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Apache::ASP Configuration
Quan Mac wrote: Hi, I just installed mod_perl and Apache::ASP on my computer and I was wondering if you could tell me how to configure my Apache httpd.conf file to make ASP pages work. I tried adding in the lines from the website for configuration and then I restarted Apache. All I get is the html, but none of my ASP is working and Im just trying to get it to print out a message. Your help would be greatly appreciated. Please see: http://www.apache-asp.org/install.html#Quick%20Start For more questions about Apache::ASP, please get on the mailing list at [EMAIL PROTECTED] Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: [ANNOUNCE] Apache Hello World Benchmarks v1.02
Ask Bjoern Hansen wrote:
On Tue, 4 Mar 2003, Josh Chamas wrote:
I thought it was interesting that Embperl 2 (barely) beat out PHP 4.3.0
on XSLT in both the XSLT Hello XSLT Big tests.
Why is that interesting? A bit more background would be
interesting. :-) (post it to the list maybe).
My experience has been that raw mod_perl handlers, PHP scripts Resin JSP
tend to be the fastest on the benchmarks generally ( aside from the pure
C handlers of course! ) ... so when Embperl2 beats out PHP on the XSLT tests,
I was a bit surprised, especially since both of the benchmarks are using
libxslt ( http://xmlsoft.org/XSLT/ ).
Neither environment seems to have a XSLT specific caching mechanism,
so I would have guessed that PHP would beat out Embperl2. Gerald
must have done a fine job on the Embperl XSLT implementation to
beat out PHP here.
Perhaps its due to that PHP does not really integrate XSLT other than
some additional API calls. The script itself is causing the XSLT
rendering to happen:
?php
$xmldoc = domxml_open_file('hxslt.xml');
$xsldoc = domxml_xslt_stylesheet_file('hello.xsl');
$result = $xsldoc-process($xmldoc);
echo $xsldoc-result_dump_mem($result);
?
This differs from Embperl where the application layer itself handles
the XSLT rending, not the script/XML file:
PerlSetEnv EMBPERL_RECIPE LibXSLT
PerlSetEnv EMBPERL_XSLTPROC libxslt
PerlSetEnv EMBPERL_XSLTSTYLESHEET $ROOT/hello.xsl
So perhaps Embperl 2 is able to do some things like caching of style
sheets and the like internally that PHP doesn't do for one?
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
[ANNOUNCE] Apache Hello World Benchmarks v1.02
Hey, I have published the latest Hello World benchmarks, available at: http://chamas.com/bench/ Just updated are: - PHP 4.3.0 built with domxml extensions for XSLT tests - HTML::Embperl 1.3.6 - HTML::Mason 1.19 The PHP XSLT test are new, and the performance is similar is Embperl2 and it doesn't seem to have a built in XSLT caching layer like AxKit, Apache::ASP Resin. I thought it was interesting that Embperl 2 (barely) beat out PHP 4.3.0 on XSLT in both the XSLT Hello XSLT Big tests. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: mp2: any recommendations for template systems yet?
Perrin Harkins wrote: On Thu, 2003-02-20 at 22:27, Carl Brewer wrote: Do any of you have any recommendations for template systems with mp2? Not of the religious kind (!) but more on the lines of what's working with mp2 at the moment? Everything that doesn't make mod_perl API calls should work without changes. That means HTML::Template, Template Toolkit, Text::Template, CGI::FastTemplate, etc. Without wishing to start anything religious ... any suggestions for a template system that handles sessions? Apache::ASP, Embperl, and Mason all have session support integrated now. I can't vouch for their stability on mp2 yet though. AFAIK, Apache::ASP v2.51 is working correctly on mp2 without any special installation or configuration. As a separate issue, but also interesting, users are reporting success with running Apache::ASP under SpeedyCGI also which speaks well towards its portability. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
[ANNOUNCE] Apache::ASP v2.51 released
Hey,
Apache::ASP v2.51 is released to CPAN. You can get it from your local
CPAN archive or here:
http://www.cpan.org/modules/by-module/Apache/
Below are the changes. This is a big release, and though it is
well tested, please upgrade carefully.
For more info on Apache::ASP, please see http://www.apache-asp.org
About Apache::ASP...
Apache::ASP provides an Active Server Pages port to the
Apache Web Server with Perl scripting only, and enables developing of
dynamic web applications with session management and embedded perl code.
There are also many powerful extensions, including XML taglibs, XSLT rendering,
and new events not originally part of the ASP API!
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
CHANGES ==
$VERSION = 2.51; $DATE=02/10/2003
+ added t/session_query_parse.t test to cover use of SessionQueryParse
and $Server-URL APIs
- Fixed duplicate bug associated with using $Server-URL
and SessionQueryParse together
+ Patch to allow $Server-URL() to be called multiple times on the same URL
as in $Server-URL($Server-URL($url, \%params), \%more_params)
(d) Added new testimonials sites created a separate testimonials page.
- SessionQueryParse will now add to amp; to the query strings
embedded in the HTML, instead of for proper HTML generation.
Thanks to Peter Galbavy for pointing out and Thanos Chatziathanassiou
for suggesting the fix.
- $Response-{ContentType} set to text/html for developer error reporting,
in case this was set to something else before the error occured.
Thanks to Philip Mak for reporting.
- Couple of minor bug fixes under PerlWarn use, thanks Peter Galbavy
for reporting.
+ Added automatic load of use Apache2 for compat with mod_perl2
request objects when Apache::ASP is loaded via PerlModule Apache::ASP
Thanks to Richard Curtis for reporting bug subsequent testing.
- When GlobalPackage config changes, but global.asa has not, global.asa
will be recompiled anyway to update the GlobalPackage correctly.
Changing GlobalPackage before would cause errors if global.asa was
already compiled.
++ For ANY PerlSetVar type config, OFF/Off/off will be assumed
to have value of 0 for that setting. Before, only a couple settings
had this semantics, but they all do now for consistency.
- Fix for InodeNames config on OpenBSD, or any OS that might have
a device # of 0 for the file being stat()'d, thanks to Peter Galbavy
for bug report.
++ Total XSLT speedups, 5-10% on large XSLT, 10-15% on small XSLT
+ bypass meta data check like expires for XSLT Cache() API use
because XSLT tranformations don't expire, saves hit to cache dbm
for meta data
+ use of direct Apache::ASP::State methods like FETCH/STORE
in Cache() layer so we don't have to go through slower tied interface.
This will speed up XSLT and include output caching mostly.
+ minor optimizations for speed memory usage
Re: install apache:asp in windows
Karthik kannan wrote: Sir, I want to run sum asp programs using apache webserver 1.3 so i downloaded mod_perl-2.0-current.ta to have asp support on apache webserver. Please email future Apache::ASP support issues to [EMAIL PROTECTED] as that is the correct user group. You can get on the mailing list by emailing [EMAIL PROTECTED] 1. Please tell me how to install.(in the website it is not clear) Please read http://www.apache-asp.org/install.html#Win32%20%2F%20Wind0f0e8ac6 2. Is there any change in config file. 3. then how to run an asp file. Please read the rest of http://www.apache-asp.org/install.html Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Problem with dbm files?
Warren Pollans wrote: One app uses MLDBM (with DB_File) to store a complex hash. One doc, mod_perl and dbm files, suggests that there might be consistency problems (locking related) when using dbm files with mod_perl. It seems that the MLDBM::Sync module is supposed to eliminate this concern. Could someone that uses MLDBM with DB_File under mod_perl please let me know if there are, in fact, problems with this combination. If so, will MLDBM::Sync fix them or do I need to rewite my app to use mysql? MLDBM::Sync is a drop in replacement for MLDBM for typical use, and correctly deals with concurrency issues as long as the files are on the local disk, files on network mounts may not respect the file locking that MLDBM::Sync uses. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Executing Apache::Registry cached script from normal mod_perl
Matthew Hodgson wrote: Hi, I have a script which executes under Apache::Registry and resides in /perl/blah.pl. However, it only generates a fragment of a page, and is normally embedded into an html template using SSI with something like: !--#perl sub=Apache::Include arg=/perl/blah.pl -- I am very aware that this would be better implemented as a raw perl module used from apache's startup.pl (and then embedded using something like !--#perl sub=Blah --) - but practically this isn't an option right now. How about just executing this file like this: do $path_to/perl/blah.pl; Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: RFC: Template::YetAnother
Thomas Klausner wrote: Hi! Yes, this is a RFC for Yet Another Templating System. I know that there are a lot of those around. But this own might be different/interesting (at least I think/hope so...) I also posted this on perlmonks: http://www.perlmonks.org/index.pl?node_id=213300 So, here it is, in POD format: Don't do it. If you want a stripped down version of an existing templatting language, then that's great. Work with the authors of exising frameworks like Template Toolkit or HTML::Template that *were designed* as pure template frameworks ( as opposed to the app frameworks like Embperl, ASP, AxKit, Mason) I'm sure you can get the authors to accept patches to disable features that you don't want, you might even be able to create a subclass of such a template module that sets these for the end user, so if they just use Template:JustVarsPlease, and Template::JustVarsPlease is a subclass of Template or HTML::Template, then you have your solution. Those template solutions that are too much for you got that way because their users wanted needed more. That is the natural evolution of these things. The perl template user community is already fractured enough, better to hop onto a project, hack it to your satisfaction ( with the blessing of the maintainers ) to get the configs/subclasses you need for your requirements. That's what I would do anyway. :) Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
odd headers with Apache::add_version_component()
Hey, I'm looking to get Apache::ASP to insert itself into the module Server tokens with the add_version_component() API, so I call it like this: package Apache::ASP ... Apache::add_version_component(Apache::ASP/$VERSION); ... 1; but then it becomes the first header on the list!, and I do not want it to look like it is the actual web server itself... Server: Apache::ASP/2.49 Apache/1.3.27 (Unix) PHP/4.2.3 mod_perl/1.27 Perl/v5.8.0 mod_ssl/2.8.11 OpenSSL/0.9.6g So, how can I use this method correctly, so that Apache::ASP ends up near the end of the server tokens? BTW, I dug up this method from the mod_perl Cookbook very good examples, http://www.modperlcookbook.org/ Thanks, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: odd headers with Apache::add_version_component()
Geoffrey Young wrote: from what I remember, this method is very strange - it depends lots on how your server is set up. for instance, whether you're using DSO (which breaks down the interpreter on restarts) and/or whether you have PerlFreshRestart On. both of these behaviors seem to affect the order of the tokens. I am not using DSO, but it is enabled. When I set PerlFreshRestart On, I do get the header in the right place, but its also still in the wrong place! Server: Apache::ASP/2.49 Apache/1.3.27 (Unix) PHP/4.2.3 mod_perl/1.27 Perl/v5.8.0 Apache::ASP/2.49 mod_ssl/2.8.11 OpenSSL/0.9.6g At least we are a step closer. Even if I can get this to work through certain config tweaks, I will not add this to Apache::ASP as I would need this to be correct for all user configs, not just mine. I do not want to preempt the Apache/... header! Thanks for the follow up. Maybe I'll revist this in MP2. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: weird cookie behavior
valerian wrote: I'm experiencing strange behavior with cookies when my scripts are accessed in mod_perl (using Apache::Registry). Everything works fine so long as my browser is configured to not go through a proxy (ie, in Netscape 4.77, directly connected to the Internet option is selected). When I configure it to use a custom proxy (eg, Junkbuster running on my LAN gateway), my cookies no longer work, but I can still browse the web fine. I would not rule out the junkbuster proxy just yet. To get at the root of the problem, you will need to see the HTTP headers as they are output directly from your program, with and without the proxy. You can use lwp-request for this like: lwp-request -ed http://URL/PATH lwp-request -ed -p PROXY http://URL/PATH and see what HTTP headers come back. If the headers change, then maybe the junkbuster proxy is munging something up or dropping headers. It may be that there is some header special to mod_perl that is messing up junkbuster for example so that you do not see the problem in CGI mode. There is also a chance that junkbuster is adding some header, only for the mod_perl output that simply messes up netscape. Either way, seeing the headers themselves should help get to the root of it. If its the former scenario, I would take the problem first to the junkbuster developers. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
[ANNOUNCE] Apache::ASP v2.49 released
Hey, Hot on the heels of the 2.47 release, I have released Apache::ASP v2.49 to CPAN which fixes a major bug introduced in 2.47. Here is the change: -- bug introduced in 2.47 cached script compilations for executing scripts ( not includes ) of the same name in different directories for the same Global/GlobalPackage config for an application. Fix was to remove optimization that caused problem, and created test case t/same_name.t to cover bug. Thanks to Rune Henssel for catching this shortly after 2.47 was released. For more info on Apache::ASP, please visit http://www.apache-asp.org Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
[ANNOUNCE] Apache::ASP v2.47 released
Hey,
Apache::ASP v2.47 is released to CPAN. It is a major upgrade
with significant speed improvements of 15-20% for script execution.
As this is a major release, please be sure to read the CHANGES
and test your sites before upgrading. The CHANGES are listed below.
For more info on Apache::ASP, please see http://www.apache-asp.org
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
$MODULE=Apache::ASP; $VERSION = 2.47; $DATE=11/6/2002
Please see README for changes for past versions.
+ = improvement;- = bug fix;(d) = documentation
++ Runtime speed enhancements for 15-20% improvement including:
+ INTERNAL API ReadFile() now returns scalar ref as memory optimization
+ cache InodeNames config setting in ASP object now for common lookups
+ removed CompileChecksum() INTERNAL API, since it was an unnecesary
method decomposition along a common code path
+ removed IsChanged() INTERNAL API since compiling of scripts
is now handled by CompileInclude() which does this functionality already
+ removed unnecessary decomp of IncludesChanged() INTERNAL API, which was along
critical code path
+ do not call INTERNAL SearchDirs() API when compiling base script
since we have already validated its path earlier
+ Use stat(_) type shortcut for stat() -X calls where possible
+ Moved INC initilization up to handler() consolidated with $INCDir lib
+ removed useless Apache::ASP::Collection::DESTROY
+ removed useless Apache::ASP::Server::DESTROY
+ removed useless Apache::ASP::GlobalASA::DESTROY
+ removed useless Apache::ASP::Response::DESTROY
- Default path for $Response-{Cookies} was from CookiePath
config, but this was incorrect as CookiePath config is only
for $Session cookie, so now path for $Response-{Cookies}
defaults to /
- Fixed bug where global.asa events would get undefined with
StatINC and GlobalPackage set when the GlobalPackage library
changed get reloaded.
(d) Documented long time config NoCache.
-- Fixed use with Apache::Filter, capable as both source
and destination filter. Added ./site/eg/filter.filter example
to demonstrate these abilities.
+ Use $r-err_headers_out-add Apache::Table API for cookies
now instead of $r-cgi_header_out. Added t/cookies.t test to
cover new code path as well as general $Response-Cookies API.
Also make cookies headers sorted by cookie and dictionary key
while building headers for repeatable behavior, this latter was
to facilitate testing.
- fixed $Server-Mail error_log output when failing to connect
to SMTP server.
+ added tests to cover UniquePackages NoCache configs since this
config logic was updated
+ made deprecated warnings for use of certain $Response-Member
calls more loadly write to error_log, so I can remove the AUTOLOAD
for Response one day
- Probably fixed behavior in CgiHeaders, at least under perl 5.8.0, and
added t/cgi_headers.t to cover this config.
+ removed $Apache::ASP::CompressGzip setting ability, used to possibly
set CompressGzip in the module before, not documented anyway
+ removed $Apache::ASP::Filter setting ability to set Filter globally,
not documented anyway
+ removed old work around for setting ServerStarting to 0
at runtime, which was bad for Apache::DBI on win32 a long
time ago:
$Apache::ServerStarting and $Apache::ServerStarting = 0;
If this code is still needed in Apache::ASP-handler() let
me know.
+ check to make sure data in internal database is a HASH ref
before using it for session garbage collection. This is to
help prevent against internal database corruption in a
network share that does not support flock() file locking.
+ For new XMLSubs ASP type %= % argument interpolation
activated with XMLSubsPerlArgs 0, data references can now
be passed in addition to SCALAR/string references, so one
can pass an object reference like so:
my:tag value=%= $Object % /
This will only work as long as the variable interpolation %= %
are flushed against the containing or ' ', or else the object
reference will be stringified when it is concatenated with
the rest of the data.
Testing for this feature was added to ./t/xmlsubs_aspargs.t
This feature is still experimental, and its interface may change.
However it is slated for the 3.0 release as default method,
so feedback is appreciated.
+ For new XMLSubs ASP type %= % argument interpolation
activated with XMLSubsPerlArgs 0, % % will no longer work,
just %= %, as in
my:tag value=some value %= $value % more data /
This feature is still experimental, and its interface may change.
However it is slated for the 3.0 release as default method,
so feedback
Re: apache::ASP
[EMAIL PROTECTED] wrote: Does this include an AddRotator? On Win32 platforms, whatever COM objects exist there can be accessed via the $Server-CreateObject API, but on Unix platforms $Server-CreateObject does not work. Please post future questions on Apache::ASP to [EMAIL PROTECTED] Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: [OTish] Version Control?
Ged Haywood wrote: Hi all, On Thu, 31 Oct 2002, Iain 'Spoon' Truskett wrote: experimenting with perforce [which, so far, appears nicer than CVS] ) Yikes! Josh, you got anything to say about that? Well I have used perforce much more than CVS now, so that is where I'm most comfortable. My basic feeling is that perforce is harder to set up, but more idiot proof while using it, especially for more advance operations like branching integration. CVS however is a breeze to set up, but I feel like its branching tagging is more of a hack ( note I am just starting to use it recently. ) I really like how I do not have to explicitly cvs edit files like I do in perforce before I start working on them. Oh, CVS is free which is always a good thing. :) As for scaling, perforce probably has a better chance to scale with its dbm based storage locking, however at this one company that uses it they get db corruption when developers hammer its with huge media checkins which I suspect CVS never would get. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: code evaluation in regexp failing intermittantly
Rodney Hampton wrote: Perrin, Danny, et. al. I looked over the comparison document as well as the perldocs on all the templating systems I could find on CPAN before embarking on this journey. I'll add in how Apache::ASP can be used to solve this problem... I really only need 3 tags: one to link the templates together, one to bring in images, and one to call code that can by dynamically inserted. Every item in my application's database (templates, images, and other files) has user and group permissions that need to Apache::ASP lets you define custom tags like: my:link_name type=template_faq / instead of % link_name template_faq % my:img_src val=some_image / instead of % img_src_name some_image % These tags get rendered by subroutines you define my::link_name and my::img_src. You can use global.asa Script_OnStart to do all the database handle setup work to make this easily accessible to your XMLSubs ( the name of this tagging feature ). Of course, maybe more like what you have now, in Apache::ASP, its easy to also do: % link_name(template_faq); % but I personally like the XMLSubs approach because it takes a more content oriented approach to your pages, than embedding code. The trick to making easy local subs for all your pages is to define these subs in your global.asa, which is the package all of your pages are compiled into. be checked on access. Thus, any templating system that did caching is pretty much out of the running because as soon as I revoke a user's privileges or change permissions on the item, I want access to change Apache::ASP does do output caching of includes only when explicitly asked for, see: http://www.apache-asp.org/objects.html#%24Response-%3EIa3beea1e This is only for performance optimization, so you do not have to worry about caching otherwise. need to track users so I had to be able to establish and maintain a session so this was a definate requirement. Also, I needed to be able to selectively protect certain areas of the application with login screens (not necessarily the same one depending on where you Like other systems session management has been built into Apache::ASP from the get go ( one of the reasons I started work on Apache::ASP ). In that system, its the $Session object. navigate). This is the underlying architecture for a client I have but I intend to make it modular enough to use for future projects. I've done some benchmarking on what I've built already and am satisfied with the results. I seem to be able to serve up 30 concurrent connections sending dynamic content all day long and have it sever between 25-35 requests per second at around 300 - 375 Kbytes/sec. I've compiled mod_perl with DSO and it's never shown any For other benchmarking of the various web app environments you could use, check out http://chamas.com/bench/ Anyway, I'm not trying to say that what I'm doing is better or worse than what has come before. I just happen to have different requirements and I didn't think that the other systems out there were going to be both lightweight and allow me to meet my need for access control. As others have asserted, I believe if you look at the other systems hard enough, you will find many others that can fill your requirements. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Apache Hello World Benchmarks Updated
Dave Rolsky wrote: On Mon, 14 Oct 2002, Josh Chamas wrote: This is interesting. I should look into upgrading to perl 5.8 on these tests see what difference there may be. You might also see if it makes a difference if you run the tests for a long enough time. I run them at least 60 seconds for these benchmarks which may make a difference. FYI, I reposted the benchmarks without the MaxRequestsPerChild 100 set for HTML::Mason Template Toolkit, as it was only Embperl 2.x that needed it. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Apache Hello World Benchmarks Updated
Ed wrote: Hi, (as far as i can tell after a quick peek at the code and some debugging) It looks like there is a bug w/ AxKit::run_axkit_engine() and/or Apache::AxKit::Cache::_get_stats() This is really great Ed. Adding the AxGzipOutput On config to the XSLT tests in the benchmark does seem to correctly activate the cache layer, and AxKit now dominates in speed on the larger XSLT transformation! I will leave off the config for the XSP tests since it does not seem to help at all there. I will republish benchmarks with the new configs soon, thanks so much for digging into this. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Apache Hello World Benchmarks: AxKit config fixed XSLT, Cocoon benchmarksadded, Tomcat updated to 4.1.12
Hey, I updated the Apache Hello World Benchmarks with some major updates: AxKit config fixed XSLT performance Cocoon XSLT benchmarks added Tomcat updated to 4.1.12 Check them out at http://chamas.com/bench/ Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Apache Hello World Benchmarks Updated
Hey, The Apache Hello World benchmarks are updated at http://chamas.com/bench/ The changes that affect performance numbers include: Set MaxRequestsPerChild to 1000 globally for more realistic run. Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Note that the latter change seemed to have the most benefit for Embperl 2.0, with some benefit for Template Toolkit less ( but some ) for HTML::Mason on the memory usage numbers. Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
[ANNOUNCE] Apache::ASP v2.45 released
Hey,
Apache::ASP v2.45 is released to CPAN. This is a fairly large
release with some new features, performance enhancements bug fixes.
Please see the change log below.
For more information about Apache::ASP, please see the web site at:
http://www.apache-asp.org
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
CHANGES for 2.45
++New XMLSubsPerlArgs config, default 1, indicates how
XMLSubs arguments have always been parsed. If set to 0,
will enable new XMLSubs args that are more ASP like with
%= % for dynamic interpolation, such as:
my:xmlsub arg=%= $data % arg2=text %= $data2 % /
Settings XMLSubsPerlArgs to 0 is experimental for now, but
will become the default by Apache::ASP version 3.0
++Optimization for static HTML/XML files that are served up
via Apache::ASP so that they are not compiled into perl subroutines
first. This makes especially native XSLT both faster take
less memory to serve, before XSL XML files being transformed
by XSLT would both be compiled as normal ASP script first, so
now this will happen if they really are ASP scripts with embedded
% % code blocks XMLSubs being executed.
+Consolidate some config data for Apache::ASP-Loader to use
globals in Apache::ASP::CompileChecksumKeys to know which
config data is important for precompiling ASP scripts.
+Further streamlined code compilation. Now both base
scripts and includes use the internal CompileInclude() API
to generate code.
-Fixed runtime HTML error output when Debug is set to -2/2,
so that script correctly again gets rendered in final perl form.
Added compile time error output to ./site/eg/syntax_error.htm
when a special link is clicked for a quick visual test.
-Cleaned up some bad coding practices in ./site/eg/global.asa
associated changes in other example files. Comment example
global.asa some for the first time reader
-DemoASP.pm examples module needed use strict fix, thanks
to Allan Vest for bug report
--$rv = $Response-Include({ File = ..., Cache = 1});
now works to get the first returned value fetched from
the cache. Before, because a list was always returned,
$rv would have been equal to the number of items returned,
even if the return value list has just one element.
(d) added site/robots.txt file with just a comment for
search engine indexing
-fixed ./site/eg/binary_write.htm to not use
$Response-{ContentLength} because it does not exist.
Fixed it to use $Response-AddHeader now instead
Re: Apache Hello World Benchmarks Updated
Perrin Harkins wrote: Josh Chamas wrote: Set MaxRequestsPerChild to 100 for applications that seem to leak memory which include Embperl 2.0, HTML::Mason, and Template Toolkit. This is a more typical setting in a mod_perl type application that leaks memory, so should be fairly representative benchmark setting. Maybe I'm more careful about memory growth than some people, but 100 sounds a bit on the low side to me. I use Apache::SizeLimit instead of For the purposes of the benchmark, using Apache::SizeLimit won't do much the worst results are only showing 3M unshared per process 8M total memory per process. The benchmarks run at 20 MaxClients. MaxRequestsPerlChild, but I'm pretty sure every child serves more requests than that. Did it seem to affect the performance numbers much? For Embperl 2.x it made a world of difference on the memory side, with only a slight performance impact of 5-10%, but reduced memory usage from 60M to 25M for the test. Gerald I have found real memory leaks in Embperl 2.x, where this kind of config is necessary. Incidentally, I hate to call this stuff memory leaks, since it's usually just normal growth as memory gets used. Calling it leaks Right... I looked into HTML::Mason today, and agree with you and David that for HTML::Mason there is not a memory leak, it just uses more unshared memory than other environments at runtime, and the MaxRequestsPerChild did not seem to make a difference. This might also be true of Template Toolkit. I'll look into the latter more. I just assumed if the unshared memory footprint was as high as it was for these environments, that there must have been a leak like in Embperl 2.x. I also looked into AxKit which seems to use more memory, but it too does not seem to have a leak. implies that memory is being wasted as a result of mistakes with pointers or some such. When people hear memory leaks they go running for stuff like Apache::Leak, thinking they can find some problem and fix it, which is usually not the case. Right. What I go for in the benchmarks as far as a memory leak goes is do the environments seem to use the same amount of memory at 30 seconds as they do at 60 seconds. In the case of Embperl 2.x, this was very different, but in the case of HTML::Mason, it stays the same. Thanks as always for your feedback. --Josh
Re: Apache Hello World Benchmarks Updated
Dave Rolsky wrote: I'm fairly sure, FWIW, that Mason does not have any memory leaks, as of 1.12. Pre-1.10 versions do have a _very_ slow memory leak, and 1.10 and 1.11 had that leak plus another, much nastier one. Yes, Mason seemed pretty free of leaks when I tested it more today too. Also FWIW, running Joshua's tests on my machine uniformly used about 1/3 to 1/4 as much RAM, with Mason, Template Toolkit and Apache::ASP. I too am running GNU/Linux, with a 2.4 kernel, on i386 hardware. The only difference in software was that I have Perl 5.8.0 installed, but I'd be incredibly shocked if that explained the difference. This is interesting. I should look into upgrading to perl 5.8 on these tests see what difference there may be. You might also see if it makes a difference if you run the tests for a long enough time. I run them at least 60 seconds for these benchmarks which may make a difference. I'm actually pretty comfortable with Mason's memory usage because I think that certain features it offers explain its memory use. Basically, any framework that offers filtering features on generated output will need to store the entire output in memory before sending it, and I suspect this is one thing I think has a big impact on Mason's memory usage. Yep, especially with how perl can store internal data structures relatively inefficiently, where 20K of data represented internally can easily bloat up to 100K internally depending on how its being stored, and matters are probably made worse by code data being intermingled so dirtying the data dirties the code pages to to become unshared. I think that is how Gerald achieves his low memory footprints generally in Embperl, since he is doing most of his stuff in C it seems, and still offering all the advanced features we have in the other application frameworks. Regards, Josh
[mp2.0] compatibility suggestion
Hey mod_perl users/developers,
In short what I think we need is for the modperl2 perl-script
configuration directive to automagically load the Apache::compat
layer, please read below for why.
I am working on the Hello World benchmarks to get them running
against mod_perl2 so we can get some numbers comparing mod_perl1
against it, and meanwhile having to port to Apache2/mod_perl2
for the first time, in this case all of the benchmarks.
What struck me odd was that even the simplest of handlers would
not run directly under mod_perl/1.99_05-dev, as in:
sub handler {
my($r) = shift;
$r-content_type('text/html');
$r-send_http_header();
$r-print('Hello ');
$r-print('World');
200;
}
In this case the error was about content_type() not being implemented
which I could fix by adding:
use Apache::compat;
If it is the case that even the most trivial of applications
need Apache::compat, then why not load the Apache::compat layer
automatically? If performance is an issue, or code bloat or
what not, then perhaps *Apache::compat* layer could be added
only in case of using the *perl-script* config directive,
instead of the new modperl directive.
With the differences between the new modperl directive perl-script,
it is clear that the latter is meant for backwards compatibility anyway, so
why not go the extra mile load Apache::compat? At the very least, it
will probably save the thousands of mod_perl modules out there from
having to add that one Apache::compat line to their code.
its not even that easy, in that to keep backwards compatibility
with old modperl 1.x code, we have to add
eval use Apache::compat;
instead! I am actually already doing this now for the modules
that I am trying to get to work with both mod_perl1 and mod_perl2
Thanks for the great work so far, and benchmarks will be forthcoming.
Regards,
Josh
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
mod_perl 2.x vs. mod_perl 1.x benchmarks
Hey mod_perl users, I just did a benchmarks to compare mod_perl + apache versions 1 2. What I find striking is that without any optimizations, the v2 mod_perl apache are faster. I'm really blown away, as I was expecting the new versions to be slower with v1 configurations. Here's the numbers in brief: Apache/1.3.26 + mod_perl/1.27 + perl 5.6.1 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1420.710 70.390.000704 322 5062 mod_perl handlerhello.ben 942.510106.100.001061 206 7660 Apache/2.0.40 + Perl/v5.8.0 + mod_perl/1.99_05-dev Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1619.710 61.740.000617 290 5912 mod_perl handlerhello.ben 1210.110 82.640.000826 194 11070 The mod_perl benchmark was run with the Apache::compat layer and the perl-script directive in Apache 2.x, so it was not optimized. Further, the configs between the web servers were identical on my linux server during the benchmarks, so Apache was not optimized at all for v2. on top of that, the mod_perl2 was loaded as a DSO while mod_perl1 was compiled statically. Again, I'm amazed. Obviously the apache mod_perl development teams have done an awesome job in building this next generation server. Regards, Josh
Re: mod_perl 2.x vs. mod_perl 1.x benchmarks
Perrin Harkins wrote: Josh Chamas wrote: I just did a benchmarks to compare mod_perl + apache versions 1 2. Cool. Any idea why bytes/hit is lower on apache 2? Are some headers being omitted? Looks like its the Server tokens, see below. 32 bytes! Maybe on a benchmark this small, this makes a difference? *sigh* So I run it again with ServerTokens Min, and get the same results. :) Still something different on the mod_perl headers, looks like mod_perl 2.x is setting Content-Length where it didn't use to. Apache/1.3.26 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1417.5 42531 30.000.000705 250 5000 mod_perl handlerhello.ben 939.1 28181 30.010.001065 134 7244 Apache/2.0.40 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML static hello.htm 1602.4 48236 30.100.000624 250 6756 mod_perl handlerhello.ben 1177.3 36062 30.630.000849 154 11648 -- Josh === Old headers throwing static HTML bytes off HTTP/1.1 200 OK Date: Wed, 18 Sep 2002 20:14:59 GMT Server: Apache/2.0.40 (Unix) mod_perl/1.99_05-dev Perl/v5.8.0 Last-Modified: Sun, 10 Dec 2000 03:43:21 GMT ETag: 153814-c-7363e840 Accept-Ranges: bytes Content-Length: 12 Connection: close Content-Type: text/html HTTP/1.1 200 OK Date: Thu, 19 Sep 2002 01:02:20 GMT Server: Apache/1.3.26 (Unix) Resin/2.1.2 PHP/4.2.1 mod_perl/1.27 mod_ssl/2.8.9 OpenSSL/0.9.6b Last-Modified: Sun, 10 Dec 2000 03:43:21 GMT ETag: 153814-c-3a32fbd9 Accept-Ranges: bytes Content-Length: 12 Connection: close Content-Type: text/html
Linux + Apache Worm exploiting pre 0.9.6g OpenSSL vulnerabilitieson the loose
Hey, There seems to be a worm spreading for Apache + Linux + OpenSSL servers that I saw a discussion on at http://apache.slashdot.org/apache/02/09/13/2315246.shtml?tid=172 Seems like we need to upgrade our apache servers to OpenSSL 0.9.6g if we haven't already. I didn't see this posted to mod_perl yet, forgive me if this has been sent out already. Based on discussion at: http://online.securityfocus.com/bid/5363/discussion/ it seems that we might need to upgrade modssl as well, but I have not seen a release of modssl since June ( see http://www.modssl.org/news/ ), so this seems to not be necessary, but do not take my word for it, upgrade if you think its a good idea ( probably is anyway ). Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
[ANNOUNCE] Apache::ASP v2.39 released
Hey, Apache::ASP v2.39 is released to CPAN. This is a minor bug fix release below are the changes. For more on Apache::ASP, please see http://www.apache-asp.org Regards, Josh Josh Chamas, Founder phone:925-552-0128 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com $MODULE=Apache::ASP; $VERSION = 2.39; $DATE=09/10/2002 - Turn off $^W explicitly before reloading global.asa. Reloading global.asa when $^W is set will trigger subroutine redefinition warnings. Reloading global.asa should occur without any problems under normal usage of the system, thus this work around. This fix is important to UseStrict functionality because warnings automatically become thrown as die() errors with UseStrict enabled, so we have to disable normal soft warnings here. - $Response-Include() runtime errors now throw a die() that can be trapped. This was old functionality that has been restored. Other compile time errors should still trigger a hard error like script compilation, global.asa, or $Response-Include() without an eval() + Some better error handling with Debug 3 or -3 set, cleaned up developer errors messages somewhat.
Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB
Perrin Harkins wrote: To answer the original question, I don't think Apache::DBI is much overhead at all. It amounts to little more than a hash lookup. Certainly less work than the the thread synchronization required for connection pooling. My only problem with Apache::DBI for a benchmark is its default ping of the db per connect(). For a benchmark that is little more that a ping itself, this might not be fair to cause 2 pings. In this light, I might want to just use a global like: $dbh ||= DBI-connect(); I just did a quick test, and these were the results: Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - mod_perl HelloDB MySQL Apache::DBI my_hellod 451.3 9042 20.040.002216 191 16092 mod_perl HelloDB MySQL Global $dbh my_hellod 570.2 11418 20.020.001754 191 15296 My question is is this a fair optimization for a benchmark like this. I tend to not over optimize the benchmarks as a rule, but I spent hours ( 12 lines of code :) ) writing an overly simple database connection pooling manager for the JSP benchmarks where a standard one seems to be lacking in JDBC JNDI, so I'm not sure using a mod_perl global instead of Apache::DBI would be skewing things. The PHP test I had to do nothing, connection persistence is enabled by default. Thanks for the feedback still looking for more! --Josh Josh Chamas, Founder phone:714-625-4051 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: ANNOUNCE: Mason 1.12
Dave Rolsky wrote: This release has a number of important improvements and it is highly recommended that anyone use Mason 1.10 or 1.11 upgrade immediately in order to fix a nasty memory leak in ApacheHandler. 1.12 is also quite a bit faster than previous 1.1x versions. Some quick benchmarks show the good work that was done... Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML::Mason v1.11 2000 h2000.mas 16.0 320 20.030.062584 28785 58044 HTML::Mason v1.11 hello.mas 53.8 1077 20.010.018578 196 44580 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - HTML::Mason v1.12 2000 h2000.mas 28.4 568 20.020.035252 28785 57316 HTML::Mason v1.12 hello.mas 114.2 2299 20.140.008759 196 40480 I'll have the benchmarks at http://chamas.com/bench/ updated shortly with new numbers for Mason. Good job. --Josh Josh Chamas, Founder phone:714-625-4051 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
Re: ASP Page wont work
Omar Chicas wrote:
I don't know what else to do but my configurations are:
the
Files ~ (\.asp)
SetHandler perl-script
PerlModule Apache::ASP
PerlHandler Apache::ASP
PerlSetVar Global .
PerlSetVar StateDir /tmp/asp
/Files
Perl
*CORE::GLOBAL::flock = sub { 1 };
/Perl
PerlModule Apache::ASP
The Apache::ASP support list is at [EMAIL PROTECTED]
You might make sure that StateDir points to a valid directory.
/tmp is a unix type directory ( you can create c:/tmp in windows too )
To really start diagnosing the errors though, we will need to
know what is in the error_log for that internal server error.
--Josh
Josh Chamas, Founder phone:714-625-4051
Chamas Enterprises Inc.http://www.chamas.com
NodeWorks Link Checkinghttp://www.nodeworks.com
Re: Apache Hello World Benchmarks
Perrin Harkins wrote: Despite the intentionally misleading nature of Microsoft's benchmark, it did get me thinking about what sort of benchmarking options exist for comparing languages and platforms. The Hello World and Hello 2000 benchmarks are pretty small (understandably so, given that it's one person doing the coding for all environments). A more realistic benchmark would be nice to have, for PR reasons. The Nile.com benchmark models an on-line bookstore and was used by eWeek Labs as recently as February to compare database performance (using identical Java code and varying the database behind it). It's a relatively small application and would probably not take a lot of work to implement on mod_perl. Versions for ASP and JSP already exist and source code is available. It would be good to see someone do this for mod_perl. None of the benchmarks I have done so far get anywhere near testing the scalability of systems in the real world, and it would be good to see this done. As a next step for the hello world benchmarks, I'll probably do a cross platform benchmark while hitting a MySQL database. An insert, delete, update, and 10-20 selects probably, but it will still be a small code base being hit. On a totally different note, it would be fun to see how mod_perl 2 is stacking up on the Hello and Hello 2000 tests. Will do. --Josh Josh Chamas, Founder phone:714-625-4051 Chamas Enterprises Inc.http://www.chamas.com NodeWorks Link Checkinghttp://www.nodeworks.com
