Несколько важных вопросов, о которых должен знать разработчик workerman

1. Ограничения среды Windows

Под системой Windows один процесс workerman поддерживает только 200+ подключений.
Нельзя использовать параметр count для многопроцессорной настройки под Windows.
Нельзя использовать команды status, stop, reload, restart и т.д. под Windows.
Невозможно запустить демон в фоновом режиме, после закрытия окна cmd служба останавливается.
Нельзя инициализировать несколько прослушивающих сокетов в одном файле.
Для Linux эти ограничения не действуют, поэтому рекомендуется использовать Linux в производственной среде, а в качестве рабочего окружения можно выбрать Windows.

2. workerman не зависит от Apache или Nginx

Workerman сам по себе представляет собой контейнер, аналогичный Apache или Nginx, и может работать, если OK среда PHP настроена для выполнения workerman.

3. workerman запускается из командной строки

Способ запуска аналогичен запуску Apache с помощью команды (в веб-пространстве его использовать нельзя). Экран запуска выглядит примерно так:

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

Для длительных соединений обязательно использовать механизм "сердцебиения". Это очень важно, поэтому повторю трижды. При длительном отсутствии обмена данными соединение может быть закрыто роутером.
Информация о сердцебиении в workerman, Информация о сердцебиении в gatewayWorker

5. Протокол клиента и сервера должны соответствовать для взаимодействия

Это очень распространенная проблема среди разработчиков. Например, если клиент использует протокол WebSocket, то сервер должен также использовать протокол WebSocket (серверный код new Worker('websocket://0.0.0.0...')), чтобы соединение могло быть установлено и обмен данными был возможен.
Не пытайтесь обратиться к порту протокола WebSocket через строку адреса браузера или использовать протокол WebSocket для доступа к порту протокола голого TCP – протоколы должны соответствовать.

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

6. Возможные причины сбоя соединения

Одним из часто встречающихся проблем при начале использования workerman является сбой соединения клиента с сервером. Обычные причины таковы:

  1. Брандмауэр сервера (включая безопасность облачных серверов) блокирует соединение (это в 50% случаев).
  2. Протоколы, используемые клиентом и сервером, не совпадают (около 30% случаев).
  3. Неправильно указаны IP-адрес или порт (около 15% случаев).
  4. Сервер не запущен.

7. Не используйте операторы exit, die и sleep

Использование операторов exit и die в бизнес-логике приведет к выходу процесса и отображению ошибки WORKER EXIT UNEXPECTED. Однако процесс будет немедленно перезапущен для продолжения обслуживания. Если нужно вернуться назад, используйте оператор return. Оператор sleep заставляет процесс спать, во время которого не выполняется никаких бизнес-операций, и фреймворк также прекращает работу, что приводит к тому, что все запросы клиентов этого процесса остаются без обработки.

8. Не используйте функцию pcntl_fork

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

9. Не используйте бесконечные циклы в бизнес-коде

Не следует использовать бесконечные циклы в бизнес-коде, в противном случае процесс не сможет передать управление фреймворку workerman и, следовательно, не сможет обрабатывать сообщения клиентов.

10. Перезапускайте код после его изменения

Workerman - это постоянный фреймворк в памяти, поэтому для просмотра результатов изменений кода необходимо перезапустить workerman.

11. Для применения длительных соединений рекомендуется использовать фреймворк GatewayWorker

Многие разработчики используют workerman для создания приложений с длительными соединениями, такими как мгновенные сообщения, интернет вещей и другие. Для этого рекомендуется использовать фреймворк GatewayWorker. Этот фреймворк делает процесс создания приложений с длительными соединениями на базе workerman более простым и удобным.

12. Поддержка более высокой параллельности

Если количество одновременных подключений к бизнес-приложению превышает 1000, обязательно оптимизируйте ядро Linux и установите расширение event.