php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #20330 Isapi/mssql crashes under high load.
Submitted: 2002-11-09 16:50 UTC Modified: 2002-11-21 17:15 UTC
Votes:5
Avg. Score:4.6 ± 0.8
Reproduced:4 of 5 (80.0%)
Same Version:2 (50.0%)
Same OS:3 (75.0%)
From: murray at mha dot ca Assigned:
Status: No Feedback Package: IIS related
PHP Version: 4.2.3 OS: Windows 2000 Advanced Server
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: murray at mha dot ca
New email:
PHP Version: OS:

 

 [2002-11-09 16:50 UTC] murray at mha dot ca 
System Specifications 
- System Windows 2000 Advanced Server
- IIS5
- tested php 4.06, 4.1.2, 4.2.3 (last version tested 4.2.3)
- Dual Pentium IV 1.2 GHz
- Database SQL Server 2000


Problems
- System runs fine under ISAPI until high load at which point database refuses to connect, or IIS locks, computer requires reboot.  Under ISAPI CPU runs at about 60%.

- Same code/same system runs fine under CGI but CPU runs at 100%.  Memory only at 20-30%, no virtual memory in use, database on seperate server running at 5% CPU.

- Individual database connection times are under 2 milliseconds for ISAPI, however under CGI they are about 150-300  milliseconds.  When using CGI, there are at least 3 expensive database connections per page (however after 3 connections they seem to be pooled as they are around 2-3 ms) cause page times be at least .5 - .8 seconds per page of PURE database connect time (connect time tends to be 60-80% of page time).

- Similar pages running under Linux and FreeBSD show no signs of such problems, same under isapi however as stated above as soon as server load gets above 100-200 page hits per second server problems begin.  Many refused http connections, many refused database connections, then server crashes causing machine to need reboot (restarting IIS does not solve the problem), causing VERY pissed off client who now believes that PHP is not an enterprise ready solution and only for home/hobbiest use.

- No mention on web site that PHP was not ready for prouduction under IIS/Mssql.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-11-09 16:59 UTC] derick@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

FYI: PHP on Windows will never be as stable as PHP on Unices... due to the nature that we don't have access to the source and of course there are just very few developers who are interested in using windows in a production environment to publish their PHP sites.

Derick
 [2002-11-19 18:39 UTC] mlaukast1 at hotmail dot com 
I've had the same problem. I gave my bug report (#19541) about two months ago without receiving any answer. Anyways, have you made fixes to PHP concerning this bug? I would be more than pleased if this bug was fixed.
 [2002-11-21 17:15 UTC] sniper@php.net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2003-02-21 11:23 UTC] jayc_lawrence at hotmail dot com 
Ive been using 4.2.3 on a p2 300mhz with 192mb ram for months... and i have great performance from it. PHP renders pages in milliseconds and the cpu usage has only ever been a problem since i installed msde on the server...

however it seems silly that your 2000 adv server dual 1.2ghz has all these issues with the mentioned php versions... as ive said, my very low spec box has no problem, and it even runs XP pro.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Oct 31 09:00:01 2025 UTC