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 Mon, 07 Nov 2005 22:21:55 GMT
Sorry for delay... took a 3 day weekend and just getting caught up.

Yes, I use SharedPoolDataSourceFactory, which uses the Apache 
commons-pool code under it.

If you're using a JNDI source, then pooling would be handled by
the JNDI source settings.

> -----Original Message-----
> From: Robert Kromkamp
> 
> Or do mean using the SharedPoolDataSourceFactory instead of 
> other ones?
> 
> -----Original Message-----
> From: Robert Kromkamp
> 
> 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
> 
> 
> > 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.
> 
> Greg
> 
> 
> 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
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message