Interesting test results.
I built a client and the messages take 50msec round trip from Boise ID to California. On my 1Gb network I get around 4-5milliseconds. I am using JAXWS-2.1 on the server and the JAXWS-2.0 on JRE 1.6 on the client.
I run the local network tests on Win 2000 Professional on a Dual AMD64 4200+ with 1GB of RAM. In the Bay Area where someone has been testing my client he is using a 3GHz Windows 2000 Professional and with my special client is getting 50-60milliseconds. I also get the same numbers for round trip between Eden Prairie MN to Boise ID using Windows XP on a Dual Centrino.
I also use threading on the client and the server is JBoss 4.0.5GA. For the 50/5 millisecond times the http message size was around 360 Bytes as measured in the Apache logs.
I have not done load testing yet but I wanted to get the server side down response time below a millisecond and feel I am there since I was running 32-bit and am switching to 64-bit to get into the microsecond response time as measured at the server.
Different type of system than what you probably have but architecture/implementation/tuning makes all the difference in the world.
Regards,
Tony Anecito
Founder, MyUniPortal
Jitendra Kotamraju <Jitendra.Kotamraju_at_Sun.COM> wrote:
LeRoy Hall wrote:
> What is "profiler data"?
>
> The WSDL imports 2 schema; one for the request and one for the
> response. The Schema are from The Open Travel Alliance. You can
> visit their web site at
>
> http://www.opentravel.org/
>
> I am using the 2005A flattened schema; FS_OTA_HotelAvailRQ/RS.
>
> I am doing a simple test at the moment. My client app starts 20
> asynchronous sessions with a MQ Series Queue. I flood the queue with
> a number of messages, which cause the sessions to begin processing.
> Each session instantiates and builds a request object that was created
> by wsimport to represent the request schema, instantiates a service
> object, sets the handler resolver, gets an instance of the port type
> object, and then invokes the web service. My handlers build a soap
> header to pass authentication info to the server endpoint, store
> request and response, and capture the time the message was sent and
> the time the message was received. Pretty straight forward.
* Creating Service object for each request adds a lot of
overhead(Fetching WSDL and parsing). You should reuse the port/proxy
objects.
* SOAP handlers are kind of expensive. You could use pass extra headers
very easily using jax-ws RI. But this will result into nonportability.
If you want to do this for authentication headers, here is a link :
https://jax-ws.dev.java.net/faq/index.html#additionalheaders
* If you are creating a JAXBContext, reuse JAXBContext instead of
creating every time.
Jitu
>
> The web service endpoint is a JAX-WS web service I developed that
> simply receives the request, reads some fields to echo back, hard
> codes other fields and returns. It's installed on a separate machine
> from the client and is running under Tomcat 5.5. I load tested this
> with JMeter and it's performing well...about 75 messages per second if
> memory serves me. Also, looking at the timestamps my handler
> generates, the sending and receiving times are very close. The
> majority of the time seems to be spent in the client. I plan
> on adding more fine grained logging to this to determine exactly where
> in the client the time is being spent, however considering what I saw
> when implementing JAX-WS 2.1 I suspect it's something to do with the
> client portion of JAX-WS. My client is a multithreaded app and in
> my experience with multithreaded apps that slow down as quickly as
> this one does as you add load indicates to me that something is
> synchronized causing a bottleneck. Just a theory at the moment; I
> haven't gotten around to doing a search on all of my client code and
> the JAX-WS code for that keyword. :-)
>
> The JVM the client is running under is configured to have 1 gig of
> memory, however I've monitored the memory as this processes and it
> never uses more than 70 meg, so I'm pretty sure there isn't any
> thrashing going on.
>
> When a message is popped off the queue and a client session invoked, a
> timestamp is generated. When the client replies to the reply queue
> with the response, another timestamp is generated. After the response
> is sent back to the reply queue, these timstamps are then logged to a
> database along with other data for tracking and timing purposes. I
> query the DB to get an average; 10 messages are averaging 4.8 seconds
> per message, and 50 messages are averaging 7 seconds per message.
>
> The client is running on a Windows server running Windows Server 2003,
> with 2 2.8 ghz processors, and 3.56 gig of RAM.
>
>
>
>
> */Vivek Pandey /* wrote:
>
> Hi LeRoy,
>
> Can you provide us with the profiler data? Can you provide more
> information about your client application/WSDL thats showing such
> regression? Also how you are measuring the performance?
>
> thanks,
>
> -vivek.
>
>
> LeRoy Hall wrote:
> > I've been doing some load testing and although JAX-WS endpoint
> > implementations perform very well, the jax-ws clients do not. Does
> > anyone know of any place I can go to read about improving
> performance
> > with JAX-WS clients??
> >
> > FYI - For my client tests, the JAX-WS RI build from 11/15/06 is
> > showing numbers 3 TIMES BETTER than the latest 2.1 release, however
> > the 11/15/06 build still is not good enough for what I need. I am
> > accustom to seeing numbers indicative of "messages per second", not
> > "seconds per message" that I am currently seeing.
> >
> >
> >
> >
> ------------------------------------------------------------------------
> > Looking for earth-friendly autos?
> > Browse Top Cars by "Green Rating"
> >
> > at Yahoo! Autos' Green Center.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
>
>
> ------------------------------------------------------------------------
> Sucker-punch spam
>
> with award-winning protection.
> Try the free Yahoo! Mail Beta.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_jax-ws.dev.java.net
For additional commands, e-mail: dev-help_at_jax-ws.dev.java.net
---------------------------------
Expecting? Get great news right away with email Auto-Check.
Try the Yahoo! Mail Beta.