Re: Cache Hit-Rate Statistics
Hi Pinaki, Thank you very much for this information. I must admit, I did not realize there were two distinct caches (L1 and L2). Furthermore, I am not that familiar with JPA 2.0 yet. (I will look into it.) As you say in your article: "Everyone loves cache", and I am certainly excited about it. I can feel that I still need to learn quite a bit about JPA (v1.0 and v2.0), and therefore I appreciate your pointers greatly! Thank you very much for your support. Regards Riaan -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4268700.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Cache Hit-Rate Statistics
Hi Riaan, > Apache OpenJPA looks like a high-quality, feature-rich, open source > product. My thanks go out to the > OpenJPA developers! Good to know that you have found OpenJPA useful. > I plan to use the persistence context in the *Extended* mode, as opposed > to "per transaction" or "per session". In other words, for my application, > I want the data cache and the query cache to be available throughout the > full life cycle of the application back-end. By definition, DataCache or L2 cache lifetime is bound to persistence unit (a.k.a EntityManagerFactory) and not to a persistence context (a.k.a EntityManager). "Extended" mode refers to lifetime of L1 cache which is not the same as L2 cache. You can find some discussion on their differences in [1]. [1] http://ppoddar.blogspot.com/2009/10/l2-cache-in-jpa-20-and-openjpa-plug-in.html Riaan wrote: > > Hi, > > I am new to Apache OpenJPA, but not new to the concept of persistence > layers in Java. > (I have played a little bit with Hibernate and TopLink in the past, > ...without paying any attention to their cache schemes at the time.) > > After beginning to understand the value of having an *extended* data cache > and query cache, I was drawn to Apache OpenJPA, because of the DataCache > and QueryCache features built into it. > > I am busy writing my first proof-of-concept application using OpenJPA, and > I have written some Java code to interrogate the DataCache and QueryCache > instances at run-time. I find this very interesting, and the goal is to > gather *Cache Hit-Rate Statistics* from a running application. > > What I would like to see, are the following four metrics: > > Data Cache Hit Count: > Data Cache Miss Count: > Query Cache Hit Count: > Query Cache Miss Count: > > In order to obtain values for the above four metrics, I downloaded the > OpenJPA 1.2.1 source code, and hacked in counters, and modified the source > code to update (increment) the counters when necessary. > > This worked for me, and it gave me the information that I was looking for, > but my solution is (obviously) not ideal, because of the following > reasons: > > a.) Any newer version of OpenJPA will not contain my hacks, and I would > have to modify the source code again. > > b.) Because I don't fully understand the OpenJPA source code, my > modification may not be optimal. (This is an understatement.) Although it > works, and it gives me the answers I was looking for, I really don't feel > that confident about my source code changes. > > c.) I suspect my changes may not even work properly the moment there are > more than one EntityManager or Persistence Unit in the same JVM. {I say > this, because my counters are defined as static attributes on some of the > OpenJPA classes. This is bad, I know.} > > Anyway, here are my questions: > > 1.) Is there currently a proper and correct way of obtaining values for > the above four cache performance metrics, that I am interested in, in > order to monitor a running application? > > 2.) If there is currently no standard way in OpenJPA to get values for > these cache performance metrics, what is the chance that the OpenJPA > developers could add these in, so that these metrics can be used by all > OpenJPA users in the future? > > 3.) I guess what I am asking for, is probably not part of the Java EE > Persistence API specifications. What I am suggesting, is additional > features for Apache OpenJPA, ...if it is not already there. How does other > people feel about adding these features to the OpenJPA cache classes? I > would like to hear some thoughts on this from other users as well. > > > Just a few comments from my side: > > A.] Database roundtrips are expensive, and it is a great win whenever a > database roundtrip can be avoided. (This is obviously a great benefit of > having data cache and query cache providers.) > > B.] Because cache-hits are so precious, it makes good sense to monitor > cache-hits and cache-misses in a running application. The application > developer could write functions to extract these performance metrics on > demand. > > C.] I would love to see "Cache Performance Metrics" (as listed above) as a > standard feature of OpenJPA, to be used by all OpenJPA users. > > D.] I plan to use the persistence context in the *Extended* mode, as > opposed to "per transaction" or "per session". In other words, for my > application, I want the data cache and the query cache to be available > throughout the full life cycle of the application back-end. This way, the > data cache and the query cache can be *shared* by *all* the application > users. This will hopefully save a lot of database roundtrips. > > E.] Apache OpenJPA looks like a high-quality, feature-rich, open source > product. My thanks go out to the OpenJPA developers! > > > Regards > Riaan > South Africa > - Pinaki -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4268214.html
Re: Cache Hit-Rate Statistics
Hi Pinaki, Thank you very much for this pointer! I am glad to see that the OpenJPA team has already thought of this! I will certainly look at these new features that are available in "OpenJPA 2.0". Regards Riaan -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4267976.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Cache Hit-Rate Statistics
Hi, > 1.) Is there currently a proper and correct way of obtaining values for > the above four cache > performance metrics, that I am interested in, in order to monitor a > running application? Basic L2 Cache statistics are available on later version of OpenJPA [1]. You can download [2] fairly stable nightly builds or 2-0.0-SNAPSHOT versions for this facility. [1] http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_cache_statistics [2] http://openjpa.apache.org/downloads.html Regards -- Pinaki Riaan wrote: > > Hi, > > I am new to Apache OpenJPA, but not new to the concept of persistence > layers in Java. > (I have played a little bit with Hibernate and TopLink in the past, > ...without paying any attention to their cache schemes at the time.) > > After beginning to understand the value of having an *extended* data cache > and query cache, I was drawn to Apache OpenJPA, because of the DataCache > and QueryCache features built into it. > > I am busy writing my first proof-of-concept application using OpenJPA, and > I have written some Java code to interrogate the DataCache and QueryCache > instances at run-time. I find this very interesting, and the goal is to > gather *Cache Hit-Rate Statistics* from a running application. > > What I would like to see, are the following four metrics: > > Data Cache Hit Count: > Data Cache Miss Count: > Query Cache Hit Count: > Query Cache Miss Count: > > In order to obtain values for the above four metrics, I downloaded the > OpenJPA 1.2.1 source code, and hacked in counters, and modified the source > code to update (increment) the counters when necessary. > > This worked for me, and it gave me the information that I was looking for, > but my solution is (obviously) not ideal, because of the following > reasons: > > a.) Any newer version of OpenJPA will not contain my hacks, and I would > have to modify the source code again. > > b.) Because I don't fully understand the OpenJPA source code, my > modification may not be optimal. (This is an understatement.) Although it > works, and it gives me the answers I was looking for, I really don't feel > that confident about my source code changes. > > c.) I suspect my changes may not even work properly the moment there are > more than one EntityManager or Persistence Unit in the same JVM. {I say > this, because my counters are defined as static attributes on some of the > OpenJPA classes. This is bad, I know.} > > Anyway, here are my questions: > > 1.) Is there currently a proper and correct way of obtaining values for > the above four cache performance metrics, that I am interested in, in > order to monitor a running application? > > 2.) If there is currently no standard way in OpenJPA to get values for > these cache performance metrics, what is the chance that the OpenJPA > developers could add these in, so that these metrics can be used by all > OpenJPA users in the future? > > 3.) I guess what I am asking for, is probably not part of the Java EE > Persistence API specifications. What I am suggesting, is additional > features for Apache OpenJPA, ...if it is not already there. How does other > people feel about adding these features to the OpenJPA cache classes? I > would like to hear some thoughts on this from other users as well. > > > Just a few comments from my side: > > A.] Database roundtrips are expensive, and it is a great win whenever a > database roundtrip can be avoided. (This is obviously a great benefit of > having data cache and query cache providers.) > > B.] Because cache-hits are so precious, it makes good sense to monitor > cache-hits and cache-misses in a running application. The application > developer could write functions to extract these performance metrics on > demand. > > C.] I would love to see "Cache Performance Metrics" (as listed above) as a > standard feature of OpenJPA, to be used by all OpenJPA users. > > D.] I plan to use the persistence context in the *Extended* mode, as > opposed to "per transaction" or "per session". In other words, for my > application, I want the data cache and the query cache to be available > throughout the full life cycle of the application back-end. This way, the > data cache and the query cache can be *shared* by *all* the application > users. This will hopefully save a lot of database roundtrips. > > E.] Apache OpenJPA looks like a high-quality, feature-rich, open source > product. My thanks go out to the OpenJPA developers! > > > Regards > Riaan > South Africa > - Pinaki -- View this message in context: http://n2.nabble.com/Cache-Hit-Rate-Statistics-tp4266362p4267778.html Sent from the OpenJPA Users mailing list archive at Nabble.com.