Насколько плох php сервер для игры?

[Godwarlock]

Собственно, вот такой вопрос. Сильно ли будет нагружаться сервер, если от 100 пользователей, будет идти запрос в бд каждую секунду? Например запрос в бд получения одной строки и вывода её во флеш.

[caseyryan]

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

[faraday]

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

[Godwarlock]

Предположим, что есть игра где надо собирать монетки. За десять минут, можно собрать 100 монеток. За две минуты, собирается 20 монеток. А теперь представим краш интернета в этой игре, если их никуда не записывать, то пользователь лишается своих 20 монет. Отсюда, как вариант, это как раз дергать базу, чтобы записывать каждую собранную монетку. И при заходе/выходе из игры мы будем получать столько монет, сколько было собрано.

[faraday]

Ну вы сами выбираете логику . Хотите чтоб сохранялось в базу при креше - сохрайяйте. Сервер в курсе когда отваливается клиент)
update базы с миллионом записей при каждом клике - смущения не вызывает? работать будет в тысячи раз медленнее. Я уж молчу каждый раз дергать модель игры из базы, и проверка каждого клика на античит.

[Godwarlock]

Хотите чтоб сохранялось в базу при креше - сохрайяйте
Последняя запись до креша. Почему миллионные записи? Можно ограничить количество монет. Так или иначе, что Вы предлагайте в таком случае?)

[faraday]

Допустим в базе миллионы игроков. делать выборку из полной базы для каждого инкремента - не правлиьно. Для 1 запроса в секунду не кртитично да.
В каком случае? Если у игрока пропадет интернет, перед сбором монеты - то она в любом случае не сохранится. все собранные до этого - сохранятся в обоих случаях

[Godwarlock]

Не для каждого инкремента, брать id пользователя записанный в куках и сравнивать его с аналогичным значением id в базе.
все собранные до этого - сохранятся в обоих случаях
Сохранятся, если при сборе монеты сработал запрос. Но они не сохраняться, если не делать запрос после каждого сбора. Иначе, как работают браузерные текстовые игры на сервере php, которые имеют не одну тысячу записей в бд.

[faraday]

О каком запросе речь? от клиента к серверу он в любом случае должен быть. Но не обязательно каждый запрос сразу писать в базу. работаете с памятью. а ее когда нужно - синхронизируете.

[Godwarlock]

О запросе от сервера, в бд. О какой памяти идет речь? Можно поподробнее?)

[faraday]

Об оперативной разумеется)
В общем возвразаясь к теме первого вопроса. 100 запросов в секунду при работе с проиндексированной таблицей - это не много. Но в целом, затрагивая вопрос архитектуры игры - такой подход не правильный.

[Godwarlock]

А чем он неправильный?)) Я просто не пойму. Вот человек играет. Собирает одну монетку, посылаем запрос из флешки, серверу. Сервер же обрабатываем полученные данные и делает запрос в бд, дабы записать, что вот этот игрок собрал одну монетку и если он сейчас выйдет из игры, покинет браузер и вернется на следующий день, то у него будет та самая монетка, которую он вчера получил) В чем неправильность?) Ну будет не один, а 500 таких игроков, которые собирают монетки, 500 запросов в в бд и то не факт что в секунду, кто-то может в это время не собирать монетки, а заниматься чем-то другим. Как будет правильно тогда?)

[faraday]

Хорошо, для игры где нужно кликать по монетками - это подходит идеально)
Для более сложных игр - нет. Если приведете пример более реальной игры - объясню чем.
Для любой игры где нужен мультиплеер - ваш вариант не подходит.

[Godwarlock]

А чем эта игра не реальная? В любой игре, используются одни и те же запросы в БД. Select, insert, update - основные запросы. Они не куда не денутся в другой игре) К примеру, давай возьмем такую игру. Есть чувак, который переходит по локациям, каждая локация имеет свой уникальный id, соответственно при переходе в другую локацию - update в одну таблицы и insert в другую. К примеру, в каждой локации есть монеты, которые игрок может собрать. При сборе монеты update одной таблицы, insert в другую. Помимо всего прочего, персонаж может нарваться на неприятности, например на него кто-то напал неведомый. Опять же идет запрос в бд, мол этот игрок вступил в бой и чтобы когда он вышел/вернулся в игру, то мог продолжить бой. В бою также, при каждом ударе идет запрос в бд, чтобы отслеживать сколько осталось хитов у оппонентов и тп, при этом запросы не к одной таблице, а к нескольким. К примеру. Объясняй)

[faraday]

Странно вы как то выделяете сущности.. Почему локация таблица в которую инсертится игрок?
Таблица локаций может представлять собой id, name, preview, background, walls
Таблица игрока id, currentLocationId, coins
При переходе игроков на локацию будет апдейтится поле в его таблице. Это что касается вашего примера.
Я еще раз говорю, он имеет право быть. Но представьте что у вас на локации другие живые игроки. как вы будете узновать их координаты? Опрашивать базу каждую секунду?
Игра может иметь сложные состояния, не все из которых можно представить в виде таблиц.

[bifidokk]

А чем он неправильный?)) Я просто не пойму. Вот человек играет. Собирает одну монетку, посылаем запрос из флешки, серверу. Сервер же обрабатываем полученные данные и делает запрос в бд, дабы записать, что вот этот игрок собрал одну монетку и если он сейчас выйдет из игры, покинет браузер и вернется на следующий день, то у него будет та самая монетка, которую он вчера получил) В чем неправильность?) Ну будет не один, а 500 таких игроков, которые собирают монетки, 500 запросов в в бд и то не факт что в секунду, кто-то может в это время не собирать монетки, а заниматься чем-то другим. Как будет правильно тогда?)

Поднимаете сокет-сервер на php. Клиент коннектится, собирает монетку, вы в оперативной памяти в переменной состояния типа coins_amount делаете инкремент. Когда клиент отваливается (пропадает инет, или пользователь закрывает браузер), сервер ловит это событие и по нему записывает переменную в базу, либо делает это по другому событию. Таким образом, у вас не будет дергания базы на каждый клик.

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

Добавлено через 1 минуту
А чем эта игра не реальная? В любой игре, используются одни и те же запросы в БД. Select, insert, update - основные запросы.

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

[Godwarlock]

А у вас есть пример реализации? И где гарантия того, что к примеру читер не изменит значение переменной сoins_amount и когда придет время отправки в бд запись, то там не будет триллион монет)

[faraday]

как он изменит coins_amount в оперативнйо памяти сервера?
Практически каждая игра топа вк - пример такой реализации

[Godwarlock]

Ладно, а есть документации какие-нибудь по такой реализации? Ибо пока я еще не особо понял, как это применять на деле.

[Котяра]

Можно и "как бы" писать в базу, а для кэширования использовать memcached

[faraday]

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

[bifidokk]

Ладно, а есть документации какие-нибудь по такой реализации? Ибо пока я еще не особо понял, как это применять на деле.

документация такой реализации обычно формируется в голове после кучи проб и ошибок :)