Performance and scalability: Performance tuning in Data retrieval
- Posted by: suresh done
- Posted on: December 18 2002 17:47 EST
If run a query in oracle it takes around 7 sec. But the same query in my application takes 40 sec (of course it is total time taken to present to the client). We are using J2EE multi-tier architecture and weblogic app server.I understand that there will network overhead and all,but I observed that looping through the resultset and preparing the value object is also consuming time.Is there any coding pratice to optimize this time,or any other optimisation techniques to be followed.Any valuable suggestions are welcome
- Performance tuning in Data retrieval by Venkatraman Balasubramanian on December 24 2002 15:44 EST
- Performance tuning in Data retrieval by Tracy Prince on January 08 2003 16:03 EST
Find the total number of hoops in delivering the page. That would give a good insight of which tier is consuming more time. Have this application been profiled before?
If coarse grained objects are returned with values not used by the presentation tier, try to refactor the value objects.
If the tiers/transactions involved from retrieving the data and till presenting it are thread safe by themselves, avoid using thread safe data holders (use ArrayList/HashMap instead of Vector/Hashtable).
Try to see, if some of the data can be cached in the JVM, of course it would be tricky in a clustered environment. Have a look at Coherance from Tangosol
Try to reuse resources. For example, reuse JNDI Context, database connections.
The type of JDBC driver can make significant difference in the throughput. Try to use native/optimized JDBC drivers for the database.
Avoid using column names to retrieve the values from the resultset.
As soon as possible, close the unused Statement and ResultSet objects or any other resource for that matter.
Tuning the indexing/sorting mechanism of the SQL can also help. See if you can optimize the response time of the SQL by adding hints to the SQL/database. 7 seconds in a web based application could be termed as slow.
I hope that this helps. Let me know, if you get some more hits.
In lieu of attempting in-process caching either in-house or through a third party vendor, look into a software solution called Apptimizer provided by Chutney Technologies. It allows for objects to be shared and persisted in an out of process storage engine. Unlike in-process caching mechanisms that require significant amount of synchronization and cause large amounts of garbage collection overhead, Chutney's product requires no synchronization and can minimize GC costs. Hope this helps.
Tracy: "look into a software solution called Apptimizer provided by Chutney Technologies"
Apptimizer is a non-Java (non-JCache) client/server-based content caching system. It is reasonably good for caching web pages if there are no complex data dependencies, but at $150,000 per Chutney server (plus $5000/CPU on the Java app server) it's a bit pricey for content caching. Since it's a client/server model, it also competes with similar home-grown solutions using Java and RMI, as well as open source solutions like OSCache.
Tracy: "Unlike in-process caching mechanisms that require significant amount of synchronization and cause large amounts of garbage collection overhead, Chutney's product requires no synchronization and can minimize GC costs."
So it doesn't support any synchronization? Maybe that's not too important for page caching.
Or did you mean data replication? JCache specifies both full replication and also distributed caches. Using Coherence, for example, you can move _all_ the cache data out of the application server JVM, or cache only a small (configurable) amount in the JVM (MRU- & MFU-based) with the rest remote, fully replicate the cached data, or distribute it evenly over the cluster.
Also, most Java cache products also support alternative spooling methods. For example, our Coherence product supports cache storage in-process (in-memory) but off the Java heap (up to 2GB of data per named cache) or even in memory-mapped files. Oracle's content caching system (which competes with Chutney's) supports file spooling of caches.
Hope it helped!
Coherence: Easily share live data across a cluster!
I respect the fact that TangoSol spams everyone on this board with their product info, b/c we all have to make a buck.
But, when you bash Chutney's product with inaccurate information for TangoSol's gain, I feel you have crossed the line. You are taking the integrity out of this discussion forum with your incessant sales pitches.
Chutney is well beyond a page cache, and anyone who can read a whitepaper can see the breadth of our uses at http://www.chutneytech.com/tech/whitepapers/index.cfm ("debunking the myth"). It is a very informative description with real production examples of the functionality of Apptimizer. Chutney is a centralized object repository that is used in mission critical applications, including non-caching based applications. In fact, many of our clients, including Merrill Lynch, JPMorganChase, Sabre, Marsh, and OfficeMax would take offense to your limited description of our product.
Your pricing info is inaccurate as well. Cameron, get your facts straight.
Director of Sales, Chutney
If any of the information that I provided was incorrect, I apologize and would be glad to discuss it with you so I can avoid making the same mistake in the future. Please contact me at your convenience, or perhaps we could meet at the upcoming Wall Street on Java show.
Regarding my post, all the information I have on Chutney is from Chutney white papers, potential customers that received sales pitches from Chutney and Internet sites that reviewed the product. For example:
"But at $100,000 per server plus $5,000 per CPU for these services, it will cost."
"COST HA, $150,000; Standard $100,000; Developer SOAP library $795; additional libraries $5,000 per CPU"
I found the same information repeatedly on different reputable sites, including the supposition that Chutney is focused on content caching, and various technical information was backed up by information in Chutney's own position papers. Regarding synchronization (concurrency control), "Tracy" mentioned that Chutney did not support it. I was not aware whether Chutney supported it or not, as I indicated in my statement above.
Coherence: Easily share live data across a cluster!