Skip to main content

WS slow over network

42 replies [Last post]
whartung
Offline
Joined: 2003-06-13
Points: 0

We've been doing some simple benchmarking of some simple web services.

By simple web services, I mean they don't have a lot of parameters, they're in a bean simply annotated with @WebService, and we're using JAX-WS in a J2SE app, running Java 5.

When we run the client and server on the same machine, we're getting 65-70 requests per second.

But when we run it over the network, this number plummets down to 4-5 requests per second.

It's a good network, we don't have any real user complaints about the network. We run our DB on it, etc. But when we run the JAX-WS app, it comes to a screeching halt.

We had some other folks do a similar test on their network, and they got similar results as well. High numbers locally, and poor numbers across the wire.

I looked at our payloads, there's about 920ish bytes of data moving for each request/response cycle. I'd like to think out network can handle 5000 Bytes/second. My network graph was pretty quiet on my PC, and CPU was reasonably quiet.

So, just curious if we're missing something glaring as to why this is happening.

Kind of our first foray in to WS tuning.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ericm
Offline
Joined: 2008-09-11
Points: 0

Jitu,

I downloaded the 2.1.x nightly, and got approximately the same results:

(Windows SE Http server, Ubuntu client)

run-service-client:
[java] ***************
[java] Functional Test
[java] ***************
[java] echoString(Hello): Hello
[java] --------------------------------------
[java] Echo String Performance
[java] Call Rate: 23.455458 calls/sec
[java] Mean Request Time: 42.632000 millisecs/call
[java] --------------------------------------

Eric

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

I checked http.jar version in today nightly release.
It is that released in September, 11th 2008.
I've already tried it.

Once again, I think it could be very useful to include also the http.jar releases to the maven dependency and in particular SNAPSHOT management.

Thanks

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

I do confirm, no improvements in performances with latest nightly release!

Still waiting for new updates/solutions/fixes....

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

> I completely understand your point about the local
> server not necessarily being "production ready", not
> designed to scale, etc. I didn't really expect it to
> be, but our use case is not Slashdot. Our servers
> will most likely have 1 or 2, and at most 5
> simultaneous connections.
>
> I was able to run 8 clients on a single machine (4
> core) before I got an overall reduction in
> throughput. It didn't scale linearly (100
> msg/sec/client with 1 client, 95 msg/sec/client with
> 2, etc.), but the overall throughput in terms of
> aggregate messages per second was decent. 400-500
> total across all clients.
>
> But, we were interested in single client results. The
> original goal was 150 msg/sec. But we can't get that
> even in loopback. And we're not even saturating the
> CPU.

I completely agree with wartung.
We know SE embedded HTTP server not being production ready and having poorer performances compared to Glassfish.
But we're not aiming to achieve "over-the-top" performances, we're trying to find a way to make SE HTTP having reasonably performances for being delivered in a production environment.
You know, 5 msg/secs in Remote connection mode are not even "fair" for a HTTP server bundled into the JDK.

So, finally, I think that this performance problem can't be considered only related to my and wartung's applications but it deserves a overall consideration, even by JAS-WS developers.

Glen Mazza

metro-3 wrote:
>
> And what bothers me the most is how JAX-WS EVEN KNOWS the difference
> between a network client and a loopback client. How does it know? Why
> should the JAX-WS stack behave any differently?
>
> But the profiles are completely different between the two, and it's all in
> the JAX-WS stack.
>

What do you mean by "profiles", do you actually mean "performance"?

Pardon me, but I'm late to this discussion--are you sure this has anything
to do with Metro--what if you use Java Http Server for other things--is it
much faster then? Is Metro grinding JavaHttpServer to a halt, or is the
performance already bad? If the latter, you may be asking these questions
on the wrong ML--this may not be a Metro issue.

Glen

--
View this message in context: http://www.nabble.com/WS-slow-over-network-tp19037941p19638295.html
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

whartung
Offline
Joined: 2003-06-13
Points: 0

> What do you mean by "profiles", do you actually mean
> "performance"?

When you run the code through the profiler, the "bottlnecks" and "hot spots" look completely different on the server when the client is on the same host vs on a different host.

