|
Andy, This is what I was looking for. There are many things I don't know about websphere - or processor load sharing for that matter. I just assumed that any job running would take advantage of any processor that wasn't busy. What about the native iseries HTTP server (or even apache)? Is it able to share request loads across multiple processors (assuming a single instance of the server)? Rick ----original message---- Andy said: Subject: RE: more good iseries news My take on the paragraph - I believe that they had an application server defined within WebSphere. As they increased the load on the server it took advantage of the second server well, but received little benefit from subsequent processors. Perhaps for reason of multithreading or some other circumstance, it had two 'jobs' which took most of the processors. Additional processors would not be of benefit. At this point, a logical next step is to create another software instance of that same WebSphere server on the same machine. For whatever reason, multiple instances must have created some integration issues which they wished to avoid, thus they went with loading completely separate copies of WebSphere on physically separate servers. WebSphere is designed to expand via multiple instances on the same hardware, I don't know what the circumstances were here. That's my guess, Andy Nolen-Parkhouse > > >Rick > > > > > >The issue of maxing out on capacity was faced early on. Passer said > > >stress tests were performed at the IBM iSeries headquarters, in > > >Rochester, Minnesota. From that, it was determined that adding a > > >second processor would be "an easy fix." The next round of increasing > > >capacity is more complicated. "After two CPUs in the iSeries," Passer > > >explained, "the application server has too much overhead and doesn't > > >really offer a big advantage over multiple application server > > >instances. In all cases, it means more CPUs, but there are major > > >software issues one gets bogged down with."
As an Amazon Associate we earn from qualifying purchases.
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.