Open acr92 opened 9 years ago
Hi Blystad,
With what version?
0.10.1
OK. Good news, the extension mechanism has been fully refactored in the next version. It is now based on SPI thus leading to much better performance. What application server are you using?
I use Spring Boot 1.2.0 with Jetty 9 Embedded.
Double good news, the new prerequisites won't hurt in your case (Servlet 3.x API). It would be awesome if you could give a try to the latest 0.11.0-SNAPSHOT version and profile your app once again. If you can't, it's not a big deal, I"ll focus on performance in a near future.
Sure, I'll get that done over the weekend and get back to you.
Alright, so, I managed to get my application ported to 0.11 SNAPSHOT and run some profiling.
0.11 is definitly a major improvement in terms of performance with a couple exceptions. dandelion/dandelion#44 was a major performance killer, but I managed to get around that. There were some bugs ( dandelion/dandelion#43 & dandelion/dandelion#45 ), but other then that it seemed to work fine.
I'm currently now down to between 70 and 90ms locally and 200-400ms on the server, which is adequate. Much better then 2-4 seconds on the server.
In an example request, which took 234ms, this is what took time:
116ms
4 calls to AbstractElProcessor:processElement:65
. for 3 of them loadUserConfiguration
took most time, and for the last ServiceLoaderUtils.getProvidersAsList
. I would think that loadUserConfiguration
should be cached in production
mode? FYI I have multiple datatables on the same website, so I guess that's why it was 4 calls.54ms
*
These did a total of 10 http calls for stuff which I had locally in the webjar. Shouldn't they get cached?See full callstack at: http://paste.ubuntu.com/9706525/
Also, I'm wondering a bit about Dandelions cache mechanism. It generates cache key, but, is this necessary to always be unique on a per-page level? Wouldn't it make sense to use the same cache key for all /static/style.css
? I can understand dynamic content (datatables
) but not static content.
Many thanks for the tests @Blystad!
I would think that loadUserConfiguration should be cached in production mode?
I'll take a closer look at it.
These did a total of 10 http calls for stuff which I had locally in the webjar. Shouldn't they get cached?
The same for this one. Thanks!
Also, I'm wondering a bit about Dandelions cache mechanism. It generates cache key, but, is this necessary to always be unique on a per-page level? Wouldn't it make sense to use the same cache key for all /static/style.css? I can understand dynamic content (datatables) but not static content.
You're right. Many optimizations remain to be done. The per-page level is the first step and allows the caching mechanism to work in all cases. In later releases, I'd love to go further in the caching mechanism by allowing more fine-tuned caching configurations. But everything in its own time :-)
Hello,
I've been an happy user of Dandelion and Dandelion Datatables for some time. However, after having done a bit of refactoring and work I noticed that one of our sides were much slower in production then on my local development machines.
After doing profiling I think I've found the case - the ExtensionLoader. It reloads built in extensions on every request, even multiple times per request. Is this really necessary? Can you not cache it?
Please see image for Callstack: