Значение Long Time to First Byte для пустого php файла

У меня был такой question несколько месяцев назад. Теперь, чтобы изолировать проблему, я попробовал новый подход. Я поместил пустой файл на свой сервер.

Имя файла - "foobar.php" . Его содержимое выглядит следующим образом:

<?php
echo "hello world";

Но когда я пытаюсь войти в example.com/foobar.php, я получаю

DNS 203 mseconds
Подключить 3,33 секунды
Отправить 0 miliseconds
Время до первого байта 17,35 секунд
Получите 1 миллисекунду Общее время загрузки 20,88 секунд

Затем я поместил еще один файл с именем foobar.txt. Его содержимое выглядит следующим образом:

hello world<br/>

Время загрузки foobar.txt составляет приблизительно 0,2 секунды.

Этот веб-сайт находится в общем хостинге, поэтому я не могу получить доступ к корневому Linux. Я пытаюсь выяснить, что делает мой сайт медленным.

Когда я получаю эти результаты, у меня на моем сайте 60 посетителей. И они отправляют запросы AJAX, когда они активны. Когда они активны, они отправляют запрос AJAX почти каждые 3 секунды.
Обычно мой сайт имеет 5-20 запросов в секунду.
Мой хостинг-провайдер говорит, что не происходит перегрузки процессора, он очень низкий.
Я спросил хостинговую компанию для ограничений Apache. Я получаю эти значения для всего общего сервера:

MaxClients 300
MaxRequestsPerChild 4000
ThreadsPerChild 25

example.com/mybigpage.php и example.com/foobar.php открываются почти в одно и то же время.
Если на странице есть txt, jpeg или другие расширения, они открываются мгновенно. Если расширение php оно открывается очень медленно.
CakePHP хранит файлы сеанса внутри папки "/httpdocs/app/tmp/sessions". Файлы сеанса удаляются через два часа после создания. Теперь в этой папке находится 3653 файла. Самый старый файл создается 2,5 часа назад.
В моей конфигурации обработчик PHP - это модуль Apache mod_php

Новое редактирование: Я разговаривал с моей хостинговой компанией. И сказал им, что "foobar.php" открывается почти через 20 секунд. Хотя у этого файла нет кода вообще. Они сказали мне, что они помещают "foobar.php" на другие веб-сайты, которые используют тот же сервер. Я также попробовал "othersite.com/foobar.php". Она открылась мгновенно. Но "mysite.com/foobar.php" открылся почти через 15 секунд. Что бы это сделало? Мы используем ту же конфигурацию PHP с другими сайтами, но мгновенно открываем их. Может это из-за моих правил .htaccess? Или что-то еще?

Новое редактирование2: Мой провайдер сказал мне, что на сервере нет файла "apd.so". Поэтому кажется, что я не могу использовать APD.

Что я должен искать, чтобы найти узкое место?
Что ограничивало бы мой сайт?

Дополнительные данные: из phpinfo я получаю следующее:

'./configure' '--prefix =/usr/local/lsws/lsphp5' '--build = x86_64-redhat-linux-gnu' '--host = x86_64-redhat-linux-gnu' '--target = x86_64-redhat-linux-gnu' '--sysconfdir =/etc' '--datadir =/usr/share' '--includedir =/usr/include' '--libdir =/usr/lib64' '--libexecdir =/usr/libexec' '--localstatedir =/var' '--sharedstatedir =/usr/com' '--mandir =/usr/share/man' '--infodir =/usr/share/info' '--cache-file =../config.cache' '--with-libdir = lib64' '--with-конфиг файл-путь =/и т.д.' '--with-config-file-scan-dir =/etc/php.dd' '--disable-debug' '--with-pic' '--disable-rpath' '- без груши' '--with-bz2' '--with-curl' '--with-exec-dir =/usr/bin' '--with-freetype-dir =/usr' '--with-png-dir =/usr' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir =/usr' '--with-openssl' '--with-libexpat-dir =/usr/lib64' '--with-pcre-regex =/usr' '--with-zlib' '--with-layout = GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg' '--enable-wddx' '--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC = shared,/usr' '--enable-shmop' '--enable-calendar' '--with-libxml-dir =/usr' '--with-mysql' '--with-mysqli' '--with-gd' '--enable-dom' '--disable-dba' '--without-unixODBC' '--enable-xmlreader' '--enable-xmlwriter' '--with-mcrypt' '--enable-mbstring' '--with-litespeed' '--enable-soap' '--with-xsl' '--with-pdo-mysql' '--with-pdo-sqlite' '--enable-sqlite-utf8' '--with-pspell' '--with-sqlite = shared' '--with-xmlrpc' '--with-mhash' '--enable-pdo' '--with-imap' '--with-imap-ssl' '--without-suhosin' '--with-tidy' '--enable-zip' '--enable-inline-optimization' '--enable-gd-native-ttf' '--enable-bcmath'

