PHP и высокая нагрузка. Каков предел?

Question

[Игорь Самохин]

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

Подскажите, есть ли смысл использовать php для высоконагруженных проектов, например, для онлайн игры с частым обновлением состояний игрового поля, например, как тут: vk.com/app3144697 (игроки сидят за столом и крутят бутылочку. )

И как бы вы описали задачи, под которые php для высокой нагрузки подошел был и не подошел?

Спасибо. Извиняюсь за дилетантское описание вопроса))

Answer 1

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

для подобного удобнее конечно взять node.js + socket.io, но и на php (с reactphp) можно. В плане нагрузок у вас больше будет уходить времени на доставку данных, нежели на их обработку, так что тут скорее эффективный сервер нужен. в node.js он из коробки довольно эффективен, а в reactphp чуть медленнее (хотя если поставить еще libevent то норм).

Comments

[Александр Кубинцев]

Я думаю они даже равны приблизительно. У обоих вроде как проблема в другом: слабая поддержка многопоточности. Так что наиболее универсальным решением была и остается Java.

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

@akubintsev, почему java? golang тогда уж. С его-то горутинами.

[Игорь Самохин]

@Fesor как вы считаете - игра в примере ( бутылочка ) с сервером на php потянет 50 000 уникальных? С учетом, что за одним столом 10 человек и нужна будет синхронизация и общий чат стола?

[Александр Кубинцев]

@Fesor я с ним не знаком. Пока что :) Но в первую очередь взялся бы за Java (знаком поверхностно). Все же технологии технологиями, но инвестируя время в их изучение хотелось бы иметь максимальную материальную отдачу в перспективе.

[Александр Кубинцев]

@grigor007 а что значит 50к уников? Интереснее иметь метрику в виде онлайна. Как уже было замечено ниже, дело не столько в том потянет или не потянет, а в горизонтальной масштабируемости решения. Какой бы крутой не была платформа, рано или поздно наступит предел вертикальной масштабируемости при росте нагрузки.

Answer 2

[Виталий Желтяков]

Методика определения нагрузки:
- Определяем количество пользователей онлайн.
- Зная количество пользователей онлайн, определяем сколько будет запросов в секунду.
- С помощью xdebug замеряем среднее время выполнения скриптов.
- Умножаем среднее время выполнения скриптов на количество запросов в секунду.
- Если получившееся время в пределах 2 секунд, то всё нормально. Иначе либо не php, либо оптимизация.

По поводу выбора php:
- PHP весьма неплохо подходит для высоконагруженных проектов, если минимизировать работу с внешними данными (база и memcached).

Answer 3

[Вадим Яковлев]

php + nginx-push-stream-module вполне подойдут для вашей задачи.
У php есть проблемы с горизонтальным маштабированием, но и они решаются за счет оптимизации, подключения кешей и разных акселераторов.

Comments

[Григорий Перетяка]

Какие это проблемы у PHP с горизонтальным масштабированием? Как раз их нет, потому что каждый запрос по новой все инициализирует. Из-за этого приходится использовать акселераторы и memcashed. Но как раз масштабируемость, можно сказать, заложена в архитектуре.

[Вадим Яковлев]

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

[Григорий Перетяка]

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

ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%81%D1%88%D1%...

[Вадим Яковлев]

@Peretyaka каюсь

Answer 4

[Григорий Перетяка]

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

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

PHP - это самое проверенное и актуальное решения для большой нагрузки на данный момент. Большинство крупных сайтов в интернете крутится именно на нем. Так что непонятен ваш вопрос про предел :)

Comments

[Игорь Самохин]

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

Если php подходит для всего, то зачем нужен erlang?

[Григорий Перетяка]

Хранить игровое поле в памяти приложения как-то не очень правильно. Это все-равно должна быть какая-то база данных и ее масштабирование - отдельная тема.

> Если php подходит для всего, то зачем нужен erlang?

А где я писал, что PHP подходит для всего? На Erlang сложновато написать большую систему, да и разработчиков мало и материалов в сети.

[Игорь Самохин]

То есть вы хотите сказать, что в той же бутылочке реально написать сервер на php, учитывая, что онлайн может быть 50 000 в одно время - но за разными столами?

Придется же наверное чем-то жертвовать? Отличия какие будут, чем если бы сервер был на erlang?

[Григорий Перетяка]

> Отличия какие будут, чем если бы сервер был на erlang?

Больше серверов, наверное, а может и нет.
Только разработать на Erlang будет сложнее точно, а 50к не факт, что будет, как и неизвестно где будет узкое горлышко, которое нужно будет переписать на более специализированный язык.

[Григорий Перетяка]

Это вы меня троллить пытаетесь :) Сколько же и какие большие проекты написаны на Erlang? :) На PHP примеры не нужно приводить?

[Григорий Перетяка]

Хотя бы Facebook, Vkontakte.

[CAMOKPYT]

@Peretyaka там от PHP одно название

[Григорий Перетяка]

1. Что? Изначально они крутились на интерпретаторе PHP, VK вообще до довольно недавнего времени. И? Что помешает автору позже использовать и эти решения, эффективность которые, кстати, довольно сильно переоценивают.
2. У HipHop VM есть поддержка ООП.

[Александр Кубинцев]

@Peretyaka по поводу постоянных соединений - смотрите ReactPHP. Тот же Node.js, вид сбоку.

@pygame на самом деле таких проектов просто исторически пока еще не видно. Нормально пыха стала развиваться только с 5.3, а это был 2011 год, то есть от силы 3 года минуло. Все что старее конечно же фарш.

[Игорь Самохин]

@Peretyaka

а можно примеры на php подобных игр с высокой нагрузкой? А то одни говорят - php создавался для http, то есть для сайтов..

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

С одной стороны php - интерпретатор и у него уже нет преимуществ в скорости перед, например, java.

Поэтому мой разум в подвешенном состоянии.. Можно или нельзя на php? Выдержит ли 50 000 пользователе онлайн в бутылочке ( берем за факт, что 50 000 будет )?

[Григорий Перетяка]

А что значит не выдержит? Серверов может понадобится больше.

> с частым обновлением игровой ситуации

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

> и синхронизацией данных для пользователей.

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

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