July 1, 2014 at 3:22 pm #26315
First of all, congratulations for building such a good, easy to use, and useful component! We’ve managed to make rewrite work on our Java EE EAR project without any glitches.
However, besides rewrite doing exactly what’s supposed to do, we’re facing some considerable performance problems. As we’re working on a Servlet environment, we decided to extend HTTPConfigurationProvider and mark it with @RewriteConfiguration annotation. We already set the org.ocpsoft.rewrite.config.CONFIG_RELOADING context-param to false, and we also set up the following param org.ocpsoft.rewrite.annotation.BASE_PACKAGES so the lookup for annotated classes is just made on one package.
We installed rewrite through maven. We added this dependency just on the web module pom.xml file. It’s nowhere else.
Besides our rule set is considerably big (around 180 rules) they all are quite simple and have the following format:
Working with all of them, increased about 100% the time needed to display any page. That’s why we decided (temporarily) to comment most of them, and we’re now working with the minimum essential ones. But, the response time even with this small amount of rules, is still very high (about 40% more compared to when rewrite is not being used). Furthermore, in CPU usage terms, when serving a page and using rewrite, the server uses about 300% more cpu capacity, compared to the same page served without rewrite, even with the small set of rules.
Although we have other filters on our application, we already tested the above cases also taking away those, but nothing changed.
Finally, we decided to profile the org.ocpsoft.** packages when rendering a page, and we figured out that most of the time/cpu usage is used on ServiceLoader.loadServiceFiles() method and on ServiceLoader.loadServiceFile(). This both methods get called more than 3.000 times and have by far, the biggest self time consumption among the total execution time.
We really do not know if those methods are supposed to have the most cpu self time consumption or there’s something wrong with our project/environment. What it feels strange to us is that the mentioned method/classes doesn’t seem to be part of the rule’s processing core, but part of the classes used to read the configuration (auxiliary).
We would really appreciate if some of you can shred some light on this problem.
We are using Jboss eap 6.1 Alpha (Jboss 7.2 final), with JSF and Primefaces component tool.
Thanks in advance, cheers!July 7, 2014 at 11:16 am #26320
first of all: Sorry for the delayed response.
Hmmm. Looks like you found a real performance problem in Rewrite. Our ServiceLoader is basically an extension of the JDK ServiceLoader which does some additional stuff. It allows for example to provide custom strategies for finding SPI implementations.
Two things come to my mind:
1. Which of the rewrite-integration-* modules do you use in your project? Some of these integration modules include custom ServiceLocator implementations which are used by ServiceLoader to lookup classes. Perhaps there is some performance bottleneck in one of these implementations.
2. I don’t think that the ServiceLoader has to be called soooo often. Did you see any Rewrite class during your performance analysis which was causing this enormous number of calls to the ServiceLoader API?
ChristianJuly 8, 2014 at 8:17 pm #26326
Thanks for getting back!
We’re not using any rewrite-integration-* modules on our project, just the rewrite-servlet (latest version). Are we supposed to be using any of them? We’re working with JSF.
I couldn’t identify the Rewrite class who’s calling the ServiceLoader. I’m attaching a screenshot of the profiler.
Thanks.July 13, 2014 at 3:46 am #26332
Sorry for my late reply.
Do, you don’t need any of the integration modules if you don’t need that kind of integration. It’s completely optional.
Thanks for sharing the screenshot. I think I’ve an idea why there are so many invocations of the ServiceLoader. It may be caused by this line of code:
So actually each instance Of DispaterType is loading SPI implementations from the ServiceLoader. There should actually be some kind of cache I think.
I’ll try to find some time in the next days to work on a patch for this issue.
However, even if there are so many invocations, I wonder why this leads to such a performance drop in your case. If you don’t use any of the integration modules, then loading the SPI files from the classpath seems to be slow for some reason.
ChristianJuly 13, 2014 at 2:38 pm #26333
Thank you very much for taking time to dig into this problem, Christian! A patch would be really helpful!
Pablo.July 14, 2014 at 3:56 am #26334
I just committed a possible fix for this issue:
Could you perhaps give the latest snapshots a try? Unfortunately our CI server is currently down. So you will have to build the snapshot yourself. But this is really really easy.
Just clone the repository from GitHub or simply download the latest source from here:
Then build it using this command:
mvn -DskipTests clean install
Now you can update the Rewrite version in your pom to
3.0.0-SNAPSHOTand give it a try. 🙂July 14, 2014 at 9:45 am #26335
Thank you so much! This patch really works and now rewrite’s performance is really good 🙂
Which will be the version that will include this patch?
Cheers.July 18, 2014 at 11:21 am #26336
Lincoln Baxter IIIKeymaster
The next released version of rewrite will be 3.0.0.Final, we can also probably release 2.0.13.Final for you if you don’t want to wait that long 😉 What is your timeframe like?
~LincolnJuly 18, 2014 at 1:40 pm #26337
Thank you very much for such an offering! We will be launching next August 11th so a 2.0.13.Final would be awesome.
You must be logged in to reply to this topic.