#20100 [Com]: Com Performance/Memory issues
ID: 20100
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: COM related
Operating System: win2k
PHP Version: 4CVS-2002-10-25
New Comment:
Just a comment. As I understand PHP is meant to be optimal at handling
HTTP requests. This implies a relatively short period of processing
after which the script exits.
This processing model implies that a lazy approach to garbage
collection is going to be most often optimal. Or to put it
differently, all the garbage is collected when the script exits.
If handling better the case described here means the usual case is less
optimal then perhaps this behaviour should stay as-is? Allocating and
freeing huge numbers of largish (~10KB) COM objects is unusual usage.
BTW - it might be a more exact example if the vbscript code used
CreateObject() rather than GetObject().
Previous Comments:
[2002-10-25 18:27:24] [EMAIL PROTECTED]
vbscript code:
wscript.echo now
For I = 1 To 3000
set
ru=GetObject("WinMgmts:{impersonationLevel=impersonate}").InstancesOf("Win32_NetworkAdapterConfiguration")
set ru = nothing
Next
wscript.echo now
vbscript output:
C:\php\wmi>cscript wmi.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
26/10/2002 00:07:26
26/10/2002 00:08:16
php code:
$prof = new Profiler;
for ($i=0;$i<3000;$i++){
$prof->startTimer($i);
$Services = new COM("winmgmts:{impersonationLevel=impersonate}") or
die("glump");
$NetworkAdapterSet =
$Services->InstancesOf('Win32_NetworkAdapterConfiguration');
$NetworkAdapterSet->release();
$Services->release();
unset($Services);
unset($NetworkAdapterSet);
$prof->stopTimer($i);
}
php results:
C:\php\snaps\php4-win32-latest>php c:\php\wmi\wmiperf.php
Warning: (null)(): Invoke() failed: Exception occurred.
Source: SWbemServices Description: Generic failure
in c:\php\wmi\wmiperf.php on line 7
Fatal error: Call to a member function on a non-object in
c:\php\wmi\wmiperf.php
on line 8
doing it as 3 seperate runs yielded:
0-1000 runs: 11313.1239 ms (100.00 %) OVERALL TIME
1000-2000 runs: 23879.2120 ms (100.00 %) OVERALL TIME
2000-3000: 544210.0750 ms (100.00 %) OVERALL TIME
At the same time, memory utilization of winmgmt.exe rises to ~30mb from
the normal 4mb...
Looks like something isn't getting freed right...
--
Edit this bug report at http://bugs.php.net/?id=20100&edit=1
Bug #16915 Updated: Problems with super globals variables
ID: 16915
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Servlet related
Operating System: SuSe Linux 7.3
PHP Version: 4.2.0
New Comment:
This doesn't look like a PHP bug.
First, you used _SERVLET were you meant to say _SERVER in your example.
An understandable mistake for someone who spends a lot of time with
Java servlets :).
Second, the _GET and _POST arrays were empty for the simple (and
correct) reason that you did not have any GET or POST parameters to
your request.
Third, the _ENV array is empty simply because Java didn't pass any
environment values - or at least that would be my suspicion. Check
your Runtime.exec() call and the semantics of this call.
Previous Comments:
[2002-04-29 14:53:50] [EMAIL PROTECTED]
It seems to be that all super arrays are empty:
This script:
";
if (is_array($_SERVER)) {
$size = sizeof($_SERVLET);
echo "_SERVER is array $size ";
foreach ($_SERVER as $key => $value) {
echo "Key: $key value: $value ";
}
}
if (is_array($_GET)) {
$size = sizeof($_GET);
echo "_GET is array $size ";
foreach ($_GET as $key => $value) {
echo "Key: $key value: $value ";
}
}
if (is_array($_POST)) {
$size = sizeof($_POST);
echo "_POST is array $size ";
foreach ($_POST as $key => $value) {
echo "Key: $key value: $value ";
}
}
if (is_array($_ENV)) {
$size = sizeof($_ENV);
echo "_ENV is array $size ";
foreach ($_ENV as $key => $value) {
echo "Key: $key value: $value ";
}
}
echo "PHP_SELF $PHP_SELF ";
flush();
?>
as result:
Globals test:
_SERVER is array 0
_GET is array 0
_POST is array 0
_ENV is array 0
PHP_SELF /examples/php-servlet/test/global.php
The arrays are empty.
My environment:
OS=Linux 2.4.10-4GB on i386
Tomcat 3.2.3 I use only Tomcat as web server without apache.
Java version=1.3.1_03
Java vendor=Sun Microsystems Inc.
--
Edit this bug report at http://bugs.php.net/?id=16915&edit=1
Bug #16908 Updated: some date functions appear to not be getting the correct timestamp from the OS
ID: 16908 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Date/time related Operating System: Linux (RedHat 7.1) PHP Version: 4.1.1 New Comment: The only date I see coming out of phpinfo() is the "Build Date" and this accurately represents the date when the PHP executable was built. Previous Comments: [2002-04-29 21:20:30] [EMAIL PROTECTED] don't you think it qualifies as a bug of some sort that some of the PHP functions return the right date as reported by the OS, and some, like the ones phpinfo() uses, do not? [2002-04-29 21:18:18] [EMAIL PROTECTED] You all are no help. If I thought this was a support issue, I wouldn't have turned to you. But I've scoured the internet looking for some explanation as to why phpinfo() is not getting the right date. Noone seems to know. So, why don't you do something helpful and tell me why? I didn't write phpinfo(), the writers of PHP did. so tell me why its wrong? its certainly not something wrong with my server, i have the RIGHT timestamp. [2002-04-29 17:53:49] [EMAIL PROTECTED] The bug system is not the appropriate forum for asking support questions. For a list of a range of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php [2002-04-29 11:55:13] [EMAIL PROTECTED] I actually have 4.1.1 installed... and the timestamp on my system IS correct... So far, I have tested several of the date/time functions and they appear to return the correct info. However, when I run phpinfo.php, it reports the wrong date and time, different than the timestamp on my server. I've also noticed that a few plugin php services (and some CGI scripts), like news scripts and message boards, (I have not examined the code THOUROUGHLY) appear to also be getting their info from the same place that phpinfo is getting it. Since I don't know how phpinfo is getting this, and it is clearly not using the same functions for date/time as I am using, I don't know what's wrong. Could someone please look into this? I really would appreciate some suggestions on how to proceed in finding and fixing this bug. -- Edit this bug report at http://bugs.php.net/?id=16908&edit=1
Bug #14051 Updated: Invalid return in realpath if extra slash
ID: 14051 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: *Directory/Filesystem functions Operating System: Windows PHP Version: 4.0.6 New Comment: Note that "//tmp" or "\\tmp" looks like a UNC path (due to the // prefix), and therefore cannot be reduced. Previous Comments: [2001-11-20 10:39:33] [EMAIL PROTECTED] In my opinion it's not the same problem as bug #14049 !? [2001-11-14 04:56:53] [EMAIL PROTECTED] Update the #14049 bug report. DO NOT OPEN NEW REPORTS ABOUT SAME THING!! [2001-11-14 04:53:26] [EMAIL PROTECTED] On Windows : [/\tmp] -> Correct : [c:\tmp] On Linux : [/tmp] -- Edit this bug report at http://bugs.php.net/?id=14051&edit=1
Bug #16409 Updated: include_once includes multiple times
ID: 16409
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Filesystem function related
Operating System: Mac OS X 10.1.3
PHP Version: 4.1.2
New Comment:
I'd suggest that if include_once() is given two distinct paths that
just happen to work out the to same file, asking PHP to figure out that
these are the same file is too much trouble.
There are too many tricky cases (like the permissions case documented
here) that are difficult or impossible to get right. On Win32 you
could have UNC and local names pointing to the same file. On Unix you
could hard and soft links pointing to the same file. Sounds like a lot
of trouble :).
Probably the safest bet is to document include_once() and
require_once() as determining file identity strictly by name.
Previous Comments:
[2002-04-09 07:12:25] [EMAIL PROTECTED]
I installed the update and it still did not work for me. I then looked
where there might be a problem with my installation and finally found,
that the problem occurs, if the webserver does not have read access to
all directories on the path to the script file. I had my home dir set
to rwx--x--x for privacy reasons. Giving read-access for the world,
solved the problem.
I don't know if there is a way to solve this problem, but it is
definitely not nice, that the functions do not work correctly depending
on access rights.
[2002-04-06 12:31:08] [EMAIL PROTECTED]
I cannot reproduce this on either the Apple-supplied PHP
4.1.2 or a fresh 4.3.0-dev build, running on the default
Apache installation (1.3.22).
realpath() also works as expected.
Can you install Apple's new Security Update, which includes
PHP 4.1.2? If it works for you, we can start narrowing down
why it doesn't work on your custom PHP build.
[2002-04-03 06:13:57] [EMAIL PROTECTED]
There is a bug with include_once including a file twice, if it is
referenced once with a fully qualified path and once with only the
filename (and the file being in the include path). This script
illustrates what I mean:
include_once('x.php');
include_once('/home/janneck/public_html/x.php');
On my Mac OS X 10.1.3, Apache 1.3.22, PHP 4.1.2 (also: 4.0.6) system,
this results in x.php getting included twice. (It works as expected on
RedHat 7.1, Apache 1.3.22, PHP 4.0.6.)
doing "var_dump(get_included_files());" shows the following:
array(2) { [0]=> string(6) "/x.php" [1]=> string(40)
"/home/janneck/public_html/x.php" }
This might be related to a problem with the "realpath()" function which
does not work correctly but returns "" all the time.
--
Edit this bug report at http://bugs.php.net/?id=16409&edit=1
Bug #9852 Updated: Header redirect and db connection cause "CGI misbehaved"
ID: 9852
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IIS related
Operating System: Windows 2000
PHP Version: 4.1.1
New Comment:
I can reproduce the problem with a simple "bounce" page (used for
measuring roundtrip times). With two active browser windows requesting
the same page, I see this error repeat (apparently at random) on one
out of 10-40 thousand requests.
This is with PHP 4.1.2 on Windows 2000 Professional w/ IIS 5 and all
the current updates from Windows Update.
bounce.php
--
BOUNCE
BOUNCING
BOUNCE
millisecondsrequests
latest
cumulative
Previous Comments:
[2002-01-16 13:45:10] [EMAIL PROTECTED]
I have tried this with W2K server and php 4.1.1 and I am getting the
same problem. Its taken a while and in fact it was only when pointed at
this bug request that the answer was apparent. My problem was it wasnt
constant, it was intimittent, so, I assumed my server was crud. I
actually had rulled out a PHP bug coz it works fine on my portable
(W2K pro) every time, but under server .. no.. Although my server does
also farm hits to the company intranet so is generally under a lot more
stress than my portable.
I will continue further tests to see if doing includes takes the
problem away, as certainly, it seems the javascript of window.location=
seems to be fine. I assume PHP is being too fast for itself?
[2002-01-12 06:58:59] [EMAIL PROTECTED]
Can you try this with 4.1.1? There been alot of fixes for IIS in the
recent versions.
[2001-03-19 22:41:31] [EMAIL PROTECTED]
Under the category of "You Can Never Have Too Much Information On A
Bug", here is my experience with the "CGI App Misbehaved" bug (related
bug reports: #8571 and #8744).
Bug report summary:
A PHP script that sends a 'Location' header directive and makes a
database connection causes IIS to intermittently return a 'Gateway
Error 502' when the client browser asks for the page specified in the
redirect. The address bar will correctly show the page that should
have loaded when the error is displayed, and pressing F5 (refresh) will
correctly load the page. Note that the error is (seemingly) completely
random, sometimes you get it, other times the script works correctly.
The error message text is:
-- Begin --
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
-- End --
This error depends on:
1) Using PHP in CGI mode (i.e. using php.exe, the ISAPI dll does not
seem to produce this error, although it has it's own problems).
2) A PHP script that connects to a database (tested both mssql_connect
and odbc_connect) *and* sends a 'Location:' header. If the script
redirects to something other than a .php file (i.e. .html or .pdf) or
does not connect to the database, the error will not occur.
3) A successful db connection. If the db connect call fails (due to
bad password, etc.), the redirect always works.
This error does *not* depend on:
1) A fully qualified 'Location' header. The following also fails:
header('Location: http://10.0.0.30/test/done.php');
2) The relative order of the header() and xxx_connect() calls in
'doit.php'. I wouldn't expect the order to affect the result, but I
checked it anyway.
Interesting note: While upgrading the server to SP1 to see if it had
any affect on this bug, I continued to test while it was in the process
of performing the upgrade. It was very difficult (I gave up) trying to
get the error. The CPU was at 100% due to the upgrade which
(obviously) caused the web server performance to suffer. Combined with
the fact that it occurs randomly anyway, this suggests that it may have
something to do with the timings between the request for doit.php,
execution of doit.php, and the request for done.php.
Hardware/Software:
Web server:
Win2000 Server (with and without SP1)
IIS 5.0
PHP 4.0.4pl1 (CGI mode)
Database server:
WinNT 4.0 SP6
MS-SQL 7.0
Client:
Win2000 Professional SP1
IE 5.5 SP1
Test scripts
start.php
Test
Do test
doit.php
done.php
Test
Test complete
Reset test
Here are actual HTTP headers recorded using a packet sniffer:
Scenario #1 - CGI E
Bug #16313: Error in CGI Application
From: [EMAIL PROTECTED] Operating system: Windows 2000 Professional PHP version: 4.1.2 PHP Bug Type: IIS related Bug description: Error in CGI Application This may be related to #9852 though I can reproduce this problem with a very simple PHP page. Left the BOUNCE page (attach to bug #9852) running in two browser windows making requests against a local server. The first browser stopped with a CGI error at 37970 requests. The second browser stopped at 59780 requests. The option "Show friendly error messages" was on in IE at the time. The error text returned: --- Error in CGI Application CGI ErrorThe specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: --- The error seems to re-occur every 10-40 thousand requests. -- Edit bug report at http://bugs.php.net/?id=16313&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16313&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16313&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16313&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16313&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16313&r=support Expected behavior: http://bugs.php.net/fix.php?id=16313&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16313&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16313&r=submittedtwice
Bug #16313 Updated: Error in CGI Application
ID: 16313 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Windows 2000 Professional PHP Version: 4.1.2 New Comment: If someone knows a good way to gather more information, let me know. Previous Comments: [2002-03-27 13:31:08] [EMAIL PROTECTED] This may be related to #9852 though I can reproduce this problem with a very simple PHP page. Left the BOUNCE page (attach to bug #9852) running in two browser windows making requests against a local server. The first browser stopped with a CGI error at 37970 requests. The second browser stopped at 59780 requests. The option "Show friendly error messages" was on in IE at the time. The error text returned: --- Error in CGI Application CGI ErrorThe specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: --- The error seems to re-occur every 10-40 thousand requests. -- Edit this bug report at http://bugs.php.net/?id=16313&edit=1
Bug #16323: php_OLECHAR_to_char() error in IIS
From: [EMAIL PROTECTED] Operating system: Windows 2000 Professional PHP version: 4.1.2 PHP Bug Type: COM related Bug description: php_OLECHAR_to_char() error in IIS The following example PHP script works fine when run from the command line, but fails when run via IIS. RegRead($key); echo " Got $key = $v\n"; $v = $v + 1; $wsh->RegWrite($key,$v); echo " Set $key to $v\n"; ?> The error returned references the line containing RegWrite. Got HKLM\foo = 2 Warning: Error in php_OLECHAR_to_char() in c:\asg\webmanager\test\x4.php on line 7 Warning: Error in php_OLECHAR_to_char() in c:\asg\webmanager\test\x4.php on line 7 Warning: Invoke() failed: Exception occurred. Source: Description: in c:\asg\webmanager\test\x4.php on line 7 Set HKLM\foo to 3 -- Edit bug report at http://bugs.php.net/?id=16323&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16323&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16323&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16323&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16323&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16323&r=support Expected behavior: http://bugs.php.net/fix.php?id=16323&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16323&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16323&r=submittedtwice
