× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dieter

I have seen the performance issues you describe but mostly on older
hardware. I do use Tomcat and it does seem to be very solid with one
exception -- the Coyote connector seems flakey and can adversely impact
performance on the iSeries. The HttpConnector seems to work fine. On
relatively small systems pulling the application server off the box does
improve performance. However, that doesn't hold true for large scale
transaction intensive workloads. It is too costly to process large sets
of data on one system and ship the results back to another system. I
have benchmarked quite a few cases -- iSeries database/Linux app server
and iSeries database with iSeries app server. For reporting workloads
and with older iSeries hardware the iSeries database/Linux app server is
faster. For Transaction intensive systems like ERP systems, the single
system with multiple processors does much better. I am stress testing an
application this week as well as profiling. I profile memory use etc.
off the iSeries but the scripts are the same. Running those tests to
simulate a months worth of transactions by 20 users on a dedicated intel
server hitting the same iSeries database takes about five times longer
even with profiling turned off. 

David Morris

>>> dieter.bender@xxxxxxxxxxxx 3/9/2004 1:37:05 AM >>>
David,

in the last 2 years, I have seen 2 diffrent things in the as400 world,
I have 
never seen before, both related to webSphere installations.
There were single processor machines with WebSphere (mostly without
EJBs) and 
database on the same box. 4 to 8 huge slow disks and insufficient
memory. 
This systems were "scaled" by ibm itself for this workload and they
even 
didn't crawl; the customers were a little bit angry, when they saw
their web 
application flying on a 2000 Euro (= $) intel box with linux or even
Windows.
And I Have seen very expensive big irons, with multiprocessor, huge
memory and 
balanced storage, all work running on one box and we had to do
PWRDWNSYS to 
stop WebSphere from eating up all ressources, DMPJVM didn't work, the 
WebSphere Admin didn't work, ENDSBS didn't work and ENDJOBABN didn't
work.
In my experience the WebSphere implementation on as400 is buggy, we've
never 
seen such problems with Tomcat or JBoss on AS400 and we've never seen 
something like this with WebSphere on NT, AIX, or LINUX. Supporttimes
for 
such problems with as400 weeks (install latest Cum, install latest
Groups, 
send me JVM Dump, must work, latest cum...)
One of the reasons for the bugs in as400 might be, that ibm itself
doesn't see 
a real market for WebSphere on AS400; the full version with all
features as 
multiple JVMs and load balancing was never available for as400. I've
asked 
when it will be available at common conferences and at marketing shows
and 
I've got answers like "never heared of enterprise edition", or speakers
at 
those conferences didn't know Tomcat. 
BTW, the last fact has another drawback for an installation with a
single 
as400; at the point scalability gets an issue and you need load
balancing you 
have to change the platform for your app Server. The critical point for

scalability on the high end isn't only the number of processors (6 or
12 
might be the same). 
The point with the native data access: I've made some benchmarks and
load 
tests too; I didn't see this advantage. seperated boxes were fastest up
to 
the bandwith of the communications connection and with growing workload
the 
separated scenario outperformed the single box.

regards

Dieter

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.