Веб-сервер Linux PHP ужасно медленный при доступе из любого браузера Windows
У меня есть сервер Linux (Ubuntu 10.04) с apache2 и PHP. Все работает нормально при доступе к странице из любого браузера с другого компьютера Linux или Mac. Но когда я пытаюсь получить доступ к странице с любого сочетания компьютера с Windows и браузера, у меня возникает 30-секундная задержка, прежде чем страница возвращается. Доступ к простому старому HTML-файлу из браузера Windows запускает быстрое разделение. Так что вроде бы просто PHP. MySQL установлен, но простая тестовая страница, не использующая MySQL, по-прежнему работает медленно.
Я не думаю, что это DNS, потому что если я жестко закодирую IP-адрес в URL-адресе, ничего не изменится. Кажется, в файлах журнала нет ничего, что я мог бы сказать.
Что могло вызвать такое поведение на клиентах Windows?
Обновление: некоторые советы по отладке "3-й базы";
Достаточно жестокий способ получить некоторую отладку - ограничить работающий процесс apache, и это на самом деле проще, потому что процессы будут зависать на некоторое время.
Эта команда ниже будет работать, как указано, только если ваш apache находится в режиме предварительной вилки, но я бы предположил, что в рабочем режиме она будет работать примерно так же. (но вам придется потратить некоторое время на получение ps и grep чтобы найти идентификаторы потоков ...) в любом случае я думаю, что php требует предварительной вилки ...
Сначала убедитесь, что сервер находится в режиме предварительной вилки ...
root@server-72839:/home/ubuntu# apachectl -V | grep MPM
Server MPM: Prefork <----------- prefork mode works with php
-D APACHE_MPM_DIR="server/mpm/prefork"
установить strace
root@server-72839:/home/ubuntu# apt-get install strace
сделайте некоторый запрос к серверу, а затем выполните следующую команду, чтобы отследить системные вызовы, сделанные зависшим процессом;
root@server-72839:~# netstat -antp | grep "ESTABLISHED" | grep 80 | while read _ _ _ _ client _ proc; do strace -f -p ${proc#/*} & done
root@server-72839:~# Process 21570 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
chdir("/") = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb16b0000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb16ae000
позвольте запросу страницы пройти через медленное окно windoze, а затем вставьте весь вывод обратно в пастебин и разместите ссылку в комментарии.
Если вам это не нравится, включите отладку php и httpd Loglevel, чтобы отладить и вставить все это в pastebin и предоставить ссылку ....
Изменить: (хорошо, возможно, не определенно), возможно, проблема с обратным DNS на сервере apache. попробуйте следующее ....
убедитесь, что вы установили HostnameLookups Off на вашем сервере Apache.
http://httpd.apache.org/docs/2.2/mod/core.html#hostnamelookups
Также убедитесь, что ваш resolv.conf указывает рабочие серверы имен;
[root@workstation001 /root]# cat /etc/resolv.conf
....
nameserver 192.168.1.254 <---- this must work. test it with dig
протестировать сервер имен с помощью dig;
[root@workstation001 /root]# dig @192.168.1.254 www.google.co.uk +short
www-cctld.l.google.com.
173.194.67.94
заставить работать сервер имен, изменив его на 8.8.8.8 (общедоступный DNS-сервер Google)
/etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.8.4
Начните с проверки файлов журналов php.log и apache на предмет медленных подключений, проблема, скорее всего, прямо там в журналах.
Однако, если вы уверены, что это не проблема DNS (которую вы можете проверить с помощью инструмента командной строки nslookup) и на стороне сервера нет ничего очевидного, тогда я бы использовал встроенные инструменты разработчика google chrome, чтобы увидеть временную шкалу страницы. нагрузка.
Это скажет вам, какой элемент на странице занимает так много времени, и была ли задержка во время соединения или во время загрузки ресурсов и т. Д.
Вы можете перейти к таким инструментам, как wget, curl в cygwin или простой telnet, для дальнейшего изучения со стороны клиента.
