ID: 14254
Comment by: shai at shai dot org
Reported By: cedric dot boudin at iconmedialab dot com
Status: Closed
Bug Type: Informix related
Operating System: Solaris 8
PHP Version: 4.0.6
New Comment:
I am using AIX4.3.3
Apache 1.3.22
PHP 4.3.1
Infrmx 7.3.1
Same problem, I am using the RS6000-M80 and I can reproduce the
problem
when I am the only person on the machine with small queries. I suspect
that this maybe an apache related issue. I notices that my apache has
spawned off 20+ children. So I started messing with the persistant
connection and timeout options, seems to have made the problem go away
for now. Even with multiple hits, apache doesn't seems to be spawning
more than 12 helpers.
Any comments from anyone?
Previous Comments:
------------------------------------------------------------------------
[2003-06-09 14:59:52] klightse at water dot ca dot gov
We are seeing the same bug. We just discovered it, two days before we
go into production. Talk about a timing issue....
Solaris 8
Apache 1.3.26
PHP 4.3.0
Informix 9.3uc3
If anyone knows the solution, please post it. We are going to have to
reprogram this site in JSP if we can't fix it.
------------------------------------------------------------------------
[2003-04-25 12:44:15] jswinborne at nwc dot edu
I am also experiencing this error. It seems to come and go randomly.
We are using PHP 4.2.1 with Redhat 9.
------------------------------------------------------------------------
[2003-02-23 20:32:39] neil dot wilkinson at transport dot nsw dot gov
dot au
This problem still exists and does indeed occur most often when the
database is busy.
However, there will always be situations where the database is busy, so
increasing performance will only help in some situations.
The problem appears to be to do with how PHP responds to the callback
functions. I believe that the apache and native ESQL libraries are bug
free in this respect because embedded perl, etc (hitting the same
database from the same machine using the same ESQL libraries) never has
this problem.
Is there anyone out there that understands the PHP IFX source code and
could fix the callback functionality. Failing that I could have a go
if given some assistance.
FYI, the server specifics are:
Solaris 2.6
Apache 1.3.27
PHP 4.2.3
ESQL 7.24.UC6
Informix 7.30.UC8
Please do not close this bug unless the problem has been solved.
Several instances around this bug have been closed by the solution
"upgrade hardware" where there is clearly still an error to be fixed.
Regards,
Neil Wilkinson
--
------------------------------------------------------------------------
[2002-07-06 17:35:16] pschmidt at naxs dot net
Well, I see this problem every time I run my scripts. We are running:
PHP 4.2.1
Apache 1.3.24
ESQL/C Version 9.51
Some of the Informix tables are large.
Since I am seeing this consistently, I would really like to see a fix
to this problem. My scripts are somewhat complicated. But I can
reproduce the problem with a simple script. It contains:
-----------------------------------------------------------
<?php
// create connection
$connection = ifx_connect("<deleted>", "<deleted>", "<deleted")
or die("Couldn't create connection.");
// create SQL statement
$sql = "SELECT f1, f2, f3, f4, f5, f6, f7, f8, f9, f10, f11, f12, f13,
f14 FROM T1 where f1 < 500";
// execute SQL query and get result
$sql_result = ifx_query($sql,$connection)
or die("Couldn't execute query");
// format result in HTML table
ifx_htmltbl_result($sql_result,"border=1");
// free resources and close connection
ifx_free_result($sql_result);
ifx_close($connection);
?>
-----------------------------------------------------------
To reproduce this, I hit the refresh button on the browser before the
page had downloaded.
I tried switching it to pconnect and still got SQLCODE=-439 failures.
Although the table is big, I think the load was light (I tried this on
a Saturday afternoon.)
Anyone that has questions, feel free to send them to me at
[EMAIL PROTECTED]
Best Regards,
Paul Schmidt
Action Web Creations
------------------------------------------------------------------------
[2002-05-25 13:15:11] [EMAIL PROTECTED]
Your problem seems to be a pure performance issue.
Unfortunately these kinds of problems present themselves in
a non-deterministic fashion, which makes the symptoms hard
or impossible to debug. The cure, however, seems clear:
upgrade to PHP 4.2, upgrade the hardware, install Zend
Optimizer, buy Zend Cache -- anything to match your server
resources with the increased load on your system.
Based on your description of the scripts used, PHP 4 alone
should bring a huge performance increase. Your client's
possible unwillingness to pay for upgrades is quite simply
*their problem*. Hang in there, iconites ;-)
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14254
--
Edit this bug report at http://bugs.php.net/?id=14254&edit=1
