DISQUS

DISQUS Hello! Homo-Adminus Blog is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Homo-Adminus Blog

Jump to original thread »
Author

SOS!

Started by Scoundrel · 9 months ago

Месяц назад этому блогу исполнился 1 год. Надеюсь, все мои чР... Continue reading »

20 comments

  • dkubb

    2 years ago

    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.
    reply
  • 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.
    reply
  • 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.
    reply
  • 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

    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
    reply
  • _Andrey_

    2 years ago

    Память тестировали?
    reply
  • id

    2 years ago

    to _Andrey_:
    нет, не тестировали, но такое проявляется редко на ещё одном сервере и было ещё на одном. Т.е. 3 разных сервера, на которых один и тот же баг - имо вариант проблем с памятью да и с железом в целом исключают.
    reply
  • Aleks

    2 years ago

    Hi,

    could this be the reason:

    http://www.debian.org/releases/stable/i386/rele...

    Hth

    Aleks
    reply
  • Aleks

    2 years ago

    Have you some tcpdumps from client and server?!
    reply
  • Aleks

    2 years ago

    Is there a irc or mail channel to talk.
    reply
  • Aleks

    2 years ago

    are the strace output available for download?
    reply
  • Scoundrel

    2 years ago

    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 ;-)
    reply
  • 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.
    reply
  • 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 :-(
    reply
  • Scoundrel

    2 years ago

    2Camel: Test script was local, but errors was on local and remote clients - distance from the server does not matter.
    reply
  • Benjamin

    2 years ago

    Can you share your nginx configuration file?
    reply
  • Aleks

    2 years ago

    Any news?!
    reply
  • ugenk

    2 years ago

    Возможно, проблема с sendfile в ядре?
    reply
  • 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.
    reply
  • Anxious

    2 years ago

    ...so? :S
    reply
  • Siava

    1 year ago

    Была похожая проблема после обновления ядра до 2.6.21.*, всё стало на свои места после возвращения на ветку 2.6.16.*
    reply

Add New Comment

Returning? Login