> Pardon me, but I'm late to this discussion--are you
> sure this has anything
> to do with Metro--what if you use Java Http Server
> for other things--is it
> much faster then? Is Metro grinding JavaHttpServer
> to a halt, or is the
> performance already bad? If the latter, you may be
> asking these questions
> on the wrong ML--this may not be a Metro issue.

Although our recent test were on JDK 6 (just to be consistent with the other poster and his environment), originally this was all done on JDK 5 (and in truth that's where it needs to stay).

JDK 5 doesn't have an HTTP server, JDK 6 "get theirs" from JAX-WS, since JAX-WS get bundled with JDK 6 (that's an assumption).

So, at a minimum, under JDK 5, using JAX-WS, and their "Endpoint.publish()" api in a simple J2SE program, it's slow over the network, and I think it's fair to point fingers at JAX-WS.

In the profiling we've done, all of the "hot classes" live within the JAX-WS package hierarchy.

I completely understand your point about the local server not necessarily being "production ready", not designed to scale, etc. I didn't really expect it to be, but our use case is not Slashdot. Our servers will most likely have 1 or 2, and at most 5 simultaneous connections.

I was able to run 8 clients on a single machine (4 core) before I got an overall reduction in throughput. It didn't scale linearly (100 msg/sec/client with 1 client, 95 msg/sec/client with 2, etc.), but the overall throughput in terms of aggregate messages per second was decent. 400-500 total across all clients.

But, we were interested in single client results. The original goal was 150 msg/sec. But we can't get that even in loopback. And we're not even saturating the CPU.

Glen Mazza

