db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Kromkamp <r.kromk...@pagelink.nl>
Subject RE: performance
Date Fri, 04 Nov 2005 08:29:17 GMT
Hi Greg,

Thanks for your answer. I prefer to do something with db connection pooling.
As a understood correctly, you are using another application to deal with
the connection db pooling for torque? Or is it a configuration within
Torque? If you are using another application, can you tell me whcih one you
are using?

Kind regards,

Robert Kromkamp

-----Original Message-----
From: Greg Monroe [mailto:Greg.Monroe@DukeCE.com]
Sent: donderdag 3 november 2005 16:03
To: Apache Torque Users List
Subject: RE: performance

> From: Robert Kromkamp  
> I've got the feeling Torque is al little bit slower than 
> straightforward queries on the database. Are there some way's 
> the improve the performance of torque? By example, use caching?
In general, there is no denying that an abstract layer will always 
be slower than a native layer.  Code written in Assembler language 
will always be faster than Java. But why do you use Java instead
of Assembler? The same reasons that people give for developing in 
Java apply to using Torque over native JDBC. You can develop, 
debug, modify, maintain it faster, better, and cheaper.  Remember,
the cost of developer time can quickly outweigh the cost of more 
hardware in today's economics.

That said, there are some internals that make Torque perform better.
IMHO, number one is using pooled connections. One of the most time
consuming JDBC operation is opening a connection to the SQL server.
Pooling eliminates this by caching open connections and letting code 
share them.  I've seen actual major performance gain by converting 
a native JDBC app that did individual connections to Torque.

There are also internal tweaks that may or may not help such as 
the torque.objectIsCaching property that controls whether data 
objects cache foreign keys or not.  I think there are a couple more
but am not sure.

IMHO, it's REALLY hard to cache at the DB interface level because 
you don't have any application context.  Its really easy to have 
a caching scheme that speeds up one type of application but slows 
down another.  Personally, I favor caching the information at the 
object level in the application.  For example, cache fairly 
static, commonly used web application information in the session.  
Or something that is used repeatedly in processing requests, in 
the request object.  Because this is application context specific, 
it tends to be more efficient.

Well, enough soap-boxing.. hopefully this helps or at least 
raises more specific questions we can deal with.


Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are
confidential communication or may otherwise be privileged or confidential
and are intended solely for the individual or entity to whom they are
addressed.  If you are not the intended recipient you may not rely on the
contents of this email or any attachments, and we ask that you  please not
read, copy or retransmit this communication, but reply to the sender and
destroy the email, its contents, and all copies thereof immediately.  Any
unauthorized dissemination, distribution or copying of this communication is
strictly prohibited.

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org

View raw message