For each load test Silk Performer writes result information aggregated at the user group level to a DBMS based results repository. Additionally the results repository stores error information for each error reported by a virtual user. This information is available via Silk Performer's Results Repository (menu: RESULTS | RESULTS REPOSITORY). The amount of storage used for these results is not dependent on the duration of a test. It is only dependent on the number of transactions, timers, page timers, counters in a script and the number of agents involved in the test. You can estimate the number of records inserted into the repository per load test as follows: Records = number of measures in report file(rpt file) * number of agents * number of user groups + minimum(number of errors, error limit per agent) Average record length ~ 140 Bytes DBMS overhead: ~2 Bytes per load test = records * average record length * DBMS overhead Error limit per agent: As the number of errors produced during a load test easily can get very large, you can configure the maximum number of errors an agent is allowed to write o the results repository. You can set this limit in the System settings Result tab (Report up to messages per agent). Example: A Report file (*.rpt) for one virtual user contains: - 26 measures in the Summary Report - 3 measures in the Transaction Report - 10 measures in the Timer Report - 52 measures in the Page Timer Report - 20 measures in the Web Forms Report A loadtest with 5 agent machines running 1000 virtual users producing 100 errors not exceeding the error limit would approx. generate the following number of records in the results repository: (26+3+10+52+20) 7 5 + 100 = 655 records, this is 90 Kbytes without overhead and assuming a factor of 2 for the DBMS overhead 180 Kbytes. Because the information stored in the results repository is aggregated on an agent/user group level the results repository can be used for very large load tests with thousands or even ten-thousands of virtual users without getting scalability or capacity issues of the repository itself.
↧
