It may be worth adding a small number of JMH micro benchmarks - not to be used as performances metrics - on camel core so we can spot potential regressions.
--- Luca Burgazzoli On Sun, May 28, 2017 at 11:31 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > 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
