Hi All, The performance bottleneck in the 0.1.0 trunk appeared to be caused by the introduction of tenant resolving; each http request ended up in one or more uncached invocations of TenantManagementService.getTenants (which in its turned invoked at least 1 cassandra query). After introducing a tenant cache, see http://jira.amdatu.org/jira/browse/AMDATU-304, performance is greatly improved, back to where it was in 0.0.6. I ran another JMeter test with the plan below, attached are the results. The results show that the performance of the current 0.1.0 trunk is at least as good as 0.0.6. Case closed. I will do some more testing with more than 1 tenant and other tests.
Regards, Ivo From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Ivo Ladage-van Doorn Sent: vrijdag 11 februari 2011 14:08 To: amdatu-developers at amdatu.org Subject: [Amdatu-developers] Blocking performance issue in 0.1.0 Hi All, The performance test I send the results for last week showed that increasing the amount of tenants/servlets in the new dispatcher approach causes a significant dropdown in throughput/response times. At the same time, response times were still acceptable and for the 'normal' case with only a few tenants and tenant aware servlets, the performance decrease was not significant. However, the guys of the BlueConic project claimed that they did ran into a major performance decrease with the latest 0.1.0 version compared to 0.0.6 in their dashboard. Therefore I created a JMeter test plan to create another performance test which is more suited to this real-life situation. The test plan is; - Open dashboard - Login as Administrator - Refresh dashboard - Logout - Refresh dashboard The attached Excel sheet shows the results of a performance test using this JMeter build plan. I tested with 0.0.6, the 0.1.0 branch just before the dispatcher was merged to that branch and the latest 0.1.0 version (including dispatcher). I also test with just 1 tenant and default Amdatu installation. The result is quite astonishing; the stats show that introducing the dispatcher caused an increase of response times by a factor 46 and throughput went down by 98%, compared to 0.0.6. Some other changes in 0.1.0 prior to the dispatcher also effected performance, but this decrease is not that dramatic. I don't think we can release a 0.1.0 version with this kind of increase in response times and dropdown in throughput, it's simply not acceptable. So we should use some profiler to see what is happening in the latest 0.1.0 version and what the cause is of this issue. I created a JIRA issue for it; http://jira.amdatu.org/jira/browse/AMDATU-301 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/20110214/b15c057f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Amdatu dashboard jmeter results.xlsx Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet Size: 15250 bytes Desc: Amdatu dashboard jmeter results.xlsx Url : http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20110214/b15c057f/attachment-0001.bin
