Looking on the graphsi was looking at the Mesh-5000 responses (hence 27 tpc), I can't see the string-5000 one on the page (I may be going blind however).
400 reqs/s would definately be superb, I just didn't see that when looking at the Mesh-5000 numbers. Steve On 31/01/07, Paul Fremantle <[EMAIL PROTECTED]> wrote:
Steve Please remember that these messages are being parsed into Java objects and also echo'ed. So this isn't a good comparison with a traditional messaging system (like MQ) where the messages are typically one-way and the actual parsing processing of the body isn't considered part of the test. The closest we did to your test was the echoStrings-5000 test which had a message size of 200k (therefore 400k throughput per message) and we got more that 400req/s which was completely saturating the 1Gb/s ethernet segment. I don't think you can really ask more?! Paul On 1/30/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > Paul, > > Its interesting stuff, but I'd certainly say that "serious work" in XML > land can often be significantly above 4-6k, and often (when using industry > standard schemas) in the 200-500k range and pretty complex structures. > Which means around 30 tps from the graph which isn't very much. One of the > issues in industry is that there are great reasons to use industry standard > schemas but they are pretty evil things as they aim to cover all cases, this > makes them very inefficient. > > Have you folks done anything around how to scale B2B and domain to > domain scenarios with large documents? From my wikipedia ripping experience > I'd expect StAX to massively outperform JAXB due to the large envelope but > small content pieces of those schemas. > > I'd be happy to provide some test schemas that I've seen cause trouble. > > Steve > > > On 30/01/07, Paul Fremantle < [EMAIL PROTECTED]> wrote: > > > A while back we had a discussion on whether Web Services are slow. > > > > Here is some data that I think concludes that SOAP can scale to high > > transaction rates (e.g. 300 million transactions a day). The test > > isn't a real-world test, but it does show that the overhead of SOAP > > processing is minimal with the latest toolkits. > > > > Some quotes from the article. > > ---------- > > > > This article shows the latest performance results of Apache Axis2 vs. > > Codehaus XFire, both Java implementations. The results demonstrate > > that modern Web Services engines can perform at very high transaction > > rates. > > > > Axis2 using the default ADB binding framework shows outstanding > > performance, with consistently better results than XFire/JAXB or > > Axis2/JAXB. > > > > Using either toolkit, the overhead of using XML and SOAP is no longer > > a limiting factor in writing distributed systems for most applications > > (with may be the exception of trading floors!). While these tests do > > not perform 'real' work, the fact that a XML messaging system can > > scale to more than 10 million transactions an hour on a single > > quad-core server shows that Web services can be used for significant > > systems applications. > > > > --------- > > > > Read more here: http://wso2.org/library/588 > > > > My disclaimer - I co-authored the document and I'm a committer on the > > Axis2 and other Apache WS projects. > > > > -- > > Paul Fremantle > > > > http://bloglines.com/blog/paulfremantle > > [EMAIL PROTECTED] <paul%40wso2.com> > > > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
