Производительность PHP на виртуальном хостинге - PullRequest
2 голосов
/ 10 мая 2009

У меня есть скрипт php, который вызывает другой скрипт с функцией php exec. Вызываемый скрипт выполняет пакетное задание, то есть обновляет статусы транзакций, уведомляет клиентов (помещает электронные письма в почтовую очередь, которая выполняется отдельно). Так что это займет 20-30 минут из-за очень большой таблицы (500000 строк), теперь я запускаю ее на своем компьютере с Windows, и php использует до 50% ЦП, mysql 20% ЦП. Это нормальная практика? Что делать, если я поместил этот скрипт в общий хостинг? У меня будут проблемы с этим? Это не нарушит правила общего хостинга? Пакетный процесс может быть запущен пользователем в любое время (обычно один раз в месяц или чаще).

Есть предложения по этому поводу?

Спасибо за чтение.

Ответы [ 6 ]

4 голосов
/ 10 мая 2009

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

Вы можете пойти на виртуальный хост, где они предоставят вам свободу делать все, что вам угодно, но вы, вероятно, обнаружите, что количество процессорной мощности, которой вы ограничены, ограничено, возможно, слишком ограничено для вас. Виртуальные хосты имеют тенденцию делить хост между несколькими виртуальными гостями, иногда всего 4, но чаще (и особенно для более дешевых планов) вплоть до 64.

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

Очевидно, что эти 3 варианта увеличивают стоимость, на арене веб-хостинга вы получаете то, за что платите.

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

2 голосов
/ 10 мая 2009

Я делаю то же самое с приложением Facebook (php, 350 000 уведомлений). У меня было 1 «предупреждение» от моей хостинговой компании об использовании процессора, но это «предупреждение» пришло от продаж, предлагая мне поработать над обновлением.

Я изменил пакетный скрипт, чтобы он использовал меньше ЦП за раз, по сути, вызывая меньше одновременных процессов (10) и помещая команду sleep (10) в нескольких местах. Команда sleep позволяет процессору снова опуститься до «нормального» уровня, так что возникают скачки процессора, а не постоянное использование.

На общем хосте ожидаются пики ЦП. Но постоянно высокий уровень процессора будет вызывать оповещения у хостинговой компании (если они хороши). Вы хотите избежать загрузки ЦП на уровне 50% или любого высокого уровня в течение длительного времени.

Если не имеет значения, занимает ли сценарий лишние несколько минут, добавьте несколько состояний ожидания (сна) в ваш код. Это также справедливо для других пользователей на той же машине.

2 голосов
/ 10 мая 2009

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

1 голос
/ 14 октября 2011

Короче говоря, нецелесообразно загружать ресурсы на общем сервере.

В принципе, если вы уделяете достаточно времени другим процессам, это неплохо. Однако пикирование процессора, о котором вы говорите, - это плохо и плохо для других пользователей системы. У вас должен быть механизм yield в главном цикле (например, usleep(100)) и запустить команду с большим nice числом, например 19.

Кроме того, похоже, что вы выполняете отдельные вызовы вставки / обновления / и т. Д. В сценарии пакетной обработки. С mysql намного лучше делать пакетные вставки, когда это возможно (очень быстро по сравнению с отдельными). Однако, в зависимости от того, как вы это сделаете, это может быть компромиссом оперативной памяти с временем ЦП (например, если вы сохраняете все значения вставки в строке до тех пор, пока они не будут готовы для вставки с помощью одного оператора вставки, то это может добавить до много оперативки). Если проблема с ОЗУ, вы всегда можете создать временный файл SQL, а затем импортировать все это в конце процесса.

Пакетная вставка выглядит примерно так (для таблицы с двумя столбцами varchar):

INSERT INTO `mytable` VALUES ('Field 1-Row 1', 'Field 2-Row 1'), ('Field 1-Row 2', 'Field 2-Row 2');

Это вставит две строки одновременно за долю времени.

Но опять же, основываясь на том, что вы описываете как цель сценария, вы, вероятно, не делаете много вставок для начала. Но, может быть, вы все еще можете собрать все (или многие) из ваших обновлений / вставок / удалений в БД в финальный скрипт, вызываемый в конце?

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

Все другие возможные предложения будут основаны на конкретной оптимизации вашего кода и схемы БД (оптимизация циклов, поисков, индексов и т. Д.).

То, что я категорически намекаю , заключается в том, что вы можете сделать что-то подобное в разделяемом хостинге, не перегружая ресурсы, но ваша структура БД, операторы SQL и алгоритмы (циклы и т. Д.) Должны быть высоко оптимизированы. , Если вы сделаете это, дополнительным преимуществом будет то, что ваш процесс также завершится очень быстро. Существует распространенное заблуждение, что php + mysql = slow / cpu hog, но в 99% случаев это проблема программирования или дизайна БД. Они должны легко справиться с таким количеством записей.

1 голос
/ 10 мая 2009

Серверы, на которых работает общий хостинг, обычно работают намного быстрее, чем обычный домашний компьютер, поэтому, вероятно, это не займет столько времени, сколько работает на вашем локальном компьютере. Я думаю, что тревожные сигналы начнут срабатывать, если вы будете отправлять 500 000 электронных писем в день, но если у вас есть разумный хост, использующий столько ЦП в течение короткого времени, это не должно быть слишком большой проблемой.

Вы всегда можете сначала поговорить с ними об этом, я уверен, что они что-нибудь уладят.

0 голосов
/ 12 мая 2009

Я бы предложил использовать такой сервис, как Amazon EC2 или Облачные серверы Mosso (принадлежащие Rackspace). Это виртуальные серверы с разумной почасовой оплатой и отличными API. Вы получаете мощность выделенного сервера без минимальных ежемесячных обязательств. Например, вы можете настроить виртуальный сервер с EC2, а затем запустить на обычном веб-сервере еженедельное / ежемесячное задание cron, чтобы запустить этот экземпляр EC2, запустить задание, а затем завершить работу экземпляра EC2.

...