Реализация многопоточного сервера на PHP

Данная публикация не претендует на полноту решения поставленного вопроса. Сервер разрабатывается исключительно в ознакомительных целях. Многие важные вопросы, такие как, например, обработка ошибок сокетов, опущены. Для реализации многопоточного сервера мы будем использовать, конечно же, потоки. Очень часто приходится видеть фразу, что, мол, в PHP потоков нет. Так вот это неправда. Потоки есть, но реализованы в отдельном расширении pthreads.

Для начала нам понадобится сборка PHP, скомпилированная с флагом thread safety. Я использую Windows для работы, поэтому скачал готовый пакет здесь. Нужно лишь правильно выбрать разрядность ОС, нужную версию PHP и, конечно же, Thread Safe версию. На протяжении статьи будет предполагаться, что архив с PHP мы распаковали в C:\php директорию. Далее нам нужно установить расширение pthreads. Идем сюда и выбираем версию, соответствующую скачанной версии PHP и разрядности системы. Из архива копируем файл php_pthreads.dll в директорию C:\php\ext и файл pthreadVC2.dll в директории C:\php и C:\Windows\System32. В директории C:\php переименовываем файл php.ini-development в php.ini и добавляем в него такую строку:

extension=php_pthreads.dll

Также находим и раскоменчиваем директиву extension_dir и выставляем ей значение «C:\php\ext» (у меня в версии PHP7 относительные пути не заработали). Открываем командную строку и проверяем:

C:\php\php.exe -v

