[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] Performance degarde on using caching option
|
You replaced a static named query using SQL, with a dynamic query using query
by example. Try instead replacing it with a static JPQL named query and set
the cache-usage as a query hint in the named query definition.
Depending on the cache size, and the speed of your database, it still may be
slower. The cache is only indexed by primary key, so if your database is
indexing these fields, and there are a lot of objects in the cache, then it
may outperform the in-memory query. What database are you using, and how
many objects are in your cache?
Another option is to use a query cache instead of in-memory querying. You
can enable a query cache on the query through query hints. The query cache
is indexed by the parameters, so it will be an indexed lookup, not a scan.
Kiran Kumar Gubbi wrote:
>
> The original query used to get the sample detail for every request from
> the database using NamedNativeQuery and no cache annotations are added to
> Sample entity.
>
>
> @NamedNativeQuery
> (
> name = Sample.FIND_PROPERTY_BY_KEY,
> query = "select * from Sample "
> + "where NonPromaryKeyProperty1= ?1 and NonPromaryKeyProperty2 = ?2 "
> + "or NonPromaryKeyProperty1 = ?1 and NonPromaryKeyProperty2
> is null "
> + "and not exists ( select 1 from property_tbl "
> + "where NonPromaryKeyProperty1 = ?1 and NonPromaryKeyProperty2 = ?2 )",
> resultClass = Sample.class
>
> )
>
> and the DAO method is
>
>
> public String getProperty( final String NonPromaryKeyProperty1, final
> String NonPromaryKeyProperty2)
> {
> Query query = em.createNamedQuery( Sample.FIND_PROPERTY_BY_KEY );
> query.setParameter( 1, NonPromaryKeyProperty1);
> query.setParameter( 2, NonPromaryKeyProperty2);
> try
> {
> Sample prop = ( Sample) query.getSingleResult();
> return prop != null ? prop.getPropertyValue() : null;
> }
> catch ( NoResultException e )
> {
> return null;
> }
> catch ( NonUniqueResultException e )
> {
> throw new RuntimeException( "Multiple properties found with key: " +
> NonPromaryKeyProperty1
> + " and scheme: " + NonPromaryKeyProperty2, e );
> }
>
> }
>
>
> If I want to use cache to imporove the performace what's the better way of
> implementing ?
>
>
> Thanks,
> Kiran
>
>
> christopher delahunt wrote:
>>
>> Are you indicating that there is problem, or just trying to explain your
>> results?
>>
>> More information is required. Is there a reason you are using the
>> checkCacheOnly option instead of the default? What are you using for
>> the original query as a comparison? If you mean the original query was
>> a straight SQL select that goes to the database compared to this, the
>> SQL query will go to the database and the rows returned used to get the
>> objects from the cache. This current query will not hit the database at
>> all, due to the checkCacheOnly option being used. Instead, it will go
>> through every single Sample object it has in the cache and check to see
>> if the NonPromaryKeyProperty1.equals("kk") and
>> NonPromaryKeyProperty2.equals("jj") until it finds what it is looking
>> for. The speed this is done is affected by the processor, application
>> load and the number of objects in the cache, even the how the JVM
>> implements string comparisons. At some level of JVM load, at some
>> number of objects in the cache etc, it will be expected that the in
>> memory query will be slower than a query that uses the database. Using
>> a more powerful processor on a JVM with no load and infinite resources
>> in a cache of very limited size (say 1 object), I might expect the in
>> memory query to be faster - assuming the java string comparisons can be
>> done faster than the time it requires to send a JDBC statement to the
>> database and get a result back. There are better options to use for
>> performance depending on what you are attemping.
>>
>> Best Regards,
>> Chris
>>
>>
>>
>>
>>
>> On 23/07/2010 10:32 AM, Kiran Kumar Gubbi wrote:
>>> After changing queries from nativequery to sessionquery the performance
>>> of
>>> the application drastically degraded. Used the following setting for
>>> entity
>>> and data access object for caching.
>>>
>>> Entity class
>>>
>>> @Cache(
>>> type = CacheType.SOFT,
>>> shared = true,
>>> size = 10000,
>>> coordinationType = CacheCoordinationType.SEND_OBJECT_CHANGES
>>> )
>>>
>>>
>>> DAO method ( before calling this methops List of sample objects are
>>> available in cache)
>>>
>>> public Sample getSample() {
>>> Sample sample = new Sample();
>>> sample.setNonPromaryKeyProperty1("kk");
>>> sample.setNonPromaryKeyProperty2("jj");
>>>
>>> ReadObjectQuery query = new ReadObjectQuery( Sample.class );
>>> query.setExampleObject( sample);
>>> query.checkCacheOnly();
>>>
>>> return ( Sample ) session().executeQuery( query );
>>> }
>>>
>>> This change has degraded performance by 3 times. Any suggestion please.
>>>
>>>
>>> Kind regards,
>>> kiran
>>>
>>>
>>
>
>
-----
http://wiki.eclipse.org/User:James.sutherland.oracle.com James Sutherland
http://www.eclipse.org/eclipselink/
EclipseLink , http://www.oracle.com/technology/products/ias/toplink/
TopLink
Wiki: http://wiki.eclipse.org/EclipseLink EclipseLink ,
http://wiki.oracle.com/page/TopLink TopLink
Forums: http://forums.oracle.com/forums/forum.jspa?forumID=48 TopLink ,
http://www.nabble.com/EclipseLink-f26430.html EclipseLink
Book: http://en.wikibooks.org/wiki/Java_Persistence Java Persistence
--
View this message in context: http://old.nabble.com/Performance-degarde-on-using-caching-option-tp29247519p29336557.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.
