Инициализация "большого" объекта.

[Xupypr]

День добрый. Вероятно не в ту ветку пишу, поправьте если что.

Сложновато парой слов сформулировать вопрос, попробую описать.

Предыстория. Пишем игру.

Есть объект, описывающий параметры игрока, его вещи и прочие радости, есть методы для работы с ними.

В начале скрипта идет его инициализация, т.е. забиваются все параметры игрока из базы + происходит перерасчет этих параметров в зависимости от скилов и прочих модификаций.

Отсюда вопрос, как можно это дело ускорить? Реально ли хранить уже съинициализированный объект до тех пор, пока игрок находится онлайн? Плотно используем memcache но записывать всю структуру объекта как-от не хочется. А хранить значения каждого параметра можно, но их весьма и весьма немало.

до 200-400 человек онлайн вполне нормально работает, а вот на большее количество уже начинает грузить сильно базу. Да и в базе записей сотнями тысяч.

Вообщем-то есть ли какие-то способы хранения объекта для его использования при дальнейших запросах?

 

[craz]

может noSQL, не думали?

 

[Xupypr]

Была идея хранения структуры в памяти на memcache (написать класс для работы с ним как с базой), но это потребовало б переписать огромную кучу уже работающего кода ( Первоначально архитектуру нормально не создали, теперь мучаемся. Пытаемся извратится с тем что есть.

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

 

[craz]

Была идея хранения структуры в памяти на memcache (написать класс для работы с ним как с базой), но это потребовало б переписать огромную кучу уже работающего кода ( Первоначально архитектуру нормально не создали, теперь мучаемся. Пытаемся извратится с тем что есть.

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

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

А ваще щас HraK придет разрулит ваш хайлоад)

 

[Xupypr]

json хорошо конечно, но клиент работает в XML... а хранить в базе, потом в json, потом для клиента в XML переделывать тоже путь не из оптимальных ))

 

[HraKK]

А что тут разруливать, Lazy initialize, детерминирование и мемкеш данных. Или громадить костыли.

Хотя не ясно, почему в текущем даже состоянии нельзя на модели юзера посадить мемкеш?

 

[AmdY]

serialize, __sleep, __wakeup

 

[craz]

json хорошо конечно, но клиент работает в XML... а хранить в базе, потом в json, потом для клиента в XML переделывать тоже путь не из оптимальных ))

клиент тоже перевести на json, не?(flash скорее всего?) и json надо не в базе хранить...

 

[HraKK]

Лучше уж тогда на amf, мы на нем работаем, и игра на 20 млн юзеров свободно летает.

 

[Xupypr]

А что тут разруливать, Lazy initialize, детерминирование и мемкеш данных. Или громадить костыли.

Отложенная инициализация есть. При авторизации запускается инициализация объекта, результат пишется в кэш. В Это время подгружаются нужные клиенту ресурсы, после их подгрузки клиент уже забирает готовый результат.

Хотя не ясно, почему в текущем даже состоянии нельзя на модели юзера посадить мемкеш?

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

 

[HraKK]

Разбить на части юзера.
Параметры, вещи и т.д.
При изменении какого-то, обновлять только то что изменилось и сразу же класть в кеш. Зачем в конце.

 

[Xupypr]

хорошо, спасибо, попробуем. Вообщем-то верной дорогой идем к оптимизации.
про AMF спасибо, начал читать про него.
Нашел класс AMFPHP, как я понимаю через него работать с ним?

 

[HraKK]

Через что хотите) можете через него.

 

[Xupypr]

HraKK Позвольте небольшой offtop... вопросец как разработчику игры. Как вы организовывали хранение вещей и умений игроков? у нас в данный момент все в таблице примерно с такой структурой:
id пользователя, id вещи (ссылка на таблицу с описанием вещи), тип (определяет что это вещь или умение), количество (для вещей)

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

Есть мысль перейти на 1 пользователь 1 запись, но как хранить данные?
Есть 2 мысли:
1) строка с id вещей + количество c разделителями, например '1-10|2-132|3-215....'
2) XML

 

[HraKK]

Я не разработчик игр, я как тот татар. мне все равно что писать))) Сказали писать игру, пишу.

Чем Вам не нравиться

куча записей в таблице.

?

 

[Xupypr]

Не нравится тем, что большая нагрузка на таблицу при вытаскивании списка вещей, т.к. записей в n раз больше чем пользователей, где n=среднему количеству вещей и скилов игрока.

Индексы помогают хорошо, но всеж.

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

 

[MiksIr]

Переходите на постгрес, там есть массивы Можно (и нужно) хранить обе формы, нормальную и ненормальную. Т.е. оставлять таблицу соответствия юзер - итем, и кешировать это в таблезе юзера в виде списка. Обновлять руками или повесить тригер на таблицу соответствия. С другой стороны, если данные все-равно лежат в кеше - можно это строить и в самом объекте.

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

 

[HraKK]

Читаем Шардинг

 

[Xupypr]

Переходите на постгрес, там есть массивы

на нем и сидим )

Такие вещи, вообще-то, делаются еще до написания персовй строчки кода.

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

 

[Xupypr]

Читаем Шардинг

понято ) Будем курить тему.