Performance problems

Splash Forums Rewrite Users Performance problems

This topic contains 8 replies, has 3 voices, and was last updated by  pablokles 2 years ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #26315

    pablokles
    Participant

    Hi,

    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:

    “.addRule(Join.path(“/admin/products/suppliers”).to(“/faces/admin/forgeGenerated/supplier/search.xhtml”).withInboundCorrection())”

    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!

    #26320

    Hey,

    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?

    Christian

    #26326

    pablokles
    Participant

    Hey Christian,

    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.

    Attachments:
    1. Profiler
    #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:

    https://github.com/ocpsoft/rewrite/blob/cd3d94419ca4a323c8f895317d742189025256a5/config-servlet/src/main/java/org/ocpsoft/rewrite/servlet/config/DispatchType.java#L48

    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.

    Christian

    #26333

    pablokles
    Participant

    Thank you very much for taking time to dig into this problem, Christian! A patch would be really helpful!

    Pablo.

    #26334

    Hey,

    I just committed a possible fix for this issue:

    https://github.com/ocpsoft/rewrite/commit/c960607c4f3a4d099aea4d0a0dc1548b3e29feca

    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:

    https://github.com/ocpsoft/rewrite/archive/master.zip

    Then build it using this command:

    mvn -DskipTests clean install

    Now you can update the Rewrite version in your pom to 3.0.0-SNAPSHOT and give it a try. 🙂

    #26335

    pablokles
    Participant

    Hey Christian,

    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.

    #26336

    Hey Pablo,

    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?

    ~Lincoln

    #26337

    pablokles
    Participant

    Hey Lincoln!

    Thank you very much for such an offering! We will be launching next August 11th so a 2.0.13.Final would be awesome.

    Cheers

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

Comments are closed.