You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ibatis.apache.org by "V.C. (JIRA)" <ib...@incubator.apache.org> on 2006/07/18 01:01:13 UTC
[jira] Created: (IBATIS-324) cache hits/misses
cache hits/misses
-----------------
Key: IBATIS-324
URL: http://issues.apache.org/jira/browse/IBATIS-324
Project: iBatis for Java
Issue Type: New Feature
Components: SQL Maps
Reporter: V.C.
Priority: Minor
It be nice to be able in real time and loged report on cache hits/misses monitoring, size of cache by map name in megs, and report by hour/date # of times a statment was used.
(also log the slow sql statements, like anything that takes more then 1/3 of a seconds to log the statment and arguments).
these are standard managment issues that come up now and then.
i'd consider implementing if that helps.
.V
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-324) cache hits/misses
Posted by "Kjirsten Koka (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-324?page=comments#action_12441190 ]
Kjirsten Koka commented on IBATIS-324:
--------------------------------------
>>>> and report by hour/date # of times a statment was used.
>>
>>That can be added outside of iBATIS. You can inject a proxy between the SqlMapClient interface and the default >>implementation to track these stats. If you build such a thing, we can consider adding it to the framework if others are >>interested.
Recently I ran across JAMon 2.2 (jamonapi.sourceforge.net/) - it has a nifty jdbc driver proxy that can track SQL statements issued by your app, although you probably wouldn't be able to get the exact time a query was run as it aggregates the usage statistics. It is very useful for identifying long-running queries. It will definitely show you how many times a query has been [re-]used, as well as average, min, and max run times.
regards,
Kjirsten
> cache hits/misses
> -----------------
>
> Key: IBATIS-324
> URL: http://issues.apache.org/jira/browse/IBATIS-324
> Project: iBatis for Java
> Issue Type: New Feature
> Components: SQL Maps
> Reporter: V.C.
> Priority: Minor
>
> It be nice to be able in real time and loged report on cache hits/misses monitoring, size of cache by map name in megs, and report by hour/date # of times a statment was used.
> (also log the slow sql statements, like anything that takes more then 1/3 of a seconds to log the statment and arguments).
> these are standard managment issues that come up now and then.
> i'd consider implementing if that helps.
> .V
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-324) cache hits/misses
Posted by "Clinton Begin (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-324?page=comments#action_12421798 ]
Clinton Begin commented on IBATIS-324:
--------------------------------------
>> can you do that please in a svn
I'll look into it. I believe there's a decent way to do it without changing the normal public interface. I'll post it here.
>> memory size, even if inaccurate and only by declared xml name or entire cache size
Let me rephrase my answer: There's NO way to do that in Java.
According to one person: you can estimate it. It's about 15 bytes in overhead per object. You can count 4 bytes for a reference. The primitive sizes are defined in the language (4 for an int, 8 for a double, etcetera).
You'd have to write something that travelled the entire collection and the entire object graph for each entry....that would not be fast if you're talking megabytes worth of data as your original post would suggest.
You might be better off just estimating based on the available memory as reported by the Java runtime.
Cheers,
Clinton
> cache hits/misses
> -----------------
>
> Key: IBATIS-324
> URL: http://issues.apache.org/jira/browse/IBATIS-324
> Project: iBatis for Java
> Issue Type: New Feature
> Components: SQL Maps
> Reporter: V.C.
> Priority: Minor
>
> It be nice to be able in real time and loged report on cache hits/misses monitoring, size of cache by map name in megs, and report by hour/date # of times a statment was used.
> (also log the slow sql statements, like anything that takes more then 1/3 of a seconds to log the statment and arguments).
> these are standard managment issues that come up now and then.
> i'd consider implementing if that helps.
> .V
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-324) cache hits/misses
Posted by "Clinton Begin (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-324?page=comments#action_12421742 ]
Clinton Begin commented on IBATIS-324:
--------------------------------------
>> cache hits/misses monitoring
This is actually already available. We just need to expose the method in the public interface.
http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/src/com/ibatis/sqlmap/engine/cache/CacheModel.java
>> size of cache by map name in megs
There's no reliable way to do this in Java.
>> and report by hour/date # of times a statment was used.
That can be added outside of iBATIS. You can inject a proxy between the SqlMapClient interface and the default implementation to track these stats. If you build such a thing, we can consider adding it to the framework if others are interested.
>> log the slow sql statements, like anything that takes more then 1/3 of a seconds to log the statment and arguments
Same as above. This could be done as a SqlMapClient proxy.
If you want to try the two above as proxies, we'll see where we land with it.
> cache hits/misses
> -----------------
>
> Key: IBATIS-324
> URL: http://issues.apache.org/jira/browse/IBATIS-324
> Project: iBatis for Java
> Issue Type: New Feature
> Components: SQL Maps
> Reporter: V.C.
> Priority: Minor
>
> It be nice to be able in real time and loged report on cache hits/misses monitoring, size of cache by map name in megs, and report by hour/date # of times a statment was used.
> (also log the slow sql statements, like anything that takes more then 1/3 of a seconds to log the statment and arguments).
> these are standard managment issues that come up now and then.
> i'd consider implementing if that helps.
> .V
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IBATIS-324) cache hits/misses
Posted by "V.C. (JIRA)" <ib...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/IBATIS-324?page=comments#action_12421748 ]
V.C. commented on IBATIS-324:
-----------------------------
"We just need to expose the method in the public interface. "
OK, can you do that please in a svn.
On memory size, even if inaccurate and only by declared xml name or entire cache size, that would help. How would I go about fishing the "object" name of the created cache? Else I'd use the system vm space size.
tia,
.V
> cache hits/misses
> -----------------
>
> Key: IBATIS-324
> URL: http://issues.apache.org/jira/browse/IBATIS-324
> Project: iBatis for Java
> Issue Type: New Feature
> Components: SQL Maps
> Reporter: V.C.
> Priority: Minor
>
> It be nice to be able in real time and loged report on cache hits/misses monitoring, size of cache by map name in megs, and report by hour/date # of times a statment was used.
> (also log the slow sql statements, like anything that takes more then 1/3 of a seconds to log the statment and arguments).
> these are standard managment issues that come up now and then.
> i'd consider implementing if that helps.
> .V
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira