Hi Well using sleep in performance testing is really not a good idea. Unless you expect to have heavy CPU business logic running. If your use-case is more about integrating systems, then the bottlenecks is often at remote endpoints, waiting for reply messages et all.
I suggest to construct testing scenarios that resemble your use-cases, and not use thread sleep. A thread sleep is a blocking thread which is bad design. On Tue, Jun 25, 2013 at 1:27 PM, kiranreddykasa <[email protected]> wrote: > Hi , > > Can anyone suggest how to improve performance of netty without using > additional thread pool. > > As mentioned here that we should not use additional threads > http://camel.465427.n5.nabble.com/camel-Activemq-performance-suggestions-td5734508.html > > Consider this simple route > from("netty:tcp://localhost:7004?textline=true") > .bean(SleepProcessor.class); > > In sleep processor there is single line Thread.sleep(100) , there is no > other logic. > > If we do load test with this route we are able to get 160 tps . > > And if we add .threads(800,800) then we get ~700 tps. > If we should not use threads option what will be the other alternative? > > We tried to load balance by starting the same route with different ports but > still no effect. > > Thanks > > > > > ----- > Regards > > kiran Reddy > -- > View this message in context: > http://camel.465427.n5.nabble.com/netty-thread-pool-clarification-tp5734734.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- www.camelone.org: The open source integration conference. Red Hat, Inc. FuseSource is now part of Red Hat Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
