> >
> > Yes, Embperl per default caches a "compiled" version of the
> > stylsheet in
> > memory.
> >
> > Gerald
> >
> > P.S. There are also options to cache the result of the xslt
> > transformation
> > or any itermediate steps
> >
>
> Oh - A way of making it even faster in the benchmarks?
>
Yes,
> From: Gerald Richter [mailto:[EMAIL PROTECTED]
>
> Yes, Embperl per default caches a "compiled" version of the
> stylsheet in
> memory.
>
> Gerald
>
> P.S. There are also options to cache the result of the xslt
> transformation
> or any itermediate steps
>
Oh - A way of making it even faste
>
> 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
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)
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
>
> 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.
>
Embperl 2.0b8 has still some real memory leaks. That's why it called beta.
Of course they will be fixed before the final release of 2.0.
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
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 benchmar
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 le
ipOutput.
So, I reran hello/bench.pl w/ AxGzipOutput On and sped axkit up quite a bit.
attached are some diffs and a couple of 1 sec bench.pl runs. Would be
interesting to see how axkit compares now?
Thanks,
Ed
On Mon, Oct 14, 2002 at 12:26:06AM -0700, Josh Chamas wrote:
> Hey,
>
>
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 be
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
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 fai
On Tue, 15 Oct 2002, 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
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 s
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
Hi Josh,
On Tue, 30 Jul 2002, Josh Chamas wrote:
> Thanks for the feedback & still looking for more!
Well for one thing you're doing a great job. :)
Fo benchmarks to be more realistic, I feel that they need to include
chunks of code to do lookups in serious databases, put together very
complex
Josh Chamas wrote:
> My only problem with Apache::DBI for a benchmark is its
> default ping of the db per connect().
Oh, you're right I wasn't thinking about that. It is important in a
benchmark to be testing equivalent functionality as much as possible,
although it's very difficult to do.
>
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
Dennis Haney wrote:
>>The bias in the test is even a little slanted towards the JSP
>>benchmarks since the trivial connection pooling I used there is
>>nothing like the Apache::DBI overhead in the mod_perl test, when I
>>could have just used a persistent global $dbh instead. ( maybe I
>>should? )
> The bias in the test is even a little slanted towards the JSP
> benchmarks since the trivial connection pooling I used there is
> nothing like the Apache::DBI overhead in the mod_perl test, when I
> could have just used a persistent global $dbh instead. ( maybe I
> should? )
I believe you shou
Hey,
The Apache Hello World Benchmarks are updated at:
http://chamas.com/bench/
They now include 2 C Apache API benchmarks which show the fastest
the benchmarks can run at, and how mod_perl is not much slower!
Also included is a new HelloDB benchmark which is a trivial
connection/query of
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"
Hi again,
Maybe I read it wrong. The list from httpd -l
included mod_perl, but not mod_php. Is the list,
titled 'Compiled-in modules' those modules which are
internal to Apache as the name implises. If so, then
I am running mod_perl internally and mod_php
externally.
Please advise. Thanks.
Hi David,
Guess I am running mod_perl internally. Great.
Thanks.
John Kolvereid
--- David Wheeler <[EMAIL PROTECTED]> wrote:
> On 4/9/02 8:24 AM, "John Kolvereid"
> <[EMAIL PROTECTED]> claimed:
>
> > These are GREAT URLs for installing mod_perl. I
> > wish I would have known
John Kolvereid wrote:
> Hi Stas,
> These are GREAT URLs for installing mod_perl. I
> wish I would have known about them sooner. Whatever.
> After reading the DSO section I'm not sure I have
> configured mod_perl as DSO. In fact, I'm not sure
> what I DO have. The article mentions using:
>
On 4/9/02 8:24 AM, "John Kolvereid" <[EMAIL PROTECTED]> claimed:
> These are GREAT URLs for installing mod_perl. I
> wish I would have known about them sooner. Whatever.
> After reading the DSO section I'm not sure I have
> configured mod_perl as DSO. In fact, I'm not sure
> what I DO have.
h
Hi Stas,
These are GREAT URLs for installing mod_perl. I
wish I would have known about them sooner. Whatever.
After reading the DSO section I'm not sure I have
configured mod_perl as DSO. In fact, I'm not sure
what I DO have. The article mentions using:
use DSO=1
for the All-in-one Way,
John Kolvereid wrote:
> Hi everyone,
>After a gruelling 2 weeks of frustration, I am
> finally able to install mod_perl in my environment.
Congrats John :)
>To the best of my knowledge I am now running
> mod_perl w/ DSO. This seems to be contraversial.
> Some say use it, others say av
Hi everyone,
After a gruelling 2 weeks of frustration, I am
finally able to install mod_perl in my environment.
W/ all your help I did it w/ the following Apache
configuration:
SSL_BASE=../openssl-0.9.6b \
configure \
--prefix=/usr/local/apache \
--enable-module=i
Perrin Harkins wrote:
>
> on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote:
> > It has been a while, but here's a new set of Hello World benchmarks!
>
> There was a recent announcement of HTML::Template::JIT, and Template Toolkit
> has an XS option now.
on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote:
> It has been a while, but here's a new set of Hello World benchmarks!
There was a recent announcement of HTML::Template::JIT, and Template Toolkit
has an XS option now. Any chance you could put those into the next round?
- Perrin
Hey, [[ NUMBERS ARE BELOW ]]
It has been a while, but here's a new set of Hello World benchmarks!
What took me so long in getting these out is that the java web environments
that I had set up would keep crashing during the tests in ways that would
not only render their benchmarks meanin
Ray and Lara Recendez wrote:
> I am trying to get Apache::Hello to work.
<...>
> #!/usr/local/bin/perl
Turn PerlWarn On as described here:
http://perl.apache.org/src/mod_perl.html#SWITCHES
Also try running Apache in single-user mode:
/usr/local/apache/bin/apachectl -X
This he
On Mon, 17 Sep 2001 13:15:44 -0700
Ray and Lara Recendez <[EMAIL PROTECTED]> wrote:
> # vi Hello.pm
> "Hello.pm" 26 lines, 392 characters
> package Apache::Hello;
> # File: Apache/Hello.pm
>
> use strict;
> use Apache::Constants qw(:common);
>
>
PLEASE HELP.
I am trying to get Apache::Hello to work. I saved it as Hello.pm in
lib/perl/Apache. Below are my setup files and pertinent info. When I access
the virtual location (hello/world) from Apache's root directory, my browser
returns the following message: "The document c
Hey,
It seemed that running the hello world benchmarks last time for only
60 seconds had problems with reproducibility, especially with mod_caucho.
So here's some numbers for ~ 10 minute run. Its actually something
like 20 benchmarks run for 30 seconds a piece, and the results s
s, before
doing the real benchmark where the results are scored.
This allows any system caching to be done before the
numbers start counting.
However, despite the new -prime setting, I was still not
getting reproducable resin/mod_caucho results, varying
from 80 hits/sec one run to 280 hits
On Wed, 11 Jul 2001, Philip Mak wrote:
> And sorry for my newbie-ish question, but what is the difference
> between "mod_perl handler" and "Apache::Registry mod_perl"?
http://perl.apache.org/guide/performance.html#Apache_Registry_PerlHandler_vs_
including the benchmarks
___
Perrin Harkins wrote:
>
> > I do feel that compile time matters, but really with 60 seconds
> > and high MaxRequestsPerChild, these systems are getting plenty
> > of compiling caching.
>
> The thing is, if mod_caucho takes 5 seconds the first time it hits each
> template, but is the fastest afte
> I do feel that compile time matters, but really with 60 seconds
> and high MaxRequestsPerChild, these systems are getting plenty
> of compiling caching.
The thing is, if mod_caucho takes 5 seconds the first time it hits each
template, but is the fastest afterwards, these numbers don't give a ve
Perrin Harkins wrote:
>
> > mod_caucho
> > used to look a lot faster, but my testing methodology changed.
> > I used to take the results of the second benchmark run, and
> > publish those, but this time only ran the -test for minor
> > caching after starting resin ( & tomcat ). S
Good work as usual, Joshua.
> mod_caucho
> used to look a lot faster, but my testing methodology changed.
> I used to take the results of the second benchmark run, and
> publish those, but this time only ran the -test for minor
> caching after starting resin ( & tomcat ). So, I'
Good work as usual, Joshua.
> mod_caucho
> used to look a lot faster, but my testing methodology changed.
> I used to take the results of the second benchmark run, and
> publish those, but this time only ran the -test for minor
> caching after starting resin ( & tomcat ). So, I'
ut what is the difference
> between "mod_perl handler" and "Apache::Registry mod_perl"?
Check out the full code in the benchmarks at:
http://www.chamas.com/bench/hello.tar.gz
For the hello tests, one is an Apache::Registry run
CGI script, and the other a small mod_perl
One thing caught my eye; how come "mod_perl handler" (808.4 hits per
second) performed better than "HTML static" (768.2 hits per second)?
And sorry for my newbie-ish question, but what is the difference
between "mod_perl handler" and "Apache::Registry mod_perl"?
Hey,
The latest Hello World benchmarks at available at:
http://www.chamas.com/bench/hello.tar.gz
To reproduce the BELOW results on your platform, for
whatever tests are available, run:
./bench.pl -test
./bench.pl -version -time=60
--Josh
DISCLAIMER: these benchmarks test only what they
Doug asked that I add some plain 'ol mod_cgi tests
to compare mod_perl to, so here you go!
hello]# ./bench.pl -time 10 CGI
Test Name Test File Hits/sec Total Hits Total Time
sec/Hits Byte
I have an update already ... Matt kindly told me to lose the
AxDebug 10 setting, now AxKit easily beats Apache::ASP
on the XSLT benchmark. Also, I have some new Tomcat/mod_jserv
benchmarks for Hello World and Hello World 2000.
As before, you can download the benchmarks at
http
Hey,
I have released the latest Hello World benchmark suite, which you
can find at http://www.chamas.com/bench/hello.tar.gz ... Enjoy!
--Josh
CHANGES
1) Apache::Registry Hello World 2000 benchmark added, fastest of group,
showing perl's raw template rendering power!
2) New XSLT
rl vs. speedy
because of the speedy architecture.
hello]# ./bench.pl -time 10 cgi.pm speedy
...
Test Name Test File Hits/sec Total Hits Total Time sec/Hits
Bytes/Hit
-- -- -- -- --
--
A
Joshua Chamas wrote:
> The Hello World 2000 benchmark is complete, and my results are below
Kind of harsh results for Template Toolkit, but it makes sense given the
nature of the test. Variable interpolation in TT provides extra
functionality to give transparent access to method calls, coder
Hey,
The Hello World 2000 benchmark is complete, and my results are below
along with the Hello World benchmark. Please feel free to contribute
h2000 benchmarks for any environment, or suggest changes for those
in the test suite, download at http://www.chamas.com/bench/hello.tar.gz
The h2000
On Thu, Jan 04, 2001 at 09:55:39AM -0500, Blue Lang wrote:
> Eh, ab isn't really made as anything other than the most coarsely-grained
> of benchmarks. Concurrency testing is useless because it will measure the
> ratio of requests/second/processor, not the scalability of requests from
> single to
On Thu, 4 Jan 2001, Roger Espel Llima wrote:
> JR Mayberry <[EMAIL PROTECTED]> wrote:
> > Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> > how horrible it is on SMP, I think some tests showed it uses as litle as
> > 25% of the second processor..
>
> A simple benchmark wit
JR Mayberry <[EMAIL PROTECTED]> wrote:
> The Modperl handler benchmark, which was done on a dual P3 500mhz on
> Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> how horrible it is on SMP, I think some tests showed it uses as litle as
> 25% of the second processor..
It's an
Modperlers...,
Hello, this is Shane Nay, I used to post quite a bit. (Hello Josh, Stas,
Peren, Doug, and many others of course) BTW Stas,
$contributors=~/Shane/Shane Nay/;, and big Thanks .
Well I'm posting now, (and resubscribed :) because I need someone to fill a
modperl develop
On Mon, 18 Dec 2000, Joshua Chamas wrote:
> The rand() is only in there to prevent a language compiler
> from rendering the whole thing static if it were able to
> guess that all of the variables would be knowable by
> unwinding the for loops.
Instead of using a random number, why don't you pa
[EMAIL PROTECTED] wrote:
>
> On Mon, Dec 18, 2000 at 10:37:16AM -0800, Joshua Chamas wrote:
> >
> > Please feel free to run the tests yourself, and if you give
> > me the results, I'll be sure to post them at a later date
> > at http://www.chamas.com/bench/ . You can grab the benchmarks
> > from
On Mon, Dec 18, 2000 at 10:37:16AM -0800, Joshua Chamas wrote:
>
> Please feel free to run the tests yourself, and if you give
> me the results, I'll be sure to post them at a later date
> at http://www.chamas.com/bench/ . You can grab the benchmarks
> from http://www.chamas.com/bench/hello.tar
Gunther Birznieks wrote:
>
> And a partridge in a pear tree :) Sorry... it's just stupid xmas carols.
>
You've got the spirit. :)
> Anyway, if you are splitting out the DB side for later then why not do the
> same for language features and template features? Here they are both rolled
> int
JR Mayberry wrote:
>
> I strongly dislike the benchmarks on the below URL, its very
> misleading..
>
> The Modperl handler benchmark, which was done on a dual P3 500mhz on
> Linux does serious injustice to mod_perl. Anyone who uses Linux knows
> how horrible it is on SMP, I think some tests show
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,
>
At 03:53 PM 12/17/00 -0800, Joshua Chamas wrote:
>Hey,
>
>
> 2+ levels of code layering
> 1 rand() value per request
> 6 for loops executed
> 20 additions (float & integer)
> 10 lval assignments
> 200 variables inline
> 202+ chuncks of static html rendered
> Over 2900 byte template
Perrin Harkins wrote:
>
> This sounds great, but the code snippet you included makes it look like
> the rand() value will have an effect on the number of bytes returned.
> This is probably not a good idea, since that would allow many other
> factors to affect the results. I suggest making sure t
Joshua Chamas wrote:
> The first of these runtime benchmarks is geared towards templating
> or embedded environments like ASP,PHP,Embperl,JSP,Mason ... the
> Hello World 2000 benchmark below has these characteristics:
>
> 2+ levels of code layering
> 1 rand() value per
Joshua Chamas wrote:
>
> Hey,
>
> I'd like some comments on the Hello World 2000 benchmark that
> I am creating. One of the great failings of the Hello World
> benchmark is that it doesn't address the runtime execution
> of various web application environments.
&
Hey,
I'd like some comments on the Hello World 2000 benchmark that
I am creating. One of the great failings of the Hello World
benchmark is that it doesn't address the runtime execution
of various web application environments.
Perl is oft stated to provide better runtime executi
testing Caucho's JSP last year is that they
do a really good job of generating efficient servlets from JSP. I was
not able to write a faster "hello world" servlet than the one they
auto-generated from a JSP page.
By the way, as a cautionary tale on "hello world" tests
Hi all,
On Sun, 17 Dec 2000, Gerald Richter wrote:
> there are so many factors, so they are very difficult to compare.
True. But nevertheless I think it's a very useful bit of work because
the thing that stands out is that all (server) dynamic content comes at
a high cost in processor cycles.
> benchmarks. All the other mod_perl tools seem slower.
>
Everybody looking at this tests should be aware that it only test the
startup/setup overhead for a "null" request. The Hello World actualy does
nothing, so it highly depends on what features are initialized at the start
of the requ
d_perl handler according to the
> benchmarks. All the other mod_perl tools seem slower.
>
I'm preparing a Hello World 2000 test which will test the runtime
properties of an environment. It will be relevant to the dynamic
template environments like ASP, Mason, Embperl, TT, JSP, PHP...
early
gt;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
> pe
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
On Mon, Dec 11, 2000 at 10:14:56PM -0800, Joshua Chamas wrote:
> [EMAIL PROTECTED] wrote:
> >
> > Could you please explain the differences between
> > CGI Raw and CGI.pm? I'm using oo method of
> > CGI.
> The Raw CGI test makes no use of CGI.pm, just issues raw print
> statements that sets up
On Tue, 12 Dec 2000, Jeremy Howard wrote:
> Joshua Chamas wrote:
> > If you are using CGI.pm object methods, I would worry about calling
> > all those methods to build your HTML and if you are performance
> > minded, I would use them frugally.
> >
> IIRC, CGI.pm is actually slower to run the func
Joshua Chamas wrote:
> If you are using CGI.pm object methods, I would worry about calling
> all those methods to build your HTML and if you are performance
> minded, I would use them frugally.
>
IIRC, CGI.pm is actually slower to run the functional syntax than the object
syntax. This is because a
ts from the other day with the Template Toolkit
> > benchmark properly optimized, thanks Perrin!
> >
> > The reference for these numbers is at: http://www.chamas.com/bench
> > If you would like the hello test suite, please email me separately.
> >
See http://www.chamas.com/b
ed, thanks Perrin!
>
> The reference for these numbers is at: http://www.chamas.com/bench
> If you would like the hello test suite, please email me separately.
>
> ]# ./bench.pl -time=60
>
> Test Name Test FileHits/sec
Hey,
Updated results from the other day with the Template Toolkit
benchmark properly optimized, thanks Perrin!
The reference for these numbers is at: http://www.chamas.com/bench
If you would like the hello test suite, please email me separately.
]# ./bench.pl -time=60
Test Name
Joshua Chamas <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> >
> > IME, simple mod_perl handlers typically run around 50% as fast as
> > HTML static pages. Your hello world benchmark seems to be slightly
> > misleading in this respect, since the content-le
Joe Schaefer wrote:
>
> IME, simple mod_perl handlers typically run around 50% as fast as
> HTML static pages. Your hello world benchmark seems to be slightly
> misleading in this respect, since the content-length is small
> relative to the header size.
>
I'll send
Joshua Chamas <[EMAIL PROTECTED]> writes:
> RESULTS:
>
> [hello]# ./bench.pl -time=60
> ...
> Test Name Test FileHits/sec Total Hits Total Time Total
>Bytes
>
"Alexander Farber (EED)" wrote:
>
> Hi Joshua,
>
> you sort the table at http://www.chamas.com/bench/ by Hits/s,
> but the ModPerl Handler was tested on PIII-500 x 2 and the Java
> thingies below - only PII-266.
>
> Is it an intended joke or do I misunderstand something?
>
The first page is m
Hi Joshua,
Joshua Chamas wrote:
> Note, this is the first benchmark that I've run of Apache::ASP on
> Linux, which is nice to see because Linux is one of the faster OS's,
> and it now looks bit more of a player, compared to what's listed at
> http://www.chamas.com/bench/ when I benched it on Sola
Gunther Birznieks wrote:
>
> Then it seems odd that there is such a huge discrepency between CGI.pm and
> no CGI.pm. If you preload CGI.pm in startup.pl does the difference go away?
>
I did preload CGI.pm. I'll send you the hello world
suite separately since you seem curio
f? Or using the Apache::args,
> > Apache::Request::param mechanism?
> >
>
>In the hello world scripts, there is no get/post processing as
>part of the benchmark. Here's the code that's run:
>
> http://www.chamas.com/bench/#perlrawcgi
>
>The general language
On Mon, 11 Dec 2000, Joshua Chamas wrote:
> Lastly, I was unable to get AxKit to run without segfaulting ...
http://axkit.org/faq.xml
Either you're running PHP on that server, or you have an Apache with expat
included. Do "nm /path/to/apache/bin/httpd | grep -i XML" to find out if
the latter is
Gunther Birznieks wrote:
>
> Is CGI Raw decoding the get/post yourself? Or using the Apache::args,
> Apache::Request::param mechanism?
>
In the hello world scripts, there is no get/post processing as
part of the benchmark. Here's the code that's run:
http://www.chamas
Is CGI Raw decoding the get/post yourself? Or using the Apache::args,
Apache::Request::param mechanism?
At 02:13 AM 12/11/2000 -0800, Joshua Chamas wrote:
>Hey,
>
>I have automated a portable Hello World test suite, but its not
>CPAN ready, so if any would like to contribute, run,
Hey,
I have automated a portable Hello World test suite, but its not
CPAN ready, so if any would like to contribute, run, and comment
on the sources, give me a holler & I'll send them to you. What
it does is fire up a lean apache on a high port with only the
config necessary t
On Wed, 13 Sep 2000, Jason wrote:
> I need a simple script that will test to see if these are working on my
> server.
>
>
>
Visit the Apache::ASP homepage, there are a lot of examples there
including the httpd.conf modification you may need.
Jason wrote:
>
> I need a simple script that will test to see if these are working on my
> server.
You need to know how to work with Apache for setting up
general permissions. The .htaccess file in the
Apache::ASP ./site/eg folder will give you some clues.
So will: http://www.apache-asp.org/i
I need a simple script that will test to see if these are working on my
server.
Hi guys,
I am new to unix world and really need help from you.
I am in the process of installing mod_perl 1.24 for the webserver that we
are running here. I am running freebsd 4.0 and stronghold.
I have no problem running "perl Makefile. PL", but when i run "make", I keep
getting the following e
On Thu, 10 Aug 2000, Ken Williams wrote:
> To clarify - some handlers can be called using object-oriented
> techniques, and some can't. The switch for this behavior is that the
> handler is prototyped with ($$).
or with newer Perls:
sub handler : method {...}
Ah I C, said the Perl man!
Thank you for the clarification.
At 09:55 AM 8/10/00 -0500, you wrote:
>[EMAIL PROTECTED] (G.W. Haywood) wrote:
>
>>Hi there,
>>
>>On Wed, 9 Aug 2000, George Sanderson wrote:
>>
>>> PerlModule Apache::Hello
>>>
>>&
[EMAIL PROTECTED] (G.W. Haywood) wrote:
>Hi there,
>
>On Wed, 9 Aug 2000, George Sanderson wrote:
>
>> PerlModule Apache::Hello
>>
>> SetHandler perl-script
>> PerlHandler Apache::Hello->handler
>>
>> #
>> Results in the followi
Hi there,
On Wed, 9 Aug 2000, George Sanderson wrote:
> PerlModule Apache::Hello
>
> SetHandler perl-script
> PerlHandler Apache::Hello->handler
>
> #
> Results in the following error_log output:
> [Sun Aug 6 21:48:02 2000] [error] Undefined subroutine
> &a
I have Apache 1.3.12 using mod_perl 1.24 as a DSO, built with Perl 5.6.0
which is running on Linux 2.2.14.
When the following is presented in the httpd.conf file:
#
PerlModule Apache::Hello
SetHandler perl-script
PerlHandler Apache::Hello->handler
#
Results in the following error_log out
1 - 100 of 120 matches
Mail list logo
