PHP берет дополнительную 1 секунду, чтобы получить каждый набор результатов из Sphinx (!!) - PullRequest
1 голос
/ 08 мая 2011

У меня странная проблема .... Все это работало нормально прошлой ночью, когда я закодировал эту чертову штуку, но я переустановил WAMP на своем локальном сервере разработчика, и теперь у меня возникают проблемы.

Я пытаюсь получить результаты из Sphinx через API PHP. Я просто выполняю самые простые запросы в качестве теста ...

    $searchtest = Sphinx::factory();
    $results = $searchtest->Query('');

И $ results содержит результаты сфинкса, как и ожидалось

...
[total] => 1000
[total_found] => 30312
[time] => 0.004

Однако, когда я профилирую этот небольшой фрагмент кода, он говорит мне, что PHP занимает дополнительную секунду для обработки запроса!

test (1) - 1.066703 s

Проблема усугубляется в моем производственном коде, который выполняет несколько запросов Sphinx, вчера ... все работало нормально, и каждый поиск занимал 0,004 секунды (или такое же небольшое количество времени), но сегодня запуск страницы занимает несколько секунд все поисковые запросы! (это на изолированном dev-сервере, поэтому нет проблем с трафиком)

results (1) - 1.046128 s
sidebar_data (1) - 10.388812 s
featured (1) - 1.034211 s

Каждый отдельный запрос к демону Сфинкса занимает дополнительную секунду, чтобы вернуться! (sidebar_data попадает на поисковый сервер 10 раз)

Что здесь происходит? Я потратил кучу времени, пытаясь понять это, и я в тупике. Я даже переустанавливал Sphinx с нуля. Так как сам sphinx сообщает [time] => 0.004 быстрое время доступа, проблема связана с PHP?

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

Редактировать: Я посмотрел на вывод из searchd --console, конечно, он подтверждает, что поисковые запросы выполняются довольно быстро, но если вы посмотрите на время, они выполняются прибл. один в секунду ... PHP вызывает некоторую задержку как-то (??)

[Sun May  8 09:57:29.923 2011] 0.012 sec [all/1/ext 15039 (0,25)] [main]
[Sun May  8 09:57:30.996 2011] 0.020 sec [all/1/rel 30 (0,20) @city] [main]
[Sun May  8 09:57:32.034 2011] 0.016 sec [all/1/rel 50 (0,20) @make] [main]
[Sun May  8 09:57:33.061 2011] 0.015 sec [all/1/rel 15 (0,20) @style] [main]
[Sun May  8 09:57:34.099 2011] 0.017 sec [all/1/rel 25 (0,20) @colour] [main]
[Sun May  8 09:57:35.122 2011] 0.009 sec [all/1/rel 1 (0,20) @field] [main]
[Sun May  8 09:57:36.145 2011] 0.011 sec [all/2/rel 1 (0,20) @field] [main]
[Sun May  8 09:57:37.174 2011] 0.010 sec [all/2/rel 1 (0,20) @field] [main]
[Sun May  8 09:57:38.187 2011] 0.003 sec [all/2/rel 431 (0,20)] [main]
[Sun May  8 09:57:39.240 2011] 0.005 sec [all/2/rel 12627 (0,20)] [main]
[Sun May  8 09:57:40.292 2011] 0.005 sec [all/2/rel 13021 (0,20)] [main]
[Sun May  8 09:57:41.343 2011] 0.001 sec [all/3/rel 200 (0,20)] [main]

1 Ответ

0 голосов
/ 08 мая 2011

На первый взгляд, я бы предположил, что может возникнуть какая-то проблема с разрешением DNS, но похоже, что вы запускаете searchd на том же хосте, что и PHP

Вместо того, чтобы возиться, пытаясь угадать, чтовызывает это, я бы порекомендовал профилирование кода PHP, работающего на машине.Я бы установил xdebug, включил профилирование и затем проанализировал вывод в webcachegrind.Он должен быть в состоянии указать вам, какие функции работают медленно и дать вам лучшее представление о том, что не так.

...