ID: 14254
Comment by: neil dot wilkinson at transport dot nsw dot gov dot au
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:
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
--
Previous Comments:
------------------------------------------------------------------------
[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 ;-)
------------------------------------------------------------------------
[2002-05-25 09:13:10] alan dot frostick at iconmedialab dot com
Referring to Bug #14254.
I can give some background clues which might help in resolving the
intermittent SQLCODE=-439 error faster.
I support the php scripts for the same server which Cedric supports.
We
have noted that our client has increased their volume of data and
traffic to the site dramatically since their intranet's inception over
a
year ago.
They're still using php3 (we're trying to convince them to pay us to
convert their scripts to php4, but presently can't guarantee this
would
resolve the problem since it's still being reported by others using
php4).
The effect seen is a refusal to connect to informix, caused by a peak
in
traffic. It's not something which is easily duplicated in a test
environment, and is a mercurial problem in that as soon as it occurs,
it
often dissappears again as suddenly. We've seen it occur regularly for
up to 40 minutes and then go away for several days.
Recently the complaint has been that some scripts simply return an
empty
page. On investigation this week I discovered these scripts were
building massive arrays while remaining connected to informix, and
apparently exceeding maximum script memory. It happens within 4-5
seconds so can't be the result of a timeout.
I suspect this is giving rise to accumulated garbage somewhere or
leaving locks in the database and has a serious effect on subsequent
attempts to connect to informix, which (sometimes) return SQLCODE=-439
error codes from ifx_connect().
We've tried using both ifx_connect and ifx_pconnect for the scripts,
but
this makes no apparent difference, just as increasing connection
limits
has failed to.
I've since optimised some of the offending scripts and this seems to
alleviate the problem in the short-term, but a huge overhaul of the
methods used is overdue but cannot be done so quickly, given the
complexity of the intranet.
We'd like a resolution of the problem as soon as possible, even with
scripts timing out or exceeding memory limits. I see you've recently
improved the memory threading, and wonder if this could finally crack
this long-standing problem?
Alan Frostick
------------------------------------------------------------------------
[2001-11-28 07:26:16] cedric dot boudin at iconmedialab dot com
a short script would not reproduce the conditions for recreating the
failure.
It happens when we have a lot of load and this with big scripts using
lots of memory and sometimes timing out.
If the timeout comes from the db connection being lost or vice versa is
hard to say
If we could isolate where in the php ifx interface callback functions
are used we would be a step further in solving this.
------------------------------------------------------------------------
[2001-11-27 12:57:34] [EMAIL PROTECTED]
Can you please add a short PHP script with which you can
reproduce this ? Also, please try PHP 4.1.0 (to be released
very soon now) as it has some improvements to the threading
which might actually fix this problem.
(it was mentioned as one possibility in that mail you
pointed to in the archives)
I don't have informix installed or any knowledge how to
set it up either so you need to help us in this.
And I don't have much time to spend on this either so please
be patient.
--Jani
------------------------------------------------------------------------
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