В конце первой строки вывода мы должны увидеть пометку (ZTS). Переходим непосредственно к реализации сервера. Создаем файл (в моём случае он будет располагаться по адресу C:\server.php. Для начала создадим сокет, который будет слушать порт 8080 на нашей локальной машине.

$server = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_bind($server, '127.0.0.1', 8080);
socket_listen($server);

Далее создаём пул воркеров.

$pool = new Pool(10, Worker::class);

Первый аргумент устанавливает максимальное количество действующих потоков, второй имя класса воркера. Для каких либо более определенных задач можно описать свой класс, унаследовав его от класса Worker. Мы же будем использовать оригинальный класс. Забегая вперед скажу, что в классе потока установленный воркер можно получить через $this->worker.

Далее реализуем класс, который будет выполняться в отдельном потоке. Класс должен наследоваться от Threaded.

class Task extends Threaded
{
    protected $socket;

    public function __construct($socket)
    {
        $this->socket = $socket;
    }

    public function run()
    {
        if (!empty($this->socket)) {
            $response = "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nContent-Length: 12\r\n\r\nHello world!";
            socket_write($this->socket, $response, strlen($response));
            // при попытке закрытия сокета я получаю ошибку zend_mm_heap currupted, поэтому эту часть в тестовом решении опускаю 
            //socket_close($this->socket);
        }
    }
}

Наш класс принимает в конструкторе сокет соединения с клиентом. Так же действия, выполняемые в потоке, должны быть описаны в методе run(). В моем случае это ответ клиенту базовых заголовков и текста «Hello world!».

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


$servers = [$server];

while (true) {
    $read = $servers;

    if (socket_select($read, $write, $except, 0) >= 0 && in_array($server, $read)) {
        $task = new Task(socket_accept($server));
        $pool->submit($task);
    }
}

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


register_shutdown_function(function () use ($server, $pool) {
    if (!empty($server)) {
        socket_close($server);
    }

    $pool->shutdown();
});

Собственно всё. Запускаем сервер в командной строке и пробуем открыть в браузере localhost:8080.

cd C:\
C:\php\php.exe server.php

Ниже привожу полный код сервера.


<?php

$server = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_bind($server, '127.0.0.1', 8080);
socket_listen($server);

$pool = new Pool(10, Worker::class);

class Task extends Threaded
{
    protected $socket;

    public function __construct($socket)
    {
        $this->socket = $socket;
    }

    public function run()
    {
        if (!empty($this->socket)) {
            $response = "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nContent-Length: 12\r\n\r\nHello world!";
            socket_write($this->socket, $response, strlen($response));
        }
    }
}

register_shutdown_function(function () use ($server, $pool) {
    if (!empty($server)) {
        socket_close($server);
    }

    $pool->shutdown();
});

$servers = [$server];

while (true) {
    $read = $servers;

    if (socket_select($read, $write, $except, 0) >= 0 && in_array($server, $read)) {
        $task = new Task(socket_accept($server));
        $pool->submit($task);
    }
}

Спасибо за внимание!
Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 50
  • +3
    Но зачем?
    • +4

      троллейбус_из_хлеба.jpg

      • –10

        Такие штука на несколько порядков быстрее и стабильнее серверов, вроде Nginx. На просторах хабра были где-то статьи на эту тему с бенчмарками, найти правда не могу.

        • –3

          Минусы за то, что нет пруфов подозреваю? Ловите: https://habrahabr.ru/post/220393/


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

          • +3
            php-pm имеется ввиду вот это.
            другое дело, что над php демоном все равно нужно ставить nginx)
          • +6
            Это, мягко говоря, не правда: master процесс в nginx при старте форкает воркеров, которые в асинхронном режиме обрабатывают соединения (по одному воркеру на поток ядра проца).

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

            Стабильнее и быстрее? Ну-ну.
            • 0

              Тут просто теплое с мягким. Естественно, стейтфул быстрее стейтлесс, т.к. не надо каждый раз поднимать все окружение (читать конфиг, строить роуты, коннектиться к базам и т.д.) для обработки одного запроса, но nginx тут ни при чем.

        • –3
          Сколько перерезал, сколько душ я загубил.
          Сколько PHP-серверов многопоточных я убил.
          • +1
            Справедливости ради.

            Случай из практики.
            Обращается заказчик: Необходимо что-то сделать с php cервером который обрабатывает websocket-соединения.
            Сервер кое-как обслуживает 5 подключений, а потом все встает колом внутри него.
            Специфика протокола была такова, что клиенты генерировали очень много маленьких сообщений в единицу времени.

            PHP-сервер был выкинут, и на его место за 2 часа работы водружено нормальное решение, которое справляется с поставленными задачами до сих пор.
            • 0
              случай из практики — нужен был websocket сервер. сделали на Ratchet. жрет 15-30 мб, обслуживает сотню одновременных подключений.
              • 0
                случай из практики: жрет 70мб, обслуживает 10к соединений. :) кто больше?
                • 0
                  и все же
                  >> 5 подключений, а потом все встает колом внутри него
                  очевидно что тут дело совсем не в php. понятно, что интерпретируемый язык со сборщиком мусора по определению не самый производительный. но не до такой степени.
                  • 0
                    Все зависит от задачи. PHP великолепен как генератор HTML.
                    Но делать для него сервера, которые смогли бы обслуживать 10к и больше соединений, я бы не стал.
                    Всему свой инструмент.
                    • 0
                      У вас устаревший взгляд на PHP
                      • +1
                        Нет, скорее кто знает PHP пихает его везде где можно. Может быть достаточно попробовать другие инструменты? Может быть тогда вы измените свои взляды?
                        • +1
                          Может быть достаточно попробовать другие инструменты?

                          В случае с «Сервер кое-как обслуживает 5 подключений» было незнание одного инструмента, потому начали использовать тот, который знали лучше.
                          К PHP, как всегда, это отношения не имеет.
                          • 0
                            Нет, скорее кто знает PHP пихает его везде где можно. Может быть достаточно попробовать другие инструменты? Может быть тогда вы измените свои взляды?

                            По-моему, ровно то же самое можно сказать и тем, «кто знает другие инструменты». :)

                            Человеку свойственно в первую очередь пользоваться тем инструментом, которым он владеет лучше.
                            • 0
                              Согласен при условии что этот инструмент работает как надо в тех условиях, которые ему уготованы.
                              • 0
                                В случае с PHP обычно проблемы не на его стороне, а на стороне кода. PHP давно перестал быть только генератором HTML.
                              • 0
                                И это не просто свойственно, это повышает эффективность решения реальных задач. Грубо, на PHP я подниму относительной простой веб-сокет сервер за день, на Node.js — за три дня, на Go или C — за месяц. Примерно в той же пропорции будет и скорость решения возникающих проблем, от багфиксов до изменившихся требований. Естественно, пока их можно решить в рамках выбранного стека.
              • 0
                В конкретно данном случае лучше будет работать однопоточный асинхронный сервер
                • 0

                  бенчмарки?

                  • +4
                    зачем?
                    • 0

                      чтобы наглядно проиллюстрировать пределы применимости

                      • 0

                        Ну для для продакшена лучше использовать ReactPHP или Kraken


                        Бенчмарки некоторые

                        https://habrastorage.org/getpro/habr/comment_images/b52/37a/6e4/b5237a6e4838671f1753127edd178a4f.png

                        • +7
                          Добавьте в график жесткий диск Seagate Barracuda ST1000DM003: там 7200/мин.
                          И болгарку Makita 9555 HN: уже целых 10000/мин. Лидер найден!
                  • –2
                    Зачем?
                    • +1
                      Как минимум в статье можно подсмотреть пример использования потоков для сложных вычислений или асинхронных действий.
                      • 0
                        Потоки для сложных вычислений? :) Вы точно правильно понимаете, что такое треды? :)
                        • 0
                          Думаю да. Я сейчас занимаюсь разработкой аналитической системы и, если бы платформа была не self-hosted типа, я бы, наверное, использовал потоки для распределения параллельных вычислений на несколько ядер процессора. Разве это не имеет смысл?
                    • 0
                      Немного смущает только, что нужно дополнительно в PHP включать потоки.
                      • +2
                        На самом деле потоки в PHP могут пригодиться только в узкоспециализированных приложениях и, я думаю, если это действительно нужно, установить расширение не будет проблемой.
                        • 0
                          Я бы сказал немного иначе — во многих самостоятельных приложениях используют потоки, мьютесы, семафоры, а еще иногда события и блокировки. Именно из-за предметной области PHP в нем это в диковинку, а в любом другом языке потоки стандартное средство языка. И тут надо ответить себе на вопрос «Почему мне понадобились потоки?». Варианты ответа: 1. я не по назначению использую PHP 2. я не могу взять другой язык с потоками 3. автор реализации не предполагал написания самостоятельных приложений
                          • +1
                            Официальные расширения — стандартное средство языка. PHP — язык программирования общего назначения, у него нет предметной области.
                            • +1
                              1. Официальные расширения — стандартное средство языка

                              1.1. Открываю документацию и смотрю на список стандартных функций (built-in function) никаких упоминаний о потоках (в основном файлы и строки), а потоки относятся к _расширениям языка_ (PECL Extensions). При дальнейшем чтении становиться ясно, что механизмов расширений в PHP бывает несколько видов и каждое расширение нужно собрать и подключить… _но многие расширения_ уже включены в дистрибутив (но не подключены к языку — в случае с pthreads нужно это сделать самостоятельно). Следовательно это не стандартные средства языка, а расширенные с помощью расширений и нужно добиваться их появления:

                              Also note that many extensions are enabled by default and that the PHP manual…

                              Для примера берем потоки в Java и смотрим описание для пакета «java.lang» где находиться класс Thread:

                              Package «java.lang» provides classes that are fundamental to the design of the Java programming language.

                              Таким образом в Java потоки относятся к фундаментальному дизайну языка )

                              2. PHP — язык программирования общего назначения, у него нет предметной области.

                              2.1. Открываю страницу «Introducing — What is PHP?» и читаю

                              Although PHP's development is focused on server-side scripting,…

                              ( дальше конечно написано, что если очень нужно, то можно писать и всякое остальное, но это же не «focused» и понятное дело не «common-way», а всякой забавы ради не целевое использование полимеров )

                              2.2. Открываю FAQ и читаю вопрос «What is PHP?»

                              PHP is an HTML-embedded scripting language. The goal of the language is to allow web developers to write dynamically generated pages quickly.
                      • 0
                        Потоки в php и в придачу еще и под windows. Полный набор…

                        кстати у нас в компании используется подобный подход :) Правда не под windows.
                        Дело в том что мы используем RabbitMQ, и что бы не писать всю функциональность заново на другом языке было принято решение писать демон на пхп.
                        • +1
                          Многие важные вопросы, такие как, например, обработка ошибок сокетов, опущены.

                          Так ведь это самое интересное. Вам придется много-много страниц кода написать, пока у вас получится более-менее работающая реализация HTTP, и пока вы сможете начать писать бизнес-логику.
                          Поэтому соглашусь с предыдущими комментаторами:
                          Зачем?
                          • +2
                            У меня две мысли.

                            1. У меня сервера на Debian, включение thread safety в deb-пакете не предусмотрено (даже если пересобираем пакет с включением thread safety — оно не работает, какой-то из дебиановских патчей ломает), по крайней мере так было два года назад (тогда же пробовал pthreads — сегфолты на каждом шаге). Соответственно это нужно брать голый PHP и собирать из исходников…

                            2. Никаких серьезных преимуществ у использования тредов перед процессами — нет, после создания сокета можно нафоркать несколько процессов, которые будут принимать соединения. Работать будет ничуть не хуже, но без необходимости включения страшных расширений.
                            • 0
                              Ваша вторая мысль очень спорная. Преимущества начинаете понимать когда разберетесь в вопросе и используете и то и другое достаточно хорошо для того что бы «прочувствовать» разницу. Ну это как в Африке знают только один вид снега, а на северном полюсе всего один тип песка, но мы то знаем… снега и песка бывает много разных типов… так и отличий на самом деле огромное количество… взять хотя бы размер стека выделяемого под поток…
                              • 0
                                Согласен, мысль спорная. Думаете стоит оформить в виде статьи с бенчмарками?
                                • 0
                                  Не только можно, но и нужно оформить — хотя бы только для собственного спокойствия. Вот только как Вы задачу выбирать будете для бенчмарков?
                              • 0
                                Собирать PHP сложно только первый раз)
                                Как выше было сказано, в php разработчиками не часто используются треды.

                                Если по первому пункту снова возникнет надобность тут полезная информация.
                              • 0
                                Давно подобный механизм использую и он очень удобен в тестировании сетевого софта. Очень часто пишу сетевые приложения и необходимо тестировать всевозможные сбои в работе (+ безопасность протокола) и вот тут проще на php быстро накидать код теста, чем писать на Си.
                                • 0
                                  Я бы использовал потоки в тяжёлых sql запросах для движка.
                                  • 0
                                    // при попытке закрытия сокета я получаю ошибку zend_mm_heap currupted, поэтому эту часть в тестовом решении опускаю
                                    //socket_close($this->socket);

                                    Это же segfault, потоки или сокеты?
                                    • +1
                                      В основном потоке сокет закрывается нормально, во второстепенном — с этой ошибкой. Если поможете победить проблему — буду признателен.
                                      • 0

                                        Сначала socket_shutdown, потом уже socket_close ?

                                        • 0
                                          Не помогает. Shutdown выполняется, а на close все равно эта ошибка. Причем именно когда сокет обрабатывается в новом thread-е. Если же дождаться выполнения thread-а и закрыть сокет в основном потоке, то всё работает хорошо. Очевидно какой-то баг, потому как алгоритм работы с сокетами верный.
                                        • 0
                                          Нужно взять за правило: не создавать и не убивать ресурсы в потоках.
                                          Можно попробовать следующее:
                                          создать класс и через его статические свойства сообщать основному потоку, что можно закрывать сокет; когда поток отрабатывает, то он переключает соответствующие флажки в этих свойствах, в основном цикле это отслеживается, и сокет-ресурс основным потоком закрывается

                                          Вообще, раньше pthreads не отличался стабильностью, поэтому прибегать к его использованию было не желательно. Если сервер не предполагает использование долгих вычислений, то потоки, как таковые, не нужны, хватает неблокирующих сокетов.
                                      • 0
                                        я лично очень часто использую параллельные вычисления на php. но я просто запуская воркеры в нескольких консолях.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое