| Title | Consistency checking and refreshing take unacceptably long in the TeamTrack integration |
| Status | suspended |
| Priority | optional |
| Assigned user | Gareth Rees |
| Organization | TeamShare |
| Description | When there are many cases in TeamTrack, the consistency checker and the refresh script take unacceptably long to run. The P4DTI TeamTrack integration is now maintained and supported by TeamShare <http://www.teamshare.com/>. |
| Analysis | We measured the time taken for TeamTrack 4509 (running with Microsoft Access) to supply cases through the TeamShare API. We used the ReadListWithWhere program in the Samples that came with the TeamShare API for build 4509 so that no P4DTI code was involved. Here are some data points: 50 cases took 17 seconds 60 cases took 23 seconds 65 cases took 26 seconds (We couldn't get any more than this at one time because of job000277.) This means that it takes between 0.3 and 0.4 seconds to fetch a single case from TeamTrack via the TeamShare API. These are not large cases: maybe 1 to 2 kb of data. This means that an organization with 10000 defects will have to wait more than 4000 seconds (over an hour) for the P4DTI to check the consistency of the databases, or refresh Perforce, or even start up for the first time. The underlying cause is the same as for job000277. See the analysis for that job. It seems unlikely that TeamShare will be able to improve the speed of accessing data through the TeamShare API. However, we can ameliorate the problem by providing progress indicators for consistency checking (refreshing already provides progress indicators if log_level is message.INFO). GDR 2001-05-19: Comparison of the performance of the Bugzilla and TeamTrack integrations shows that the performance bottleneck is the TeamShare API. On similar hardware, the Bugzilla integration can fetch 60 bugs per seconds but the TeamTrack integration can fetch 5 cases per second. We have measured the performance of the TeamShare API in some detail [2]. However, we haven't tried to improve it, because capacity is more important (the capacity problem prevents the P4DTI from working; the performance problem makes it inconvenient to use). Here are some ideas about improving the performance of the TeamTrack integration: 1. Restrict the fields read from the TeamTrack database, as recommended by [3]: "If you need relatively few fields for each record, and you are running your client API program on a different machine from the TeamTrack application, you can improve your performance somewhat by specifying which fields will be returned by the TeamTrack server." (I would like to know, is it safe to do this? In particular, if I fetch only a subset of the fields in a record (using ReadRecordListWithWhere() with the optional fields argument), can I then pass that record to UpdateRecord() and Transition() and get the results I expect? That is, the fields I selected in the first place get updated, but fields I didn't select are left unchanged.) In our recommended configuration (P4DTI on the same machine as the TeamTrack server) this strategy saves no time (according to [3]; I haven't tested this). 2. Change the TeamShare API and/or protocol so that it's faster. It currently takes 600kb to represent a case in memory in the API client. It appears that the TeamShare API stores a schema description of the TS_CASES table with each record read from the table. Perhaps the TeamShare API could be changed so that it only had one copy of the schema in memory and each case had a reference to the schema. GDR 2001-05-22: Solution 1 above (field only selected fields from the CASES table) won't work. [4] says: "We also have several open issues on the ReadRecordListWithWhere with the optional 'fields' argument, the returned record is not correctly filled in (I didn't know this when I suggested you use this method). Therefore, you will most likely get an error if you attempt to use this record for anything but a read operation." GDR 2002-02-04: TeamTrack 5.5 is better: the test takes 11-13 seconds to read 50 records from the CASES table, so that's 0.22 to 0.26 seconds per case. |
| How found | manual_test |
| Evidence | [1] <http://www.ravenbrook.com/project/p4dt...-23/teamtrack-testcase/tTrackSample.mdb>.[2] "Performance analysis of TeamShare API workarounds"; < http://www.ravenbrook.com/project/p4dti/doc/2001-05-16/teamtrack-performance/>.[3] "Re: Notes on memory usage in the API"; < http://info.ravenbrook.com/mail/2001/04/18/08-28-40/0.txt>.[4] "Re: Capacity and performance problems with TeamTrack 4.5"; < http://info.ravenbrook.com/mail/2001/05/21/16-22-04/0.txt>. |
| Observed in | 1.0.5 |
| Test procedure | <http://www.ravenbrook.com/project/p4dti/master/test/test_teamtrack.py>, section 2.3 |
| Created by | Gareth Rees |
| Created on | 2001-03-23 18:19:32 |
| Last modified by | David Jones |
| Last modified on | 2003-08-19 13:55:16 |
| History | 2001-03-23 GDR Created. 2001-05-19 GDR Added lots of analysis. Reduced priority to 'optional' since all the long operations have progress indicators. 2002-02-04 GDR Noted improvement in TeamTrack 5.5. 2003-05-19 NB TeamShare handover. 2003-08-19 DRJ Suspended due to teamshare handover |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 35521 | suspended | 2002-11-14 13:44:46 | Richard Brooksby | Removing TeamTrack support from master sources. Updating project index and FAQ to reflect new TeamTrack situation. |
| 12703 | open | 2001-05-19 15:57:16 | Gareth Rees | Added progress indicators for consistency checking. |