Hi I have found some more spots for optimisations which I have committed over the last couple of days.
Its been several years since we last did such things last, and I have to admit we have introduced some code that add more object allocation and a few performance drawbacks since then. So with the help of profilers we should be able to improve the situation for the Camel 2.20 release. I have to give credit to Luca for bring this idea up about making Camel startup faster and look into the number of objects allocated etc. Usually Camel has negligible performance overhead in the grand scheme of things. But we have more fine grained performance statistics today which records the time taken in every step messages are routed. This uses the StopWatch object which we frankly create too many new instances. So by reducing those we can reduce the object allocations and therefore the JVM GC characteristics. In the stuff I have optimised you can find the JIRA tickets with Optimise as prefix. I usually have attached some screenshots from the profiler so you can see before vs after situations). We have two areas that can be improved 1) startup Camel faster (jndi registry, caffine lru cache, and the uuid generator is a bit slow in their constructors) 2) faster routing per message at runtime (potential optimise by reducing object allocations, turn off some features less/seldom in use, optimise code logic in hot-spot areas, reduce size of internal state objects, avoid thread contention from synchronized methods, etc.) On Fri, May 26, 2017 at 3:59 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > We have found a few spots to optimize the camel-core source code for > thread contention and something else. > > You can use a profile tool such as YourKit which is excellent at > identifying spots and visualizing what goes on in the JVM. > > We have used it in the past to optimise stuff. However recently Luca > asked about making Camel startup faster: > https://issues.apache.org/jira/browse/CAMEL-11321 > > And although fast startup is not excatly the same as runtime > performance then they are still related. A profile can help identify > places for improvements. > > I have pushed a sample project at > https://github.com/davsclaus/camel-profile-sample > > You can then run this via > > mvn spring-boot:run > > And then attach YourKit profiler. > > However if you use IDEA then you can start YourKit, then from YourKit > you can choose Integrate with IDE ... and then chose IDEA and then say > ok even if IDEA is also running. > > In IDEA you should see a YourKit icon if you right-click on the > SampleCamelApplication to run this application, then you can chose > that to profile, and it run the app with profiler. > > You then switch to YourKit and you should start see data. > To check for thread contention, then select the "Monitor Usage" tab, > and then click the gear button with the play icon "Start Monitor > Profile" which then starts capture data. > > For YourKit you can request a trial license that works for 2 weeks. > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
