Rich_Buttenhoff
Member
--=====================_7168941==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
All,
I spent quite a bit of time on the phone with Seagull Customer Support
yesterday. They do have some good talent there, as dr2 mentioned in an
earlier post. Here, in a nutshell, is what we discussed and what our
approach will be:
They basically said that there are 4 major areas related to performance
(realizing that there are many variables - what all is running on your
AS/400, how is it tuned, what is your network traffic like, how is your pc
configured, what all do you have running on it, etc).
1) AS/400 HTTP Server. Any tuning applied here will increase/decrease the
time it takes for the as/400 sign-on screen to appear after hitting the
URL. For us, this is about 5 times faster than the Windows Client
already. Once the user signs on, the performance of the Java Client will
be no different than the Windows Client with regards to AS/400 HTTP Server
tuning. However, when you start adding users to the formula (we'll have
350 concurrent), an AS/400 that serves 900 windows clients will serve 300
Java clients.
2) Network Bandwidth. The more the merrier of course. The Jwalk Windows
Client sends packets that are 2k in size and the Java Client will send
packets that are 3k or 4k in size. A sniffer or network monitor will be
able to show whether or not bandwidth is sufficient. On a 10mb Shared
ether, 27% average utilization is considered saturated. If the network is
switched, this percentage can be much higher.
3) Client PC configuration. JVM will run better on a larger client - much
like the network issue. The faster the system and the more memory the
better. Seagull recommends a Pentium III 450 mhz client with 128 mb RAM
for OPTIMUM performance and a straight Pentium 100 is going to struggle.
4) Upgrade the JWalk Server from 3.1 to 3.1C3 - three releases ahead of
where we are now. This alone, they claim, will be like night and
day. They have done much to manage PC resources more efficiently, etc.
The emphasis of the discussion was on # 4 then # 3.
So, the first thing we will do is upgrade our Jwalk Software. The latest
version will be out by the 19th or so. I'm hoping that this will give us
good response times since we aren't going to be able to change the other
options much. If so, we will do some load testing.
I'll post the results if anyone is interested.
Rich
===========================================================
Rich Buttenhoff Phone
208)799-4181
Potlatch Corporation Fax208)799-1687
805 Mill Road Mailto:[email protected]
Lewiston, ID 83501-1016 http://www.potlatchcorp.com
===========================================================
Walking on water and programming from
specifications are easy, if both are frozen.
===========================================================
--=====================_7168941==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
All,
I spent quite a bit of time on the phone with Seagull Customer Support
yesterday. They do have some good talent there, as dr2 mentioned in
an earlier post. Here, in a nutshell, is what we discussed and what
our approach will be:
They basically said that there are 4 major areas related to performance
(realizing that there are many variables - what all is running on your
AS/400, how is it tuned, what is your network traffic like, how is your
pc configured, what all do you have running on it, etc).
1) AS/400 HTTP Server. Any tuning applied here will
increase/decrease the time it takes for the as/400 sign-on screen to
appear after hitting the URL. For us, this is about 5 times faster
than the Windows Client already. Once the user signs on, the
performance of the Java Client will be no different than the Windows
Client with regards to AS/400 HTTP Server tuning. However, when you
start adding users to the formula (we'll have 350 concurrent), an AS/400
that serves 900 windows clients will serve 300 Java clients.
2) Network Bandwidth. The more the merrier of course. The
Jwalk Windows Client sends packets that are 2k in size and the Java
Client will send packets that are 3k or 4k in size. A sniffer or
network monitor will be able to show whether or not bandwidth is
sufficient. On a 10mb Shared ether, 27% average utilization is
considered saturated. If the network is switched, this percentage
can be much higher.
3) Client PC configuration. JVM will run better on a larger client
- much like the network issue. The faster the system and the more
memory the better. Seagull recommends a Pentium III 450 mhz client
with 128 mb RAM for <u>OPTIMUM</u> performance and a straight Pentium 100
is going to struggle.
4) Upgrade the JWalk Server from 3.1 to 3.1C3 - three releases ahead of
where we are now. This alone, they claim, will be like night and
day. They have done much to manage PC resources more efficiently,
etc.
The emphasis of the discussion was on # 4 then # 3.
So, the first thing we will do is upgrade our Jwalk Software. The
latest version will be out by the 19th or so. I'm hoping that this
will give us good response times since we aren't going to be able to
change the other options much. If so, we will do some load testing.
I'll post the results if anyone is interested.
Rich
<x-sigsep>
</x-sigsep>
===========================================================
Rich
Buttenhoff
Phone208)799-4181
Potlatch
Corporation
Fax208)799-1687
805 Mill Road
Mailto:rich.buttenhoff@potlatchcorp.<a href="mailto:[email protected]" eudora="autourl">com
</a>Lewiston, ID
83501-1016
http://www.potlatchcorp.<a href="http://www.potlatchcorp.com/" eudora="autourl">com
</a>===========================================================
Walking on water and programming from
specifications are easy, if both are frozen.
===========================================================
</html>
--=====================_7168941==_.ALT--
Content-Type: text/plain; charset="us-ascii"; format=flowed
All,
I spent quite a bit of time on the phone with Seagull Customer Support
yesterday. They do have some good talent there, as dr2 mentioned in an
earlier post. Here, in a nutshell, is what we discussed and what our
approach will be:
They basically said that there are 4 major areas related to performance
(realizing that there are many variables - what all is running on your
AS/400, how is it tuned, what is your network traffic like, how is your pc
configured, what all do you have running on it, etc).
1) AS/400 HTTP Server. Any tuning applied here will increase/decrease the
time it takes for the as/400 sign-on screen to appear after hitting the
URL. For us, this is about 5 times faster than the Windows Client
already. Once the user signs on, the performance of the Java Client will
be no different than the Windows Client with regards to AS/400 HTTP Server
tuning. However, when you start adding users to the formula (we'll have
350 concurrent), an AS/400 that serves 900 windows clients will serve 300
Java clients.
2) Network Bandwidth. The more the merrier of course. The Jwalk Windows
Client sends packets that are 2k in size and the Java Client will send
packets that are 3k or 4k in size. A sniffer or network monitor will be
able to show whether or not bandwidth is sufficient. On a 10mb Shared
ether, 27% average utilization is considered saturated. If the network is
switched, this percentage can be much higher.
3) Client PC configuration. JVM will run better on a larger client - much
like the network issue. The faster the system and the more memory the
better. Seagull recommends a Pentium III 450 mhz client with 128 mb RAM
for OPTIMUM performance and a straight Pentium 100 is going to struggle.
4) Upgrade the JWalk Server from 3.1 to 3.1C3 - three releases ahead of
where we are now. This alone, they claim, will be like night and
day. They have done much to manage PC resources more efficiently, etc.
The emphasis of the discussion was on # 4 then # 3.
So, the first thing we will do is upgrade our Jwalk Software. The latest
version will be out by the 19th or so. I'm hoping that this will give us
good response times since we aren't going to be able to change the other
options much. If so, we will do some load testing.
I'll post the results if anyone is interested.
Rich
===========================================================
Rich Buttenhoff Phone
208)799-4181Potlatch Corporation Fax
208)799-1687805 Mill Road Mailto:[email protected]
Lewiston, ID 83501-1016 http://www.potlatchcorp.com
===========================================================
Walking on water and programming from
specifications are easy, if both are frozen.
===========================================================
--=====================_7168941==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
All,
I spent quite a bit of time on the phone with Seagull Customer Support
yesterday. They do have some good talent there, as dr2 mentioned in
an earlier post. Here, in a nutshell, is what we discussed and what
our approach will be:
They basically said that there are 4 major areas related to performance
(realizing that there are many variables - what all is running on your
AS/400, how is it tuned, what is your network traffic like, how is your
pc configured, what all do you have running on it, etc).
1) AS/400 HTTP Server. Any tuning applied here will
increase/decrease the time it takes for the as/400 sign-on screen to
appear after hitting the URL. For us, this is about 5 times faster
than the Windows Client already. Once the user signs on, the
performance of the Java Client will be no different than the Windows
Client with regards to AS/400 HTTP Server tuning. However, when you
start adding users to the formula (we'll have 350 concurrent), an AS/400
that serves 900 windows clients will serve 300 Java clients.
2) Network Bandwidth. The more the merrier of course. The
Jwalk Windows Client sends packets that are 2k in size and the Java
Client will send packets that are 3k or 4k in size. A sniffer or
network monitor will be able to show whether or not bandwidth is
sufficient. On a 10mb Shared ether, 27% average utilization is
considered saturated. If the network is switched, this percentage
can be much higher.
3) Client PC configuration. JVM will run better on a larger client
- much like the network issue. The faster the system and the more
memory the better. Seagull recommends a Pentium III 450 mhz client
with 128 mb RAM for <u>OPTIMUM</u> performance and a straight Pentium 100
is going to struggle.
4) Upgrade the JWalk Server from 3.1 to 3.1C3 - three releases ahead of
where we are now. This alone, they claim, will be like night and
day. They have done much to manage PC resources more efficiently,
etc.
The emphasis of the discussion was on # 4 then # 3.
So, the first thing we will do is upgrade our Jwalk Software. The
latest version will be out by the 19th or so. I'm hoping that this
will give us good response times since we aren't going to be able to
change the other options much. If so, we will do some load testing.
I'll post the results if anyone is interested.
Rich
<x-sigsep>
</x-sigsep>
===========================================================
Rich
Buttenhoff
Phone
208)799-4181Potlatch
Corporation
Fax
208)799-1687805 Mill Road
Mailto:rich.buttenhoff@potlatchcorp.<a href="mailto:[email protected]" eudora="autourl">com
</a>Lewiston, ID
83501-1016
http://www.potlatchcorp.<a href="http://www.potlatchcorp.com/" eudora="autourl">com
</a>===========================================================
Walking on water and programming from
specifications are easy, if both are frozen.
===========================================================
</html>
--=====================_7168941==_.ALT--
