Steve Sorry we didn't publish all the data in graph format. The Mesh-5000 is doing pretty complex XML processing. The String-5000 (which is in the excel spreadsheet - we will add it to the page shortly) number was 444/sec. This is still doing some reasonable processing (i.e. creating an array of 5000 strings versus a single big string).
Paul On 1/31/07, Steve Jones <[EMAIL PROTECTED]> wrote:
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 > >
-- 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