metro-3 wrote:
>
> Although our recent test were on JDK 6 (just to be consistent with the
> other poster and his environment), originally this was all done on JDK 5
> (and in truth that's where it needs to stay).
>
> JDK 5 doesn't have an HTTP server, JDK 6 "get theirs" from JAX-WS, since
> JAX-WS get bundled with JDK 6 (that's an assumption).
>
> So, at a minimum, under JDK 5, using JAX-WS, and their
> "Endpoint.publish()" api in a simple J2SE program, it's slow over the
> network, and I think it's fair to point fingers at JAX-WS.
>

I'm not sure but I think they use java.net.HttpURLConnection for that (which
the Metro team may very well have no control over)--in both Java 5 and Java
6. Maybe this article can give you some pointers:
http://today.java.net/pub/a/today/2007/07/03/jax-ws-web-services-without...

Also, if you're not happy with Metro's Endpoint() implementation you might
want to try Apache CXF's:
http://www.jroller.com/gmazza/entry/writing_junit_test_cases_for

CXF uses embedded Jetty behind-the-scenes in its implementation of
Endpoint.publish().

Glen
--
View this message in context: http://www.nabble.com/WS-slow-over-network-tp19037941p19641094.html
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

whartung
Offline
Joined: 2003-06-13
Points: 0

> I'm not sure but I think they use
> java.net.HttpURLConnection for that (which
> the Metro team may very well have no control
> over)--in both Java 5 and Java
> 6.

JAX-WS bundles http.jar which contains com.sun.net.httpserver. This is used for running under Java 5.

That is also bundled with JDK 6, but only within the context of JAX-WS. There is no "java" web server in the JDK. Recall com.sun.* packages bundled with the JDK are not part of "Java", but rather an artifact of Suns implementation. We, as users, are not supposed to use or rely upon com.sun.* classes.

HttpURLConnection is a simple HTTP client, not a server.

But, since com.sun.net.httpserver can be used "by itself", I took it upon myself to test it straight, without the web services. A simple "hello world" "servlet" (handler actually), and I use HttpURLConnection on my simple client.

You'll be happy to hear that it's performance is equally horrible over the network.

Running loopback on Windows, I get 1000 message in .5 secs, or 2000 msg/sec, but we already know about Windows and loopback.

I then deployed the little server against our Ubuntu box. At that point, we go down to 5 msg/sec. Running loopback on Ubuntu gives us 25 msg/sec, which is what we've always been seeing.

So, clearly the HTTP server shipped along with JAX-WS, and bundled with Java 6, is unusable over a network.

(Just to show I'm not completely deranged, Tomcat 6 clocks on this simple benchmark at 717 msg/sec over the network, and 2000 msgs/sec via "localhost" on Ubuntu.)

Recall, I'm not expecting "production" numbers from Java's server. But...FIVE msgs/sec? Please...

And I lay this issue at the feet of the JAX-WS team, as it seems to still be in their domain.

Glen Mazza

metro-3 wrote:
>
> You'll be happy to hear that it's performance is equally horrible over the
> network.
>
>
>
> And I lay this issue at the feet of the JAX-WS team, as it seems to still
> be in their domain.
>

No, I would go to a Sun J2SE forum and send these problems there. The Metro
team's plate is full enough, and I don't think they can pull a rabbit out of
a hat for you here--you're still stuck with a turtle right now. But do be
careful in how you phrase your complaints--the squeaky wheel doesn't always
get the grease, sometimes it gets replaced. :)

Glen

--
View this message in context: http://www.nabble.com/WS-slow-over-network-tp19037941p19655397.html
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

ericm
Offline
Joined: 2008-09-11
Points: 0

Patrizio,

>So, what I'd really like to know is why SE Http Server performances are so low compared to Glassfish.

I'm not sure if it's the SE Http Server or not. Here are two runs from my windows box, one using the SE Http Server, and one on Glassfish:

SE http server:
[java] ***************
[java] Functional Test
[java] ***************
[java] echoString(Hello): Hello
[java] --------------------------------------
[java] Echo String Performance
[java] Call Rate: 102.732690 calls/sec
[java] Mean Request Time: 9.703000 millisecs/call
[java] --------------------------------------

Glass fish
***************
Functional Test
***************
echoString(Hello): Hello
--------------------------------------
Echo String Performance
Call Rate: 84.545147 calls/sec
Mean Request Time: 11.812000 millisecs/call
--------------------------------------

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Eric,

> I'm not sure if it's the SE Http Server or not. Here
> are two runs from my windows box, one using the SE
> Http Server, and one on Glassfish:
>
> SE http server:
> [java] ***************
> [java] Functional Test
> [java] ***************
> [java] echoString(Hello): Hello
> [java] --------------------------------------
> [java] Echo String Performance
> [java] Call Rate: 102.732690 calls/sec
> [java] Mean Request Time: 9.703000 millisecs/call
> [java] --------------------------------------
>
> Glass fish
> ***************
> Functional Test
> ***************
> echoString(Hello): Hello
> --------------------------------------
> Echo String Performance
> Call Rate: 84.545147 calls/sec
> Mean Request Time: 11.812000 millisecs/call
> --------------------------------------

these performances are the same as those you already posted.
Did you make a mistake in paste them, or you wanted to do it?

Anyway, If I remember well they are performances achieved in LOOPBACK connection in windows, and we already know that SE Http Server performs pretty well in LOOPBACK mode in windows.

What we should be interested on is a comparison of performances between Glassfish and SE HttpServer in remote connection.
I mean running a WS client against both Glassfish and SE Http Server from ad different machine from that hosting the servers.
And, obviously, see what the performances look like in the two cases.

Thanks
Patrizio

ericm
Offline
Joined: 2008-09-11
Points: 0

Patrizio,

I believe I had already posted those numbers, sorry for the confusion.

Here are the numbers when going across the network:

The setup is to have the server run on the windows box, the client on ubuntu linux. The server is either Glassfish, or SE Http:

Windows Glassfish, Ubuntu Client
run-service-client:
[java] ***************
[java] Functional Test
[java] ***************
[java] echoString(Hello): Hello
[java] --------------------------------------
[java] Echo String Performance
[java] Call Rate: 121.595331 calls/sec
[java] Mean Request Time: 8.220000 millisecs/call

Windows SE Http Server, Ubuntu Client
run-service-client:
[java] ***************
[java] Functional Test
[java] ***************
[java] echoString(Hello): Hello
[java] --------------------------------------
[java] Echo String Performance
[java] Call Rate: 21.900048 calls/sec
[java] Mean Request Time: 45.661000 millisecs/call
[java] --------------------------------------
[java] --------------------------------------

It appears that the SE http server is much slower than Glassfish.

Eric

jitu
Offline
Joined: 2003-06-14
Points: 0

Thanks for posting a bug. That is terrible performance. I assigned the bug to SE networking person.
I guess I can quickly wrap grizzly into light weight http server API so that we have an alternate transport for SE endpoints.

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Hi eric,

did you found anything interesting....??

I've a new information for you,
I've just found using wireshark that running the test in loopback mode in windows doesn't go through all network protocol layer.
Packets aren't exiting network interface...

Keep me posted.

ericm
Offline
Joined: 2008-09-11
Points: 0

Hi patrizio,

I ran it under ubuntu, on a dual quad-core 2GHz:

[java] ***************
[java] Functional Test
[java] ***************
[java] echoString(Hello): Hello
[java] --------------------------------------
[java] Echo String Performance
[java] Call Rate: 24.874384 calls/sec
[java] Mean Request Time: 40.201000 millisecs/call
[java] --------------------------------------

I'm going to try running it in glassfish to try to separate the http webserver from the web services code.

Eric

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Hi eric,

> [java] ***************
> [java] Functional Test
> [java] ***************
> [java] echoString(Hello): Hello
> [java] --------------------------------------
> [java] Echo String Performance
> [java] Call Rate: 24.874384 calls/sec
> [java] Mean Request Time: 40.201000 millisecs/call
> [java] --------------------------------------

These are the same performance as I saw under Fedora, on a similar platform as yours.

Don't you think they are really low performances...???

Keep me posted...!

ericm
Offline
Joined: 2008-09-11
Points: 0

Yes, those results on Ubuntu seem unusually low, especially when I compare them with the results from my mediocre windows box:

[java] ***************
[java] Functional Test
[java] ***************
[java] echoString(Hello): Hello
[java] --------------------------------------
[java] Echo String Performance
[java] Call Rate: 102.732690 calls/sec
[java] Mean Request Time: 9.703000 millisecs/call
[java] --------------------------------------

I then ran the test on my windows box in glassfish:

***************
Functional Test
***************
echoString(Hello): Hello
--------------------------------------
Echo String Performance
Call Rate: 84.545147 calls/sec
Mean Request Time: 11.812000 millisecs/call
--------------------------------------

I'm not sure why it would be so slow in the linux environment. I checked and it's using the local loopback connector. Any ideas or other tests I could do would be greatly appreciated.

Eric

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Eric,

I did also some tests running client and server in different machines (even client in windows and server in linux) and I had performances like those in linux.

So what I'm worried about is why SE http server performances are so low in remote connection and not in loopback ..??

Besides I'm not interested, as many others I think, in having high loopback performances, but high over network performances.

My advise is to test performances in remote mode connection, so that we can understand why SE http goes so slow, and where it could be starving.

Patrizio

ericm
Offline
Joined: 2008-09-11
Points: 0

Patrizio,

>My advise is to test performances in remote mode connection, so that we can understand why SE http goes so slow, and where it could be starving.

Here is a test from the
ubuntu client to the windows server

[java] ***************
[java] Functional Test
[java] ***************
[java] echoString(Hello): Hello
[java] --------------------------------------
[java] Echo String Performance
[java] Call Rate: 20.646227 calls/sec
[java] Mean Request Time: 48.434000 millisecs/call
[java] --------------------------------------

Eric

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Hi Eric,

they seem completely coherent with those in linux machine.

My thoughts are:

1) SE Http server performances are those we can see on:
- linux machine in loopback mode
- in remote connection
and they are coherently the same.

