db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Monroe" <Greg.Mon...@DukeCE.com>
Subject RE: performance
Date Thu, 03 Nov 2005 15:02:33 GMT
> 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

View raw message