| Author |
|
ng4win
Joined: 25 May 2014
Posts: 78
|
 Posted: Sun 28 Dec '14 23:37 Post subject: |
 |
|
nginx, php (nts) 5.5.20 same thing on Length (<?php phpinfo();?>):
Complete requests: 500
Failed requests: 61
(Connect: 0, Receive: 0, Length: 61, Exceptions: 0)
"GET /phptest/test1.php HTTP/1.0" 200 88529 "-" "ApacheBench/2.3" "-" -
"GET /phptest/test1.php HTTP/1.0" 200 88528 "-" "ApacheBench/2.3" "-" -
1 byte of. |
|
| Back to top |
|
Radek Hulán
Joined: 17 Mar 2007
Posts: 10
Location: Prague / CZ
|
| Posted: Mon 29 Dec '14 22:36 Post subject: |
|
|
Thank you for this build. Very useful to have SQLSRV, WinCache, and many others available under PHP 5.6 x64  |
|
| Back to top |
|
C0nw0nk
Joined: 07 Oct 2013
Posts: 241
Location: United Kingdom, London
|
| Posted: Mon 29 Dec '14 23:09 Post subject: |
|
|
So how will you guys go about fixing that bug ?, I have not noticed it i do notice memory leaks within PHP. I wounder if it is both 32 and 64bit PHP that have this issue or just one.
I set "PHP_FCGI_MAX_REQUESTS=1000" in a non threaded enviorment so every 1000 requests served PHP restarts.
And i use nginx what load balances the PHP requests between multiple running PHP-cgi.exe servers so the requests are not hitting a single php.exe all at once they are proborly being passed across them all what is why i see no timeouts or failed requests.
| Code: | upstream web {
server 127.0.0.1:9041 weight=1 fail_timeout=4;
server 127.0.0.1:9042 weight=1 fail_timeout=4;
server 127.0.0.1:9043 weight=1 fail_timeout=4;
server 127.0.0.1:9044 weight=1 fail_timeout=4;
server 127.0.0.1:9045 weight=1 fail_timeout=4;
server 127.0.0.1:9046 weight=1 fail_timeout=4;
server 127.0.0.1:9047 weight=1 fail_timeout=4;
server 127.0.0.1:9048 weight=1 fail_timeout=4;
server 127.0.0.1:9049 weight=1 fail_timeout=4;
server 127.0.0.1:9050 weight=1 fail_timeout=4;
} |
I also use ng4win's Nginx and PHP script and builds supplied upon his/her site. http://nginx-win.ecsds.eu/ |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1265
Location: Amsterdam, NL, EU
|
| Posted: Tue 30 Dec '14 19:24 Post subject: |
|
|
| ng4win wrote: | "GET /phptest/test1.php HTTP/1.0" 200 88529 "-" "ApacheBench/2.3" "-" -
"GET /phptest/test1.php HTTP/1.0" 200 88528 "-" "ApacheBench/2.3" "-" -
1 byte off. |
Silly, apparently ApacheBench stumbles over 1 one byte difference in file size:
| Quote: | ***** tmp50725.txt
_SERVER["PHP_SELF"] /phpi.php
_SERVER["REQUEST_TIME_FLOAT"] 1419959739.487
_SERVER["REQUEST_TIME"] 1419959739
__________________________________________________________________
***** TMP50726.TXT
_SERVER["PHP_SELF"] /phpi.php
_SERVER["REQUEST_TIME_FLOAT"] 1419959709.5422
_SERVER["REQUEST_TIME"] 1419959709
__________________________________________________________________
***** |
PHP 5.3 does not report the REQUEST_TIME_FLOAT and generates no 'errors'. |
|
| Back to top |
|
ng4win
Joined: 25 May 2014
Posts: 78
|
| Posted: Tue 30 Dec '14 21:32 Post subject: |
|
|
| Jan-E wrote: | | PHP 5.3 does not report the REQUEST_TIME_FLOAT and generates no 'errors'. |
Technically it isn't an error then, which is good news.
We just need to find a way to strip such dynamic data. |
|
| Back to top |
|
jimski
Joined: 18 Jan 2014
Posts: 196
Location: USSA
|
| Posted: Thu 01 Jan '15 13:50 Post subject: |
|
|
| Jan-E wrote: |
Silly, apparently ApacheBench stumbles over 1 one byte difference in file size |
I'm not sure if I understand this.
If this is just 1 byte difference then why only some requests are reported as "failed" and not all of them?
So out of 1000 requests only 10% are off by 1 byte in file size and the other 90% are OK? Why? |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1265
Location: Amsterdam, NL, EU
|
| Posted: Thu 01 Jan '15 15:04 Post subject: |
|
|
Because 1 out of 10 times the fourth digit after the decimal separator is a '0' and PHP reports a float as 1419959739.487 (not 1419959739.4870). Hence the 1 byte off. Sometimes the failure rate is around 10%, sometimes around 90% depending on what ApacheBench considers as the right output size.
phpinfo just is not a reliable function to test with ApacheBench. For instance when you have Opcache running the filesize grows with the numbers in cache and the hits. |
|
| Back to top |
|
jimski
Joined: 18 Jan 2014
Posts: 196
Location: USSA
|
| Posted: Thu 01 Jan '15 21:52 Post subject: |
|
|
| Jan-E wrote: | | ...depending on what ApacheBench considers as the right output size. |
I assume that Apache Bench was written based on a previously predictable behavior of PHP, and as such it must have some method of measuring the anticipated output size as this is one of the methods of judging if the request was completed successfully. Who in your opinion should address this problem, the Apache team or PHP team.?
AB is a widely used benchmarking tool so I wonder what other cases could produce skewed results when using AB with newer versions of PHP.
| Jan-E wrote: | | phpinfo just is not a reliable function to test with ApacheBench. |
Until this problem surfaced phpinfo() was a very handy tool for quick load testing because it generates a template, a bunch of text, pokes into php guts and puts a fair load on the webserver and cpu for a one liner function. |
|
| Back to top |
|
laurin1
Joined: 26 Oct 2014
Posts: 74
Location: Flower Mound, TX
|
| Posted: Mon 19 Jan '15 14:52 Post subject: Re: PHP & Image Magick |
|
|
| Jan-E wrote: | Hi Keith,
I finally found the time to upgrade this extension. Could you try if it works with the latest Image Magick release? |
I'm not getting notifications of updates to this forum, so I just now noticed that you had responded to me, Jan.
I'll test this as soon as I can. |
|
| Back to top |
|
laurin1
Joined: 26 Oct 2014
Posts: 74
Location: Flower Mound, TX
|
| Posted: Mon 19 Jan '15 15:12 Post subject: Re: PHP & Image Magick |
|
|
| I'm using your complete build (https://phpdev.toolsforresearch.com/php-5.6.4-nts-Win32-VC11-x86.zip), but the LDAP extension won't load. |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1265
Location: Amsterdam, NL, EU
|
| Posted: Mon 19 Jan '15 15:42 Post subject: |
|
|
The LDAP extension needs these DLL's:
Module: php_ldap.dll
===========================
libsasl.dll
msvcr110.dll
ssleay32.dll
libeay32.dll
msvcr110.dll is the VC11 redistributable, the other three are in the zip. |
|
| Back to top |
|
laurin1
Joined: 26 Oct 2014
Posts: 74
Location: Flower Mound, TX
|
| Posted: Mon 19 Jan '15 17:43 Post subject: |
|
|
| Jan-E wrote: | The LDAP extension needs these DLL's:
Module: php_ldap.dll
===========================
libsasl.dll
msvcr110.dll
ssleay32.dll
libeay32.dll
msvcr110.dll is the VC11 redistributable, the other three are in the zip. |
Ok, I mis-typed. I updated my current PHP installation with your version (copied all of the files from the zip into my c:\PHP directory, overwriting), which has LDAP already working. I verified that I have all 4 of those files (msvcr110.dll is in the path). |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1265
Location: Amsterdam, NL, EU
|
| Posted: Mon 19 Jan '15 17:46 Post subject: |
|
|
| Is php_ldap.dll loading or not? And how about php_imagick.dll? |
|
| Back to top |
|
laurin1
Joined: 26 Oct 2014
Posts: 74
Location: Flower Mound, TX
|
| Posted: Mon 19 Jan '15 19:40 Post subject: |
|
|
| Jan-E wrote: | | Is php_ldap.dll loading or not? |
No
| Jan-E wrote: | | And how about php_imagick.dll? |
No, however, I haven't upgraded my Image Magick installation (stopped with the LDAP support failed). |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1265
Location: Amsterdam, NL, EU
|
| Posted: Mon 19 Jan '15 20:54 Post subject: |
|
|
Do you get an error message when you run 'php -m' from the command line? That is in many cases the quickest way to determine what goes wrong.
If no error message: does it show ldap in the list? This is for instance the output of 'php -m' for my 5.6.5RC1:
http://apaste.info/Wdi
Mode note: moved console output to apaste |
|
| Back to top |
|
laurin1
Joined: 26 Oct 2014
Posts: 74
Location: Flower Mound, TX
|
| Posted: Mon 19 Jan '15 22:50 Post subject: |
|
|
Ok, so I upgraded my Image Magick to ImageMagick-6.9.0-4-Q16-x86-dll and now php_imagick.dll loads (haven't tested it's functionality, but at least it loads with errors).
Running php -m now I get no errors, but ldap does not load:
http://apaste.info/EI6
Mod note: moved console output to apaste |
|
| Back to top |
|
laurin1
Joined: 26 Oct 2014
Posts: 74
Location: Flower Mound, TX
|
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1265
Location: Amsterdam, NL, EU
|
| Posted: Tue 20 Jan '15 3:16 Post subject: |
|
|
| Try php.net's 5.6.2 php_ldap.dll in stead of mine. Then update to php.net's 5.6.4 or 5.6.5RC1 to see if it is a problem with my builds or with (the sources of) php_ldap.dll. |
|
| Back to top |
|
laurin1
Joined: 26 Oct 2014
Posts: 74
Location: Flower Mound, TX
|
| Posted: Tue 20 Jan '15 14:29 Post subject: |
|
|
| Jan-E wrote: | | Try php.net's 5.6.2 php_ldap.dll in stead of mine. Then update to php.net's 5.6.4 or 5.6.5RC1 to see if it is a problem with my builds or with (the sources of) php_ldap.dll. |
Ok, this is very strange. It's not your php_ldap.dll file at all. It's the libeay32.dll file in your zip. I replaced the php_ldap.dll file from the 5.6.4 on php.net and it still didn't work, so on a whim, I replaced libsasl.dll, ssleay32.dll, and libeay32.dll and it worked. So, I reverted 3 of the 4 files (php_ldap.dll, libsasl.dll and ssleay32.dll) and it still worked, as long as I have the libeay32.dll file from 5.6.4 from php.net, instead of yours.
The libeay32.dll file from php.net is version 1.0.1.9, but the one from your zip is 1.0.1.10. |
|
| Back to top |
|
Jan-E
Joined: 09 Mar 2012
Posts: 1265
Location: Amsterdam, NL, EU
|
| Posted: Tue 20 Jan '15 14:54 Post subject: |
|
|
| I already updated to OpenSSL 1.0.1j and compiled OpenSSL with FIPS support. One of these 2 factors must have caused the problems. |
|
| Back to top |
|
