Как найти узкое место в производительности скрипта?

Question

[Mike Evstropov]

Здравствуйте.

Есть парсер, который кушает html с чужого сервера (в пределах РФ) и возвращает некоторые данные в формате json. Пока нагрузка была 40к запросов в сутки, все было здорово. Но в данный момент количество запросов значительно увеличилось. И с этого момента, время на выполнение скрипта стало доходить до 10-20 секунд!

Операции:

1. require библиотеки QueryPHP
   
2. запрос на другой сервер с получением 100кб кода html
   
3. инициализация класса QueryPHP
   
4. извлечение содержимого 8 элементов DOM из ответа
   
5. запрос в локальную базу данных PHP::PDO методом SELECT
   
6. вывод объекта json.
   

Пожалуйста помогите понять, что нужно сделать? Есть ли смысл менять тариф у хостера? Хостер говорит, что производительность в первую очередь зависит от скрипта, а не от железа, и более дорогой тариф вряд ли решит мою проблему.

Конфигурация: VPS OpenVZ / Xeon 400MHz / 512mb / RAID HDD

Статистика CloudFlare (сейчас прокси отключен)

Статистика от хостера за 1 час.

Answer 1

[Сергей Протько]

https://blackfire.io/ - для профилирования кода.

В целом первым делом надо думать над кешированием результатов парсинга, если это возможно, а не лазать каждый раз на удаленный сервер и т.д. Подозреваю что у вас именно так, и это и сжирает 99% времени.

Comments

[Mike Evstropov]

Html каждый раз разный к сожалению...

[Barmunk]

Можно еще попробовать разделить процесс.
Сначала по крону скачиваем нужные страницы все разом, к примеру ночью, кладем их в отдельную папку, а потом уже спокойно работает с локальными копиями в любое удобное время.

Answer 2

[Алексей Уколов]

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

Может быть, стоит заменить QueryPHP на регулярные выражения или стандартный DOMDocument. Но это несёт свои ограничения, как правило, парсить html регулярками - плохая идея.

Comments

[Mike Evstropov]

То есть, если бы там была одна строчка кода, к примеру echo 'hello'; , при 42к запросах в час, сервер бы отвечал так же быстро как и без нагрузки?

[Алексей Уколов]

Конечно, не совсем так же быстро, но всё-таки прежде, чем менять тариф нужно профилировать скрипт и смотреть в чём конкретно дело.

[Mike Evstropov]

Спасибо за ответы... Так и не могу подружиться с php....

Answer 3

[lubezniy]

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

1. По возможности кэшировать select из Вашей базы в memcache или куда-то ещё, чтобы каждый раз не подключаться к БД (есть не очень большая, но вероятность, что поможет);
2. Перенести скачивание и парсинг страниц стороннего сайта (а, может, и select к базе заодно) на другие виртуальные машины (может, даже в другом дата-центре, чтобы не забивать канал), балансируя нагрузку между ними (например, по результату выполнения функции mt_rand обращаться то к одной машине, то к другой, то к третьей - количество подобрать экспериментально).

Важно учесть то, что владельцам стороннего сайта большой трафик с нескольких ip может и не понравиться.