Нагруженные приложения

[ElaBamz]

Почти в любой браузерной игре присутствует элемент "энергия" которая расходуется по по мере активности игрока, но и восстанавливается со временем. Вот и вопрос, как?

Если пользователей онлайн по статистике больше 30-40к, неужели через corn?
При условии что нужно вытащить каждого пользователя (и это каждые 3 минуты), проверить не равна ли энергия максимальному значению и обновить данные.

Думаю такой цикл серьезно озадачит сервер.

 

[WMix]

а как ты думаешь, можно ли это сделать простым javascript и ответом сервера осталось секунд до восстановления, ореентируясь на базу данных?

 

[Вурдалак]

Тебе действительно необходим cron для того, чтобы узнать сколько энергии восстановится у игрока за минуту?

class Hero
{
    const HP_PER_SECOND = 2;
    const MAX_HP = 3000;

    protected $lastDamageTime;
    protected $lastHp;

    public function getCurrentHp()
    {
        $timeDiff = time() - $this->lastDamageTime;

        return min(
            self::MAX_HP,
            $this->lastHp + $timeDiff * self::HP_PER_SECOND
        );
    }
}

(именно в таком виде будет race condition, ога)

 

[ElaBamz]

Видимо у меня еще детская логика, спасибо

 

[Gas]

Если пользователей онлайн по статистике больше 30-40к, неужели через corn?

при таких цифрах мне видится стэк техгологий несколько иной, не php/mysql, а java и естественно все объекты онлайн пользователей уже в памяти и с ними ведётся работа, периодически скидывая изменения на диск.

 

[keltanas]

при таких цифрах мне видится стэк техгологий несколько иной, не php/mysql, а java и естественно все объекты онлайн пользователей уже в памяти и с ними ведётся работа, периодически скидывая изменения на диск.

А чем php + redis плох?

 

[Gas]

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

 

[Lionishy]

Если игра не отличима от ЖЖ или форума, то вполне можно использовать и PHP.
Кроме того, для самой игры сервер можно упаковать в расширение PHP, которое будет работать быстро и которое будет всегда в памяти и многопоточно.
А сценарии использовать для генерации html контента пользователю. На PHP это, несомненно, сделать проще.
В итоге: накопить пользователей в количестве окупаемости машины + прибыль вполне можно. Остальное -- зола.
Выжимать никому и не нужно, главное -- окупиться.
Так что 30 - 40 к на машину -- это, скорее всего, многовато, гораздо раньше начнёт игра плюшками окупаться. Зато в стандартной связке какой-нибудь PHP + что-то там + что-то ещё можно будет дешевле стартануть.

 

[Alexandre]

при таких цифрах мне видится стэк техгологий несколько иной, не php/mysql, а java и естественно все объекты онлайн пользователей уже в памяти и с ними ведётся работа, периодически скидывая изменения на диск.

можно и на РНР, глаавное дело в архитектуре. Наша игра на пхп по производительности был не хуже, чем в соседней группе, реализованной на java.

PHP работал как демон.

 

[Alexandre]

сервер можно упаковать в расширение PHP, которое будет работать быстро и которое будет всегда в памяти и многопоточно.

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

2) упаковать код в РНР расширение - это большой труд, проще изначально все написать на Си/С++ или как предлагали выше на Java
3) как вариант можно использовать PHP-Hiphop, но он имеет свои ограничения, которые могут не подойти текущему проекту.
на это решение не подошло, так ка не было драйвера к монге и не может использовать другие ПХП расширения.

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

на серверной стороне крутился PHP демон, который принимал входящие сокетные соединения. Масштабирование задавалось round-robin при загрузке HTML страницы (выбирался один из серверов)

Если, сокетное соединение не могло создаться (Пользователь был за прокси), то обмен шел через WEB сервер. Но таких было всего 20 на 1000 пользователей.

Общие данные хранились в мемкеше, БД использовалась только при обрыве/создании соединения (сохранение данных).

Обмен данными - бинарный, на базе protobuff

 

[Alexandre]

А чем php + redis плох?

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

 

[fixxxer]

redis это вообще в некотором смысле хак. к нему нельзя относится, как к полноценной key-value базе.
это просто in-memory storage с возможностью персистенции, реализованной самым простейшим способом.