Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB

2002-07-31 Thread Ged Haywood

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 pages, and make use of any chaching schemes which are likely
to be available.  That's a lot of work.  Unless you're prepared to do
something like that more or less for kicks, I think that what you've
done up to now is about as good as it's going to get.

73,
Ged.






Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB

2002-07-30 Thread Perrin Harkins

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? )
 
 
 I believe you should. It is the most common setup using mod_perl, if
 you are concerned about performance, anyway.

I think you got confused by the wording.  The most common setup with 
mod_perl is to use Apache::DBI, which is what he used in the test.

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.

- Perrin




Re: [ANNOUNCE] Apache Hello World Benchmarks - Apache C API, HelloDB

2002-07-30 Thread Josh Chamas

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] Apache Hello World Benchmarks - Apache C API, HelloDB

2002-07-30 Thread Perrin Harkins

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.

 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

I thought that JDBC had a pooling capability now.  I also thought Resin 
had something built in.  I would use those if possible.

Stick with Apache::DBI for mod_perl though.  I would never tell anyone 
to roll their own database persistence for performance instead of using 
Apache::DBI.  Pinging the database connection is good, and all systems 
should do it if they don't already.

- Perrin