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



Aaron,

I'm pretty certain we ran into this as well (or something similar to
it). We were having problems with our database, jobs would hang, HTTP
requests would queue (users' natural instinct when something doesn't
work is to hit refresh) and at some point the server would become
swamped.

We had already implemented Cisco CSS appliances to do load balancing
across multiple pieces of hardware (for higher availability), so we
created more Apache instances, and we also reconfigured our load
balancing to separate traffic among one group of Apache servers acting
as front-ends for app servers and another group handling nothing but
requests for static assets. After being forced into it, we developed
a pretty strong topology. However, I am extremely fortunate to work
for an organization that was willing to make these sorts of
investments. Then we got the database situation resolved, and all is
back to normal (for now :)

Mike E.

On Thu, Sep 25, 2008 at 6:03 PM, Aaron Bartell <aaronbartell@xxxxxxxxx> wrote:
But there is only so much increasing on both sides that you can do, much
less just the OS400 job side. At some point increasing OS400 jobs will only
slow things down because the ones currently running are waiting in line for
their time-slice. At one point I think we had a couple hundred Apache jobs
running and that still wasn't enough to keep up with JMeter on a powerful
desktop spawning multiple hundreds of threads at a time. Note that I put
together a very simple write-to-standard-out CGI program for these test to
insure there was very little time spent in the OS400 job.

I am not saying the scenario will happen a lot, but we were able to
re-create the error on request (no pun intended :-) using JMeter.

In the end this comes down to making sure you have the processing power
(CPW/HD-controllers/Memory) to facilitate the amount of traffic.

Aaron Bartell
http://mowyourlawn.com


On Thu, Sep 25, 2008 at 4:48 PM, Thorbjørn Ravn Andersen <ravn@xxxxxxxxxx>wrote:

Aaron Bartell skrev:
with IBM). It turns out that Apache has a configurable finite amount of
queueing it can do for requests coming in on a port (which is a process
completely separate and before the request hits an OS400 job). As I

Your description sounds like it is the queue in the TCP/IP layer in the
operating system and not Apache as such, where the request is being
denied by the operating system and not by Apache. Increasing this
value is not a good idea since it does not cure the problem.

Try increasing the number of active Apache instances/threads/workers
(cannot recall the name they use) which should allow apache to service
incoming requests faster.


--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.



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.