@alexhd

Здравствуйте, уважаемые форумчане!

Меня давно интересует вопрос: допустим написал я скрипт, выложил его на свой сайт, и тут к нему захотели обратиться сразу 100 пользователей. Что будет с моим сайтом в этом случае?
Слышал, что сайт должен упасть в этом случае, если не применять так называемое распаралеливание. Так мне сказал один программист, к сожалению, время на обьяснение у него не было...
Обьясните, пожалуйста, новичку, что же такое распаралеливание, и может есть еще какие нибудь способы борьбы с нагрузкой на скрипт?

0

@Gouvere

Сервер сам разберется что делать. Если хотите чтобы сайт не упал - берите сервер получше.

0

@alexhd

Gouvere, т.е, на этапе написания скрипта можно не предпринимать никаких действий, даже если знаешь, что скрипт будет порядком загружен? Достаточно купить дорогой хостинг?

0

@Gouvere

alexhd, ну конечно желательно оптимизировать, как сможете. Кешировать данные, например. Но ни про какое распараллеливание не слышал.

1

@alexhd

Gouvere, понял)спасибо)

0

@Programmer_

Не не слышал )
В php на *nix серверах есть возможность управления процессами PCNTL http://php.net/manual/ru/book.pcntl.php
Но применение этого подхода может не только повысить производительность а и свести ее на нет
Итого... Для нормальной работы достаточно грамотного кода + хороший сервер... Но чаще всего, самым узким местом является БД

0

@Tatikoma

Не-не-не, давайте-ка все по-честному =)

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

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

Теперь про распараллеливание - т.к. код для ответа на HTTP-запросы теперь не требует много ресурсов - там нет необходимости что-либо распараллеливать. Это важно, т.к. параллелизм с mod_php или php-fpm может привести к некоторым трудностям (например это может упростить DDoS).

Соответственно для параллельного решения задач в PHP есть несколько разных методов:
1. Самый известный костыль, - используем curl_multi который делает десяток HTTP-запросов к нужному скрипту. Преимущество в том, что работает на любом shared-хостинге, минус в том что это костылище и тянет за собой весь HTTP-стек, что плохо.
2. pcntl_fork, - этот метод создает копию процесса в котором он был вызван (а за счет copy-on-write, - он не так уж и медлителен), минус в том что общаться с дочерними/родительским процессами довольно затруднительно. Я использую для общения между такими процессами stream_socket_pair, но он какой-то неторопливый по каким-то причинам, поэтому если нужно передать много данных из мастер-процесса - стараюсь сохранить их в переменную до fork'а, тогда у всех детей есть эти данные. Впрочем создание нового процесса - операция в все равно довольно затратная.
3. Исконно правильный и православный способ, - pthreads (для расширения потребуется php thread safe, что может оказаться довольно затруднительным - пакет под Debian (одна из наиболее популярных серверных платформ) просто отказывается перекомпилироваться с флагом --enable-maintainer-zts (конфликтует с патчами от Debian), в Debian про это знают, но не шевелятся: приходится либо брать сурс с php.net, либо брать пакет с gotdeb с php5.6 с включенным thread safe: это не очень круто, т.к. такой подход убивает основное преимущество дистрибутива - его стабильность). Собственно говоря это расширение реализует POSIX-треды со всеми присущими им недостатками и преимуществами, оно довольно сыровато, но я уже разбираюсь с ним с целью внедрить у себя в продакшн.

Соответственно лично мое предпочтение в использовании сначала pthreads, потом форки, первый вариант я не использую никогда.

-------------------------

И непосредственно ответ на вопрос автора. Если к тебе на сайте обратится сразу 100 пользователей произойдет примерно следующее (может варьироваться в зависимости от используемого ПО и конфигураций, я буду говорить на примере своих серверов):
1. В первую очередь у меня запросы обрабатывается nginx, - 100 запросов для него не проблема, он их прочитает, распарсит и отдаст в php-fpm на обработку.
2. php-fpm в рамках настроенных у себя ограничений начнет параллельно обрабатывать запросы, если у него стоит ограничение на 64 параллельных запроса, - то соответственно 36 запросов будут в очереди ждать, пока какой-либо запрос завершит обработку.
Собственно все. Запросы просто обработаются в порядке очереди и никакого кошмара не произойдет, а т.к. среднее время обработки запроса 0.001 сек - то проблем это не доставит ровным счетом никаких, даже если прилетит тыща одновременных запросов - они довольно сносно обработаются, пользователи скорее всего не заметят особых тормозов в работе ресурса.

--------------------------------

Интересно становится, если на сервер придет сразу 100 тыс или даже миллион запросов: здесь уже начинается масштабирование (по-сути тоже распараллеливание, но на уровне физических или виртуальных серверов), для решения этой задачи используется простая схема: один сервер занимается только приемом запросов, которые потом round-robin'ом передает на сервера которые их обрабатывают (nginx, кстати, с этим прекрасно справляется).

В какой-то момент начинается нехватать одного балансера для того чтобы справится с текущей нагрузкой, тогда на помощь приходит dns round-robin - просто отдаем разные IP-адреса балансеров по принципу round-robin, что тоже проблем не представляет - тот же bind прекрасно выполняет эту задачу.

Резюмируя все вышенаписанное - каких-либо особых сложностей в работе с большой нагрузкой нет, нужно просто изучить какие-то основы и можно смело делать проекты под миллионы пользователей =) Ну и никогда не ползволять серверам быть загруженными выше 50%.

2

@Tatikoma

Насчет pthreads походу погорячился, - как-то плохо он завелся, масса сегфолтов на ровном месте и других странных штук. Продолжаю использовать форки =)

0