Return-Path: Delivered-To: apmail-httpd-bugs-archive@httpd.apache.org Received: (qmail 88201 invoked by uid 500); 8 Oct 2002 09:59:48 -0000 Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: "Apache HTTPD Bugs Notification List" Delivered-To: mailing list bugs@httpd.apache.org Received: (qmail 88188 invoked from network); 8 Oct 2002 09:59:48 -0000 Date: 8 Oct 2002 10:00:44 -0000 Message-ID: <20021008100044.17571.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: bugs@httpd.apache.org Cc: Subject: DO NOT REPLY [Bug 13400] New: - The number of hit/second decrease on increase load X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13400 The number of hit/second decrease on increase load Summary: The number of hit/second decrease on increase load Product: Apache httpd-1.3 Version: 1.3.23 Platform: Sun OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: bugs@httpd.apache.org ReportedBy: ViSharma@sapient.com We are using Apache 1.3.20, and we are tuning the sevrer for optimal performance. We are using Apache Bench (ab) utility to tune the server. But we are facing a weird behaviour which is, that as we increase the load(no of concurrent virtual users), the hits/sec and throughput decreases (including the server CPU and Memory utilization). We are using a simple html file to setup our Web Server. Theoritically, the hits/sec served by any server should go to maximum level and then stay at the level irrespective of the increase load (the no. of concurrent users logging in). The server throughput would always be the same. The Response time will go up as the load is increased, but the throughput for the server remains the same. Cau anyone tell us where we are making a mistake? Are we not doing the right thing? Which all places do we need to look at? If you need more info then kindly contact me! --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org For additional commands, e-mail: bugs-help@httpd.apache.org