Hi.
>trip. Packet sizes were on the order of 1000 bytes. Over a 100 Mbps
>LAN, that's about 0.1 ms transport time, which is very small compared
>to the overall round trip times that were more like 90 ms. This may
>point out a difference in our tests: mine were relatively processing
>intensive, while yours may be more network intensive.
>LAN, that's about 0.1 ms transport time, which is very small compared
>to the overall round trip times that were more like 90 ms. This may
>point out a difference in our tests: mine were relatively processing
>intensive, while yours may be more network intensive.
The transmission occurs over a standard LAN conenction however it seems to to be in the order of 20 seconds rather than ms.
>however, I seem to recall that copies sold under development license
>were restricted in the number of worker threads. I don't know
>whether 4 is similar (or whether you are even using a development
>license).
>were restricted in the number of worker threads. I don't know
>whether 4 is similar (or whether you are even using a development
>license).
This is correct but we are using a non-development license on a test server.
We are sending large packets over the network, they comprise of a number of self defined objects.
You mentioned pools previously - were you able to control these in jrun 3?
Cheers again
Jonathan
Scott Nichol <[EMAIL PROTECTED]> wrote:
> Hi again Scott,
>
> >similar to yours, in that the average response time for a request
> >remained fairly consistent.
>
> Does this mean that the amount of time to get a response back from a request was the same in your test for 1 and mutliple transactions. I would of thought an a noisy channel there would have been some performance issue?
The response time was not *exactly* maintained when adding more
client threads, but it was closer to constant than what you describe.
In my tests, network I/O was a very small part of the total round
trip. Packet sizes were on the order of 1000 bytes. Over a 100 Mbps
LAN, that's about 0.1 ms transport time, which is very small compared
to the overall round trip times that were more like 90 ms. This may
point out a difference in our tests: mine were relatively processing
intensive, while yours may be more network intensive.
>
> >The configuration of your Web server, servlet container and even
> >server OS can impact your results. All 3 likely have a pool of
> >threads and/or memory structures from which resources are allocated
> >to service requests. If the pools are small, your SOAP requests will
> >sit in the queue longer. Making sure the pools are large enough is
> >essential to obtain proper throughput.
>
> I'm running the soap server on a JRUN 4 server, do you have any advice on j2ee settings. Do you have any advice on how to manipluate the pools and which pools! What settings do usually amend on your j2ee app server, or elsewhere
I don't have a copy of JRun 4 available. I used JRun 3 some time
ago, but I understand 4 was a pretty significant re-write. With 3,
however, I seem to recall that copies sold under development license
were restricted in the number of worker threads. I don't know
whether 4 is similar (or whether you are even using a development
license).
As I said, there may also be differences in our test services.
Perhaps you are sending much bigger packets or doing much less
processing. I would think that as the transport time and total round
trip times get closer, you would start having increasing Ethernet
collisions as you added client threads.
Scott Nichol
Do not reply directly to this e-mail address,
as it is filtered to only receive e-mail from
specific mailing lists.
Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger
