-
1. Re: Performance Issue JbossNet -Java Client
osdchicago May 18, 2003 2:13 PM (in response to felix_pardos)Can you list out the exact steps you see in tcpmon when you are using the Web Services? Plus give any log entries for JBoss when you invoke the Web Services. Also, if you know which step is taking a lot of time, please list that. This will enable the JBoss-Net developers to locate the bottleneck and see if anything can be improved. As an aside, Web Services by nature are themselves performance-intensive.
-
2. Re: Performance Issue JbossNet -Java Client
felix_pardos May 20, 2003 10:07 PM (in response to felix_pardos)At this moment, we are on 13 seconds.
Having tcpmon running, 12 seconds pass
on waiting for request. On 13th second
request is processed extremely fast, a fraction
of a second to send response.
So it seems the delay is on client side.
We are not using UDDI so the web service
is referenced in the target end URL
http://server:8070/jbossnet/service/mainservice?wsdl
wsdl was generated by JbossNet. The client was
generated by AXIS WSDL2Java tool.
Thanks
Felix. -
3. Re: Performance Issue JbossNet -Java Client
felix_pardos May 20, 2003 10:11 PM (in response to felix_pardos)At this moment, we are on 13 seconds.
Having tcpmon running, 12 seconds pass
on waiting for request. On 13th second
request is processed extremely fast, a fraction
of a second to send response.
So it seems the delay is on client side.
We are not using UDDI so the web service
is referenced in the target end URL
http://server:8070/jbossnet/service/mainservice?wsdl
wsdl was generated by JbossNet. The client was
generated by AXIS WSDL2Java tool.
Thanks
Felix. -
4. Re: Performance Issue JbossNet -Java Client
felix_pardos May 20, 2003 10:14 PM (in response to felix_pardos)At this moment, we are on 13 seconds.
Having tcpmon running, 12 seconds pass
on waiting for request. On 13th second
request is processed extremely fast, a fraction
of a second to send response.
So it seems the delay is on client side.
We are not using UDDI so the web service
is referenced in the target end URL
http://server:8070/jbossnet/service/mainservice?wsdl
wsdl was generated by JbossNet. The client was
generated by AXIS WSDL2Java tool.
Thanks
Felix. -
5. Re: Performance Issue JbossNet -Java Client
felix_pardos May 20, 2003 10:16 PM (in response to felix_pardos)At this moment, we are on 13 seconds.
Having tcpmon running, 12 seconds pass
on waiting for request. On 13th second
request is processed extremely fast, a fraction
of a second to send response.
So it seems the delay is on client side.
We are not using UDDI so the web service
is referenced in the target end URL
http://server:8070/jbossnet/service/mainservice?wsdl
wsdl was generated by JbossNet. The client was
generated by AXIS WSDL2Java tool.
Thanks
Felix. -
6. Re: Performance Issue JbossNet -Java Client
jonlee May 21, 2003 5:22 AM (in response to felix_pardos)How are you measuring the elapsed time? Is it from when you run the command line? Also, are there any execution time differences when going directly to the service (without TCPMON)?
You may want to put some time logs say first line of code to time the web service protocol is started and when it returns to get some breakdown of execution. -
7. Re: Performance Issue JbossNet -Java Client
osdchicago May 27, 2003 10:31 PM (in response to felix_pardos)SOAP/HTTP is supposed to be 10-100 times slower than RMI/IIOP. So web services are naturally slow.
-
8. Re: Performance Issue JbossNet -Java Client
mikesu Jul 14, 2003 11:38 AM (in response to felix_pardos)SOAP/HTTP is supposed to be 10-100 times slower than RMI/IIOP. So web services are naturally slow.
Weblogic http tunneling is only 3 times slower than RMI. (and btw weblogic with tunneling http access speed = jboss with RMI) What a pity it's not free :-/ -
9. Re: Performance Issue JbossNet -Java Client
spohl Jul 18, 2003 11:19 AM (in response to felix_pardos)Can it be that you test within an Microsoft Windows (perhaps NT) environment?
Then take a look at what happens when you start a new Internet Explorer the first time after system start. In an intranet environment there is a configuration option in the registry to tell the IE to load proxy settings etc. from a central location in the network. This process will happen again and again in your client. Stop the time, looks like the same duration, hein?
The only solution I have at the moment is to turn this automatic configuration option.
Look at
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Rename the keys beginning with AutoConfig (..Proxy & ..URL) to something different and try IE and your progs again, what a difference?
Please let me know if you have another solution!
Regards