2008/9/12 Christian Vest Hansen <[EMAIL PROTECTED]> > On Fri, Sep 12, 2008 at 11:07 AM, Kent Närling <[EMAIL PROTECTED]> > wrote: > > Hi! > > I guess this might have been answered here before, but I searched the > lists > > and the FAQ:s and could not find anything so I will take the risk ... ;-) > > > > What ARE reasonable overheads using CXF Webservices? for instance > compared > > to RMI/Beans etc? > > I would never recommend RMI. It is based on Java serialization, which > is fundamentally broken.
Yes, naturally, for compatibility it is horrible, so I would never compare it to webservices etc ;-) And I didn't intend to compare with RMI as an alternative, more to get a feeling of the "cost" of sebservices/SOAP compared to less robust but more low level alternatives. > > I'd suggest using Googles Protocol Buffers instead. Ok, Will look into that ... > > > > > > We did some measurments and found that some basic calls got between 3-5 > > milliseconds of overhead/response time (using a dummy implementation). > > Is this normal? or does it sound high? can this be tuned significantly? > > Considering this is (presumably) over a network connection, then this > latency looks to me to be quite good. But I wonder how this was No, actually it was not! I simply initialized a (mockup) webservice , published it and then called it from within the same process (tried both with single thread and multiple threads with comparable results) > > measured. The process-schedulers in most operating systems use 10 ms > timeslices, so unless you really know your way around benchmarking and > statistical analysis, you can expect measurements in the < 20 ms scale > to be very inaccurate. Very true, forgot that for a moment, will doublecheck that. But the analysis is based on thousands of calls and then calculating the average/call. Also, I used System.nanoTime() which should be more accurate. > > I suppose it can be tuned by using a binary XML format. There has been > some talk about on this list, but I can't find anything on the wiki so > I don't know if it is actually feasible. Ok, will keep my eyes open for this. > > > > > Mainly I need to know to decide our strategy for using webservices etc > > > > For our external interface this latency/overhead is not an issue, but we > > have discussed using webservices as an internal interface in a SOA > > architecture, but then this overhead would not be practical... > > Is latency really that important to you? Or is it actually throughput > that is your real concern? Well, maybe not as long as it is not a symptom of overhead so your point is very valid. > > Only a proper load-test can tell whether or not the throughput will be > good enough. My experience is that you throughput-bottleneck is much > more likely to be in your application code that in CXF itself. At > least, that is my conclusion for load that ranges up to 20.000 > requests per minute. This is a very interesting comparison!! 333 TPS? Can you qualify that a bit more? is that on a single machine? If performance on levels of 100-200 TPS is achievable with webservices is easily achievable on a single machine (without heavy tuning etc), then I think we should be happy enough! :-) > > I don't know anything about systems that need to live up to real-time > gaurantees, though. No, we do have some stringent demands on our systems, but I wouldn't qualify them as "real-time guarantees" > > > > > Best regards, > > Kent > > > > > > -- > Venlig hilsen / Kind regards, > Christian Vest Hansen. >