2) Performances we can see in Windows in Loopback mode are not real and I think they come from a "smart" managing of loopback connection in Windows systems.

So, what I'd really like to know is why SE Http Server performances are so low compared to Glassfish.

I think we should investigate this point first to understand if we can do something for improving the performances.

Patrizio

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Any news on this point...??

Glen Mazza

metro-3 wrote:
>
> Any news on this point...??
>

As for your question, "So, what I'd really like to know is why SE Http
Server performances are so low compared to Glassfish," I would guess the SE
http server is primarily for demonstration or low-usage cases, not for
high-demand production circumstances. Unless I'm missing something here,
I'm not sure why you would find it so surprising that a production
application server can handle large numbers of requests more efficiently and
more quickly.

Glen
--
View this message in context: http://www.nabble.com/WS-slow-over-network-tp19037941p19635704.html
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

whartung
Offline
Joined: 2003-06-13
Points: 0

> As for your question, "So, what I'd really like to
> know is why SE Http
> Server performances are so low compared to
> Glassfish," I would guess the SE
> http server is primarily for demonstration or
> low-usage cases, not for
> high-demand production circumstances. Unless I'm
> missing something here,
> I'm not sure why you would find it so surprising that
> a production
> application server can handle large numbers of
> requests more efficiently and
> more quickly.