Ответ 1

Кажется очевидным, что это проблема PHP, поскольку Apache не имеет проблем с обслуживанием статических файлов. Вы пытались установить APD из PECL?

Использование профилировщика PHP, такого как APD, покажет вам, является ли узкое место на PHP, и если да, то где это. Например, это медлительность в рамках, которую вы используете? Или, возможно, просто мошенничество?

Перефразируя от официального manual:

С APD вы просто добавляете инструкцию в точке входа:

<?php
apd_set_pprof_trace();
?>

APD сбрасывает данные профилирования в файл * apd.dumpdir/pprof_pid.ext *.

Затем pprofp будет использовать ваши файлы дампа и рассказать вам, какие методы пережевывают время ответа:

bash-2.05b$ pprofp -R /tmp/pprof.22141.0

Trace for /home/dan/testapd.php
Total Elapsed Time = 0.00
Total System Time  = 0.00
Total User Time    = 0.00


Real         User        System             secs/    cumm
%Time (excl/cumm)  (excl/cumm)  (excl/cumm) Calls    call    s/call  Memory Usage Name
--------------------------------------------------------------------------------------
100.0 0.00 0.00  0.00 0.00  0.00 0.00     1  0.0000   0.0009            0 main
56.9 0.00 0.00  0.00 0.00  0.00 0.00     1  0.0005   0.0005            0 apd_set_pprof_trace
28.0 0.00 0.00  0.00 0.00  0.00 0.00    10  0.0000   0.0000            0 preg_replace
14.3 0.00 0.00  0.00 0.00  0.00 0.00    10  0.0000   0.0000            0 str_replace

Если ни одна из задержек, которые вы видите, не появляется в профиле, это может спровоцировать системную проблему с настройкой PHP (возможно, мошенничество или неправильно сконфигурированное расширение). Но я предполагаю, что это что-то в рамках.

Ответ 2

Вы пишете, что в момент возникновения этой проблемы у вас несколько клиентов, выполняющих AJAX-запросы каждые 3 секунды. Это делает вероятным, что все рабочие PHP-пользователи, доступные на вашем сервере, блокируются этими запросами AJAX. Ваш веб-сервер получает ваш запрос для /foobar.php, а затем должен ждать, пока работник PHP не сможет обработать ваш запрос.

Таким образом, среди возможных решений для вашей проблемы (без вашего уточнения, для чего нужен AJAX, мне нужно сохранить этот общий):

запрос AJAX переходит к статическому файлу
убедитесь, что PHP действительно закрывает соединение, когда запрос (AJAX) завершен, например, с помощью header("Connection: close"); (хотя этого может быть недостаточно, проверьте комментарии на Руководство по настройке подключения к Интернету)
уменьшить количество сделанных запросов AJAX (к числу, разработанному в сотрудничестве с вашим провайдером).

В общем, вам понадобится помощь вашего провайдера при решении этого вопроса. Вы не указали, какой метод использует ваш провайдер для обслуживания PHP, например, с помощью fpm есть параметр под названием process.max, который может ограничить способность ваших веб-серверов обрабатывать так много файлов PHP параллельно.

Ответ 3

Без сотрудничества с вашим провайдером у вас нет шансов узнать, что не так.

Я бы предположил, что это что-то вроде проблем с диском сессии.

Еще одна интересная мысль заключается в том, что ваш провайдер использует: http://www.litespeedtech.com/php-litespeed-sapi.html Никогда не слышал об этом.

Если ваш провайдер будет знать, что вам посоветовал mjk, вам следует просто сменить поставщика. Это швы, чтобы они не контролировали их.

Ответ 4

Если один и тот же пустой файл PHP мгновенно загружается при перемещении на другой сайт, это может быть не из-за каких-либо фреймворков или включенных файлов, поскольку в этот момент они не были загружены.

Это может быть проблема конфигурации на стороне php или Apache или может быть вызвана вашими правилами перезаписи. Я бы рекомендовал попробовать следующее:

1.) Если разрешены настройки PHP на каждом сайте, попросите компанию-хостинг переименовать ваш конкретный php.ini в другое имя, скопируйте поверх php.ini с другого сайта и перезапустите Apache, посмотрите, поможет ли это. У меня была аналогичная проблема в Windows, и это связано с проблемами доступа к файлам на php.ini, поэтому это может помочь.

2.) Временно переименуйте вас .htaccess и снова получите доступ к файлу php. Если время загрузки уменьшается, у вас будет ошибочное условие перезаписи или другая директива. Не могли бы вы также разместить содержимое вашего .htaccess?