I did try playing with the thread pool size in the config file for smix.. However, st flow doesn't scale better than SEDA.
Our next option is to go with clustering of SMix with seda and JMS flow. We had to use threading within our application to increase the rate at which Smix does all the JBI components processing on our input files, which we have developed. The difference, with threading in our application process , image+xml file to extend of 1000 rec /minute With out threading in our application , the process did close to 50 recs / minute. Thanks Mat gnodet wrote: > > In addition, I would also try playing with the thread pool size, > especially > if your CPU consumption is not maxed. > > On Dec 19, 2007 3:33 PM, Bruce Snyder <[EMAIL PROTECTED]> wrote: > >> On Dec 14, 2007 1:23 PM, MatSM <[EMAIL PROTECTED]> wrote: >> > >> > Hi, >> > >> > Iam trying to understand the performance metrics for the above two >> flow. >> > Please clarify. >> > >> > The scenario for the flow is : >> > >> > 1. Different files of with a few recs totalling to xml recs- 500 is >> dropped >> > in a Queue.In our case MQ. >> > >> > 2. That is read by Smix through JMS binding - The JBI components in >> Smix >> > does - splitting of xml, validation of xml(Node level) and calls a web >> > service running in Geronimo to insert recs into database. >> > >> > The metrics >> > Appromixately 1.5 minutes for 480 recs inserted into db.. (Some >> exceptions >> > thrown, those recs not inserted into db) - Flow -SEDA >> > >> > Appromixately 8.5 minutes for 480 recs inserted into db.. (Some >> exceptions >> > thrown, those recs not inserted into db) - Flow -STRAIGHT >> > >> > >> > Any explanation to the above poor performance for the ST flow. >> >> This is straightforward difference between the straight through flow >> and the SEDA flow. The ST flow does no buffering whatsoever so it's >> not as efficient and doesn't scale very well. The SEDA flow is based >> on the concepts in the SEDA paper >> (http://www.eecs.harvard.edu/~mdw/proj/seda/<http://www.eecs.harvard.edu/%7Emdw/proj/seda/>) >> so it is designed to be >> more efficient and scale much further. This is why the SEDA flow is >> the default flow. >> >> Bruce >> -- >> perl -e 'print >> unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" >> );' >> >> Apache ActiveMQ - http://activemq.org/ >> Apache Camel - http://activemq.org/camel/ >> Apache ServiceMix - http://servicemix.org/ >> Apache Geronimo - http://geronimo.apache.org/ >> >> Blog: http://bruceblog.org/ >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > > -- View this message in context: http://www.nabble.com/Seda-Flow-and-ST-flow-tp14339781s12049p14420813.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