There's a distinction between "high-demand" production and "working at all". So far, I'd argue that when using JAX-WS with SE, OVER THE NETWORK, it is unusable. I mean, completely unusable for ANY traffic load. 5 msgs per second? Absurd.

It would be another thing if the problem was with scaling to dozens or hundreds of clients, but it's not. It's a single client. One thread. And over the network, it's terrible.

Then, you consider that when you run locally, single client, single thread, routing through the Localhost LOOPBACK (i.e. 127.0.0.0) where the network interface "gets out of the way", we get 100+ msgs per second. Which, I'd argue, isn't a horrible number and quite useful for a lot of "production" applications.

But we can't get that number over a network. Only on the same host -- which kind of defeats the purpose.

Then, of course, you get the head scratching of the same trivial benchmark, over loopback, gets us only 84 msgs/sec against Glassfish, which is supposed to be production ready. Now, it's fair to argue that perhaps GF will scale better, and keep at 84 messages over a larger client load than the SE engine will. I don't know, we didn't test it.

I forget what number we got running GF over the network.

Mind, we got far far worse numbers on Ubuntu (on faster hardware) in loopback than we did with Windows -- who knows why.

And what bothers me the most is how JAX-WS EVEN KNOWS the difference between a network client and a loopback client. How does it know? Why should the JAX-WS stack behave any differently?

But the profiles are completely different between the two, and it's all in the JAX-WS stack.

Glen Mazza

metro-3 wrote:
>
> Mind, we got far far worse numbers on Ubuntu (on faster hardware) in
> loopback than we did with Windows -- who knows why.
>
> And what bothers me the most is how JAX-WS EVEN KNOWS the difference
> between a network client and a loopback client. How does it know? Why
> should the JAX-WS stack behave any differently?
>

I think I can at least solve the Ubuntu/Windows mystery for you. Loopbacks
do not trigger TCP/IP activity in Windows like they do in Ubuntu:
http://wiki.wireshark.org/CaptureSetup/Loopback , so it could be understood
why the latter would be much slower.

Glen
--
View this message in context: http://www.nabble.com/WS-slow-over-network-tp19037941p19638244.html
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

ericm
Offline
Joined: 2008-09-11
Points: 0

patriziomunzi,

I would like to try to duplicate your results.

>1) I ran both WS SE embedded HTTP server and client on the same laptop. >Client (single thread) was connecting the server in loopback mode.

How did you setup the client so that it would connect to the server in loopback mode? Are you using Java 5 or Java 6?

Thanks,

Eric

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

eric,

I'm using Java SE 6 u7 + JAX-WS 2.1.4.
You can also find a better description of my environment in this thread:
http://forums.java.net/jive/thread.jspa?threadID=46943&tstart=0

About my test application, I've attached a zip file containing a simple extract of classes I'm using for test.

Keep me posted, I'm really really interested in improving HTTP Server WS performances.

Thanks

jitu
Offline
Joined: 2003-06-14
Points: 0

We need to push streambuffer jars to maven, there are few bug fixes in this area. Let me do that soon. Otherwise 2.1.5-SNAPSHOT looks good.

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Going ahead in my over the network performance tests I noticed a strange behavior.

First of all let me describe my test:
- I ran both WS server and client in the same machine, and the client was connecting the server in loopback mode.
- WS implentation was a simple echoString method published by using Endpoin.publish() method and run in the Java SE embedded Http server
- Client was a single thread application performing as many as possible calls of WS method

