On Mon, May 29, 2017 at 4:23 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > So today the old cruft of the legacy tracer came to bit us. There is > something called Tracer in camel-core that was used to trace Camel > messages. Its only in use if you do camelContext.setTracing(true) from > Camel end users point of view. However it captures trace details > regardless. > > That old cruft has been lingering for a long time, and it was really > intended to be deprecated sooner (it slipped my radar when we marked > stuff for @deprecated a little while back) and removed completely in > Camel 3.0. > > Today we have a better way of tracing via Message History EIP and > BacklogTracer. > > So I am working on disabling that old cruft, and remove parts of it, > and then make camelContext.setTracing(true) use the new way via > BacklogTracer / message history to trace instead. >
Okay I opted to keep the old way with setTracing(true) but found a way to optimise it so its not adding overhead if tracing is off. We can then later migrate tracing(true) to use the new way. > > There is some before vs after screenshots at > https://issues.apache.org/jira/browse/CAMEL-11360 > > .. of a prototype that runs the camel-profile-sample project. > > > > > 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 > > > > -- > 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
