He Ivo, nice work! Can we (re-)use that test and is it easy to use. Ie I can image we can run it in some fixed configs using a mvn profile or something :)
2011/2/4 Ivo Ladage-van Doorn <Ivo.Ladage-vanDoorn at gxsoftware.com>: > > 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. That is what I expected and there are still some optimizations to do by precalculating the filter/servlet array passed into the chain and optimizing matching. > ????????? 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. Can be improved on again by formentioned optimizations. In the end however it makes sense that longer chains affect performance. With regard to throughput I also suspect a synchronization issue. I'll look into that. > ????????? 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). Yup, not much the dispatcher can do about that. As all service dependency /registration logic seems most synchronous this effect is to be expected. not sure we can fix that. It should not affect runtime behavior too much though. > ????????? 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. I'll look into that if you give me the test :) > 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. We should be aware as to not introduce too much specifically filters. Eg. non tenant ones and/or no unnessecary ones like the rest dispatchers. grz Bram