I ran this test over three different machines:
1) my laptop (windows): higher power
2) A unix based machine: medium power
3) a Sun Solaris machine: lower power

The result were evaluated by calculating mean call latency:
1) 0.0005 secs - CPU utilization 100%
2) 0.04 secs - CPU 5%
3) 0.2 secs - CPU N.A.

I cannot understand why performances in last two machine are so bad and, especially, why in those last cases CPU utilization doesn't saturate.

The tests I ran were the same so where's the bottleneck...??

ANY IDEAS....?????

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

I ran another test which made me even madder about performance problem:

This time I ran the test as previous post by using two equal laptop with good power (intel centrino Core 2 Duo with 2GB of memory).

I made the following two tests:
1) I ran both WS SE embedded HTTP server and client on the same laptop. Client (single thread) was connecting the server in loopback mode.

In this case I had good performance results.
Mean latency= 0.0005 secs
Rate=2000 calls/sec

2) I ran WS SE embedded HTTP Server in one laptop and client in the other one. In this case single thread client was connecting the server over the network.

Here I had very bad performances:
Mean latency=0.2 secs
Rate=5 calls/secs
CPU_server = 2%
CPU_client = 1%

So, since I verified that there are no problems with my internal network I can't really understand the performance gap between the two cases.
Moreover, since
Where could be the bottleneck..?

Does anyone know if there are some kind of differences by using jaxws in loopback mode and network mode...???

Please help me,
I don't really know where hitting my head...!!

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Further results:

This time I deployed the WS on GLASSFISH v2 then I ran again the same test in both loopback and remote node by using the same equal laptop.

In loopback mode I found the same results as those I got by using the SE embedded HTTP Server. I mean about 0.0005 ms call mean latency.

Instead in remote mode by connecting Glassfish from my other laptop I got much better performances than those carried out by using the SE embedded HTTP Server.
In fact by using Glassfish as application server I got a calls mean latency of 1.5 ms, really far away from 500 ms obtained in remote mode with the SE emdebbed HTTP Server.

So, I think we could finally make the following assertions:
1) SE embedded HTTP server behaves differently in loopback and remote mode. I don't know why, and I'd really like to know it.
2) Same WS on Glassfish performs worse in remote mode than in loopback, and the rather big difference can't be related to network problems.

Guys,
I'm still waiting for an opinion or answer to my doubts.

jitu
Offline
Joined: 2003-06-14
Points: 0

I think SE embedded HTTP server doesn't perform well compared to servlet containers. I am bringing this to the attention of SE networking team. Servlet containers have been there for a while and they are tested, benchmarked, tuned etc.

Regarding loop back connections and remote connections, a lot depends on OS. Sometimes loopback may not be going to through all the network layers.

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Hi Jitu,
thanks for your answer.
Indeed I was wondering if loopback was going through all network layers.

However I read a post on vivek blog reporting benchmark results on jaxws made in loopback mode with glassfih on, I guess, a unix based machine.
So may we state that on unix OS loopback mode works properly and benchmark on this OS are reliable, even if in loopback mode...??

Here's the link to vivek post:
http://weblogs.java.net/blog/vivekp/archive/2007/02/jaxws_21_fcs_fa_1.html

Thanks

Added the link to vivek's post, although I guess you know it very well :-)

Message was edited by: patriziomunzi

whartung
Offline
Joined: 2003-06-13
Points: 0

After all is said and done, I entered an issue.

https://jax-ws.dev.java.net/issues/show_bug.cgi?id=625

jitu
Offline
Joined: 2003-06-14
Points: 0

Can you also try the 2.1.x nightly, which has a newer version of http.jar.
https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=6020

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

> Can you also try the 2.1.x nightly, which has a newer
> version of http.jar.
> https://jax-ws.dev.java.net/servlets/ProjectDocumentLi
> st?folderID=6020

Since I use maven as building tool don't you think it would be far better to tie up also the releases of http.jar to the maven repository...???

jitu
Offline
Joined: 2003-06-14
Points: 0

Is the web service deployed in a servlet container or is it deployed using Endpoint.publish() API ? What version of JAX-WS are you using ? Also, are you reusing the proxy ?

