× 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.



Hi Martin,

we did some loadtests in spring 2003 at a customers site. The application was 
a JSP application with rather heavy database work load, not using EJBs The 
response time on the AS/400 as single server for WAS and the Database was 
rather slow (1 to 10 sec), the scalability rather bad.
The as400 has had single processor 4GB memory and 72 GB DASD with 4 big slow 
Devices; the system was sold by (guess who) ... and "tuned" for this 
environment.
The results showed up, that every other combination was faster than this. WAS 
running even on a little NT Box was faster and scaled better then the one 
iron combination.
The results showed up further: 
WAS slowed down the database and the scaling of the database workload 
extremly under the given "tuning" (extra pool for the database and QPFRADJ 
activated).
The as400 would have needed much more DASD Devices for the database Workload 
(Performance Capability and other official papers recommend 30 disk arms for 
a balanced system of this CPW).

Another experience in this project was, that WAS on NT was much more stable 
than on AS400. For NT patches have been no issue, one fixpack and it works. 
On as400 ? PTF after PTF and the support ? in Germany ? ???

Maybe for extreme scalability, on the biggest as400, there might be an 
advantage, but I never saw this in real life and I don't believe so much on 
marketing people and I would suppose for this installations you would need 
load balancing from the full version of WAS, never offered for as400, but all 
other ibm plattforms.

My personal conclusion is: run the database on as400 (if the custumor wants 
this), run WAS on an INTEL platform (cheapest in memory and processor speed 
and fast cache) if possible (if the customer prefers as400, he pays the 
hardware), write your application without any app server specifica and with 
minimal specifica of the database and it runs on nearly any mix of hardware 
and appserver combination.

Dieter


On Wednesday 09 July 2003 23:08, you wrote:
> Hi all
>
> For those of you running WAS, what platform are you running it on? We're
> about to start development on a new order entry project that will use
> WebSphere and initially I just assumed we'd want WAS running natively on
> the iSeries. Then in talks with a BP about hardware upgrades (two 730s to
> upgrade by October), running WAS on an xSeries was mentioned. The BP had
> recently finished a project which had WAS on Linux on an xSeries, and it
> was performing very well. It got me thinking, as the cost of the extra
> RAM we'd need to put on the iSeries to cope with WAS should easily cover
> the cost of a suitably equipped Lintel server. Plus there's the cost of
> activating another processor if the extra WAS workload on the iSeries
> slowed other processes down.
>
> How much difference is there in running WAS on a different platform (or
> even LPAR) to the database (plus a large number of legacy RPG batch apps
> in our case). Is there much latency introduced or any other big
> disadvantages to non-native WAS? Does a lot depend on the type of
> workload - transactional vs enquiry etc?
>
> I'm sure we'll get good advice from the BPs involved, but I'd appreciate
> thoughts from those of you who've already gone down this route.
>
> Regards, Martin

-- 
mfG

Dieter Bender


DV-Beratung Dieter Bender
Wetzlarerstr. 25
35435 Wettenberg
Tel. +49 641 9805855
Fax +49 641 9805856
www.bender-dv.de

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.