IScmService getHistoryForVersionable is really slow
I manage our team's RTC server for a team of less than 10 developers. We're running 2.0.0.2 iFix 1 (I20100302-1947) with Derby.
I've recently been receiving reports from users that the Show History action is very slow and timing out. I dug around into the counters (jazz/service/com.ibm.team.repository.service.internal.counters.ICounterContentService) and noticed that the action that was slow was com.ibm.team.scm.common.IScmService.getHistoryForVersionable(). It is averaging 187 seconds, with a high of 460 seconds. Is there some re-indexing type action that I can run to make the performance of show history acceptable? |
One answer
|
Adding more data from the sql query counters, in case that helps trigger any thoughts....
number of queries total execute time min execute time avg execute time max execute time total fetch time min fetch time avg fetch time max fetch time total query time total rows read min result set size avg result set size max result set size SQL 6 38965 0 6494.17 8493 261418 0 43569.67 51490 300383 2 0 0.33 1 SELECT CHR.JZ_PARENT_ID, CHR.JZ_POSITION, CS.ITEM_ID, CHR.CREATED_BY_ITEM_ID, CHR.CREATION_DATE FROM SCM.CHANGE_SET_CHANGES C JOIN SCM.CHANGE_SET CS ON C.JZ_PARENT_ID = CS.ITEM_ID JOIN SCM.CHANGE_HISTORY_RECENT_ENTRIES CHR ON CS.ITEM_ID = CHR.CHANGE_SET_ITEM_ID WHERE C.ITEM_ITEM_ID = ? AND CHR.JZ_PARENT_ID IN (?) My reading of this tells me that although the query takes awhile, its the fetch that is killing me(261 seconds). Any ideas on how to improve this situation? I'm going to re-index to try to help the query portion, but I'm not convinced that will help the fetch time. I'll report back as I learn more.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.