whartung
Offline
Joined: 2003-06-13
Points: 0

Endpoint.publish() in a simple Java SE app.

The version is a recent snapshot which we use because it will automatically call wsgen on startup. I don't recall the exact version.

Jitendra Kotamraju

Can you try the latest nightly from https://jax-ws.dev.java.net/servlets/ProjectDocumentList?folderID=6020
It contains some improvements for light weight http server. If it
doesn't improve the performance, can you profile the server side.

Jitu

On Aug 18, 2008, at 6:19 PM, metro@javadesktop.org wrote:

> Endpoint.publish() in a simple Java SE app.
>
> The version is a recent snapshot which we use because it will
> automatically call wsgen on startup. I don't recall the exact version.
> [Message sent by forum member 'whartung' (whartung)]
>
> http://forums.java.net/jive/thread.jspa?messageID=294048
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
> For additional commands, e-mail: users-help@metro.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Hi All,

I'm facing the same perfomance problems as whartung.

I've got a simple WS published using Endpoint.publish() in a simple HttpServer on Java SE 5.0.
Moreover I'm using Maven.

So I've got two questions:

@ whartung
Did you find any solution to the performance problem...??

@ Jitu (or anyone else..)
How can I access latest development release from Maven....??
I tried to add as maven dependency the following SNAPSHOT:

com.sun.xml.ws
jaxws-rt
2.1.5-SNAPSHOT
compile

and even if I haven't got any error at compile time I get the following exception at runtime:
---------------------------
java.io.IOException
at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:268)
at com.sun.xml.ws.transport.http.HttpAdapter.publishWSDL(HttpAdapter.java:528)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:229)
at com.sun.xml.ws.transport.http.server.WSHttpHandler.handleExchange(WSHttpHandler.java:106)
at com.sun.xml.ws.transport.http.server.WSHttpHandler.handle(WSHttpHandler.java:91)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:65)
at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:65)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:68)
at sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:581)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:65)
at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:553)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.xml.stream.XMLStreamException
at com.sun.xml.stream.buffer.stax.StreamReaderBufferProcessor.getTextCharacters(StreamReaderBufferProcessor.java:599)
at com.sun.xml.ws.util.xml.XMLStreamReaderToXMLStreamWriter.handleCharacters(XMLStreamReaderToXMLStreamWriter.java:146)
at com.sun.xml.ws.server.WSDLPatcher.handleCharacters(WSDLPatcher.java:223)
at com.sun.xml.ws.util.xml.XMLStreamReaderToXMLStreamWriter.bridge(XMLStreamReaderToXMLStreamWriter.java:108)
at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:291)
at com.sun.xml.ws.server.SDDocumentImpl.writeTo(SDDocumentImpl.java:265)
---------------------------

Thanks

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

Hi again,

I solved the problem causing exception at runtime, so I was able to run my simple WS using latest JAXWS-RT 2.1.5-SNAPSHOT.

Anyway even with latest jaxws release there still is a big lack of performances.

What I'd like to know is either if this performances problem depends from my WS implementation or it is related to the Java SE embedded HTTPServer.

I hope someone could help me..

Thanks

jitu
Offline
Joined: 2003-06-14
Points: 0

Have you tried running in a servlet container ? That should tell you whether SE embedded HTTP server is slow or not(or how much slower)

patriziomunzi
Offline
Joined: 2008-08-27
Points: 0

No I didn't try it in a servlet container.

I didn't want to use a servlet container and that is why I choosed JAXWS to develop my WS.

here's my SE embedded HTTP server configuration. Maybe I did something wrong or there is something I can optimize:
-------------------------------------------
Endpoint endPoint = Endpoint.create(new ProvisioningImpl());

HttpServer server = HttpServer.create(new InetSocketAddress(8000), 10);
server.setExecutor(Executors.newCachedThreadPool());
HttpContext context = server.createContext("/Service/Provisioning");

provisioningEndPoint.publish(provisioningContext);

server.start();
------------------------------------------------

One more thing, I evaluated the time my WS takes to reply back to the client, I know it depends from a lot of things, first of all my machine, anyway that time is 0.2 seconds.

Don't you thing is a very high reply time, no matter what machine are you using??