I see no one's replied yet, so I'll throw my hat in. Not sure how much help I can be -- I'm not a PHP developer, but I have debugged PHP/FastCGI with LightTPD and Nginx before, so anything's probably better than nothing...
The weird part about this is that you tried Apache, Nginx and LightTPD and you got the same result with each. This plus the fact that strace shows PHP is sending all the requested information to the server is really weird.
Have you tried communicating with the FCGI process using a unix socket AND an internet socket? Can you eliminate the web server from the equation, and write a script that uses the FastCGI protocol to talk to the FCGI process directly?
When I hit a wall, I usually try to reduce things to the smallest number of moving parts and then try again. Close the feedback loop as tightly as possible. Eliminate the web server if you can. Try to compile PHP in FastCGI mode with no external library dependencies. Heck, even see if you can execute the script from the command-line with the ENV variables set to expected values and try duplicate the problem.
Scoundrel
· 2 years ago
2Dan Kubb: Thanks for advices. I've tried unix and tcp sockets without luck :-(
Your idea of writing some wrapper to be sure than php sends correct data is really great - will try to implement it tomorrow.
dkubb
· 2 years ago
@Soundrel: I wasn't even suggesting writing a wrapper, I was more suggesting writing a "bot" that communicates with the script via the FastCGI protocol directly. You could run it directly against the app and raise any exceptions if the data comes out other than expected.
A wrapper seems like a more difficult problem to solve. A bot would simply need to simulate a FastCGI request, and log the response.
DM
· 2 years ago
Итак, вот что вышло у меня: файл размером в 1М, забит нулями, PHP работает как модуль апача. В процессе была загрузка 100% (cpu: Pentium(R) 4 CPU 1400MHz, mem: 516680 kB) Тестил через ab -c 100 http://dm.test/test.php Если скажете как скачать его 100 раз иначе - попробую иначе.
Server Software: Apache/2.2.3 Server Hostname: dm.test Server Port: 80
Concurrency Level: 1 Time taken for tests: 474.532609 seconds Complete requests: 100 Failed requests: 0 Write errors: 0 Total transferred: 104877000 bytes HTML transferred: 104857600 bytes Requests per second: 0.21 [#/sec] (mean) Time per request: 4745.326 [ms] (mean) Time per request: 4745.326 [ms] (mean, across all concurrent requests) Transfer rate: 215.83 [Kbytes/sec] received
_Andrey_
· 2 years ago
Память тестировали?
id
· 2 years ago
to _Andrey_: нет, не тестировали, но такое проявляется редко на ещё одном сервере и было ещё на одном. Т.е. 3 разных сервера, на которых один и тот же баг - имо вариант проблем с памятью да и с железом в целом исключают.
2Aleks: Thanks - I'll take a look at this tcp scaling problem.
About chatting with me - you can reach me via any IM (contacts are on resume page).
I've deleted strace/tcpdump/etc but I think I can get new dumps ;-)
Camel
· 2 years ago
Were your test scripts local or remote? I've had similar issues, check your ethernet MTU, it couldn't hurt to try lowering it to 1450.
Scoundrel
· 2 years ago
Hmmm... I've got major update - looks like there is no problem when web server is not on port 80. Just tested it with the same config but on port 8080 - everything works fine on full speeds without any problems (at lest on my 100-files-download test). Really strange :-(
Scoundrel
· 2 years ago
2Camel: Test script was local, but errors was on local and remote clients - distance from the server does not matter.
Benjamin
· 2 years ago
Can you share your nginx configuration file?
Aleks
· 2 years ago
Any news?!
ugenk
· 2 years ago
Возможно, проблема с sendfile в ядре?
Dimon
· 2 years ago
We have rebuilt the kernel - versions from 2.6.16.51 to 2.6.19.7 - nothing helped. Trying different NIC cards also didn't help.
Anxious
· 2 years ago
...so? :S
Siava
· 2 years ago
Была похожая проблема после обновления ядра до 2.6.21.*, всё стало на свои места после возвращения на ветку 2.6.16.*
All Comments
The weird part about this is that you tried Apache, Nginx and LightTPD and you got the same result with each. This plus the fact that strace shows PHP is sending all the requested information to the server is really weird.
Have you tried communicating with the FCGI process using a unix socket AND an internet socket? Can you eliminate the web server from the equation, and write a script that uses the FastCGI protocol to talk to the FCGI process directly?
When I hit a wall, I usually try to reduce things to the smallest number of moving parts and then try again. Close the feedback loop as tightly as possible. Eliminate the web server if you can. Try to compile PHP in FastCGI mode with no external library dependencies. Heck, even see if you can execute the script from the command-line with the ENV variables set to expected values and try duplicate the problem.
Your idea of writing some wrapper to be sure than php sends correct data is really great - will try to implement it tomorrow.
A wrapper seems like a more difficult problem to solve. A bot would simply need to simulate a FastCGI request, and log the response.
файл размером в 1М, забит нулями, PHP работает как модуль апача. В процессе была загрузка 100% (cpu: Pentium(R) 4 CPU 1400MHz, mem: 516680 kB)
Тестил через ab -c 100 http://dm.test/test.php
Если скажете как скачать его 100 раз иначе - попробую иначе.
Server Software: Apache/2.2.3
Server Hostname: dm.test
Server Port: 80
Document Path: /test.php
Document Length: 1048576 bytes
Concurrency Level: 1
Time taken for tests: 474.532609 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 104877000 bytes
HTML transferred: 104857600 bytes
Requests per second: 0.21 [#/sec] (mean)
Time per request: 4745.326 [ms] (mean)
Time per request: 4745.326 [ms] (mean, across all concurrent requests)
Transfer rate: 215.83 [Kbytes/sec] received
нет, не тестировали, но такое проявляется редко на ещё одном сервере и было ещё на одном. Т.е. 3 разных сервера, на которых один и тот же баг - имо вариант проблем с памятью да и с железом в целом исключают.
could this be the reason:
http://www.debian.org/releases/stable/i386/rele...
Hth
Aleks
About chatting with me - you can reach me via any IM (contacts are on resume page).
I've deleted strace/tcpdump/etc but I think I can get new dumps ;-)