Hi All, In the context of the new tenant/dispatch mechanism I wrote a simple performance test to test the performance of the new dispatch mechanism. This test has two goals;
1. Compare performance/throughput impact of new dispatch mechanism planned for 0.1.0 with the original Felix whiteboard/filter approach used in 0.0.6. 2. Create a reproducible performance test to test performance impact of future changes First let me clarify the setup of this test; * Use Pax Exam to startup OSGi container with only those bundles deployed which are really necessary for this test * Register a single servlet which needs to be tenant aware; it writes the current tenant to the http response * Use in-memory tenant storage provider (to prevent tenant storage becoming the bottleneck) * Invoke GET requests to this servlet (with a unique URL), where; o The amount of tenants varies o The amount of registered tenant aware/unaware filters/servlets varies o The amount of concurrent threads invoking these GET requests varies * Measure average response time on the http client * Measure throughput (amount of requests per seconds) of the server In the dispatch setup the servlet is Tenant aware by becoming an adapter service of Tenant. In the Felix whiteboard setup the servlet is registered as a regular service but the tenant is resolved in the servlet itself by matching hostname. The attached excel sheet contains the results of this different runs with different configurations. Most important thing to look at are the last two columns in each run, which summarizes the relative response time/throughput increase or decrease compared to the original. The runs have been executed with a relative small seed, but I do not expect many differences running them with larger seeds, considering the standard deviations in response times and differences between the two runs. Looking at the results my conclusion is: * With only tenant unaware filters and servlets registered, there is not much difference in performance/throughput of the new dispatch mechanism compared to as it was in 0.6.0. This can be seen looking at the results from run 1 and 2. * Increasing the amount of registered tenant aware servlets or filters (not invoked, just available in the system) has a major impact on response times/throughput in the new dispatch mechanism as opposed to as it was in 0.6.0. With a reasonable amount of servlets registered (i.e. 50), in the original 0.6.0 version increasing the amount of tenants did not have much impact on response times/throughput as opposed to the new dispatch mechanism. With 50 servlets and 50 tenants, response times increase by a factor 7 and throughput drops with 86%. This can be seen looking at the results of run 3, 4 and 5. * With the new tenant mechanism, creating or removing 100 tenants in an environment with already 100 servlets registered takes a very long time (up to 12 seconds per tenant). * I wasn't able to test with a significant amount of tenant aware filters, as this results in a StackOverflowError in the new dispatcher (see http://jira.amdatu.org/jira/browse/AMDATU-285). Hence the 'NaN' values in run 5. NB: in the default Amdatu runtime there are 51 servlets of which 8 are tenant aware and 11 filters of which none are tenant aware. Regards, Ivo GX Software | Ivo Ladage-van Doorn | Product Architect | Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 21 | ivo.ladage-vandoorn at gxsoftware.com<mailto:ivo.ladage-vandoorn at gxsoftware.com> | www.gxsoftware.com<http://www.gxsoftware.com> | twitter.com/GXSoftware<http://twitter.com/GXSoftware> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20110204/f093f3dd/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: performance_test_results_0.0.6_versus_0.1.0.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 41073 bytes Desc: performance_test_results_0.0.6_versus_0.1.0.xlsx Url : http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20110204/f093f3dd/attachment-0001.bin
