предложение по оптимизации игры.
 

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

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

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

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

3. оптимизация необходимостей.
снизу под персонажем есть куча кирпичей. круто красиво бесполезно, что можно сделать. добавить на эту кучу кирпечей бутылочку востоновления бодры. человек нажимает на бутылочку она выпиваеться при наличии, что мы получим. людям не придёться заходить в инвентарь через каждые 10-15 боёв, тоже самое можно делать и с остольными часто применяемыми вне боя предметами, так же можно обеденить с пунктом номер 2 и будет вообше сказка, урежиться куча лишних запросов.

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

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

а грабить корованы?

да ещё чуток подумал есть ещё одно возможно легко реализуемое дополнительное действие.

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

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

т.е. чисто теоретически это переход из локации а в локацию а.

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

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

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

Угу, мало в Хадде отсутствия транзакций на бои, давайте еще меньше консистентности в данных:)

Тема - какой-то поток странных мыслей.
1. Инвентарь - это чтение по PK, там все быстро и просто.
2. Рунники пьют через слоты. Хотя есть аналогичная вещь, которая сделана определенно странно - кормежка таракашек. 1000 объедков скармливаются за 2000 запросов (редирект никак в браузере не срежешь) и 2.5мб трафика. Добавить кнопку "скормить все объедки" было бы здорово.
3. Быстрые слоты / авторам расширений
4. Это вообще какой-то бред, посмотри запросы, в обновлении приходит не только статы, но и другие важные вещи. Единственное что можно сделать - переделать на сокеты и пушить с сервера, без доп запросов.


Как я понимаю, основная проблема лагов - старый движок mysql, myisam, где запись вызывает лок на всю таблицу.

чтение по пк быстро да, нужно ? нет! эта мелочь не даст многово но что-то даст.
просто я более чем уверен если поуберать в определённых местах лишние действия, это привидёт к тому что сервер сможет актуально поддерживать 100 человек, на слабой серверной машинке.

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

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

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

Марис, машина в 2006-2007 держала онлайн в 2к одновременно. Тогда все качались и активности гораздо больше было и ничего особо не лагало. Как сказал Буги, проблема в том, что старый движок и куча "костылей", потому, что при внедрении новинок нужно их как-то привязать к общей БД, что порой бывает не так просто.

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

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

в 2006-2007 было меньше функционала, было меньше предметов, меньше действий, меньше таблиц и 2к одновременно это вполне возможно было как шас 20. да и видел я в в 2006-2007 игру это невозможно сравнивать с тем что есть сейчас. 1 играюший 60 уровень в 2006 накидал бы нагрузки минимум на 30 пользователей которые были тогда, даже если его кинуть назад в прошлое с текушим персонажем. т.к. по началу человек думает минут 20 делает минут 5 играет в игру совершая минимум действий, сейчас же всё достроено до автоматов, куча всяких костылей в виде Екстеншенов, которые просто е.. сервер. и люди не станут их удолять потому что тогда им будет не удобно играть.
я не говорю о разростании базы это тоже как-то нужно обробатывать. да и я более чем уверен что шас есть какой-то бектрейс пользовательских действий тогда его небыло (или был гораздо упрошёнее). тобиш взять то что есть сейчас повесить на тех 2к людей они там просто загнуться. даже с пустой базой. да и тогда даже интернет был такой что 50% онлайна были просто неактивные т.к. у них интернет не позволял быстро играть. да и тоже были проблемы даже тогда.

на самом деле тебе так кажеться : )) записываються цифорки по 4 байта локи унлоки всё это фигня база может работать если записываеться быстро, а потом начинаеться самое весёлое чтение фигня да хорошо а то что записать 4 байта даже с локами ему будет проше чем постоянно читать одни и те же текста с базы, и учитывая время я более чем уверен что там происходит что-то типо дай мне дроп, подожди какой дроп а давай закинем функцию SELECT * FROM .. LEFT JOIN .. .... ORDER BY RAND() "превед пацаны я не нагружаю чтения." если по русски. так что про чтения я не соглашусь, люди очень часто вешают на базу нагрузку которую могли бы не вешать подумав пару часиков над тем что они творят. записи легко сжать до минимума чтение гораздо сложнее.

Чето ты фигню пишешь. Локи вызывают очереди. Очереди увеличивают время записи. Время записи увеличивает время выполнения HTTP запроса, учитывая что в Хадде php, запросы выполняются не асинхронно, получаем timeout. А чтение - это просто чтение. При 200 игроках в чтение упереться сложно, ИМХО.
Сильно сомневаюсь, что дроп генерится в базе, скорее всего в php.

PS
На счет чтения и кэширования еще. Судя по всему МФы с вещей кэшируются куда-то, в persMe в main.php около wear лежит хэшик.

я ставлю на то что тут есть уйма прикольных mysql процедур функций и у mysql есть функция дай мне дроп : )). потому что это то как работали в тех годах, это то как проше работать.
если ты говориш про локи хорошо маладца давай посмотрим что будет по локам в 3 ситуациях.
1. insert into table tt (b,c,d) ('tt', 12, '12 is key field') > что сделает база заблочит тейб это вообше миг дальше закинит в конец таблички ну скажем 2-3 килобайта если всё сделано правельно даже при очень частых инсертах это не смертельно> ключь ну добавит ещё 50 байт в свои ключи. тут если много разнашорстных значений и значение падает где-то в середину и при том у него небыло раньше такого значения. может быть много памяти записано, потому что он построит это всё по возростанию. записали сняли лок всё впринципе тут не будет такого количество убер записей в идеале что-бы на 100 клиентах ламалась база данных, и покрывалась запретами, т.к. 1 запрос в среднем работает ну 200 милисикунд за 1 запрос ну максимум 20 записей, умножаем 20 * 5 = 100 записей в секунду от человека берём ещё 100 * 200 = 20 000 записей в секунду, переводим это всё в мегабайты, 3000 * 20 000 + 50 * 20 000 = 61 000 000 байт, 61 000 000 * 8 = 488 000 000 бит.

идём дальше
2.update.
тут первая стадия как правила работает с цифравыми значениями, и занимает ну 50 байт на запрос, т.к. память уже зарезервирована на стадии Insert. что у нас по ключям да тоже самое если ключи сушествуют это 50 бит если старый ключь был последний или новый он может по записям выдать больше, давай проведём прикодчную математику (и update на ключи очень редко проходит и как правило не вызывает ротацию по ключам.). 50 * 20 000 + 50 * 20 000 + 50 * 20 000 = 3 000 000 байт, 3 000 000 * 8 = 24 000 000 бит.
т.е. если чисто теоретически всё происходит примерно так то в обшем мы имеем 500 мегабит запись, при полном отсутсвии настроек mysql. обшее значение в теории сможет обеспечить 200 клиентов даже если будет висеть на жостком диске SATA 1 а это древний диск. и все локи будут быстро появляться и быстро проподать.

а вот теперь чтение.
3. 1. where clause.
ну тут всё довольно примитивно, забиваються ключи в память дёргаються постоянно (делая key level lock на запись или чтение по данному ключу пока он не закончит выборку, если нету ключа на время работы он закрывает всю табличку.).
в упдейт я писал что может пойти не так ну новый ключик появился цифорка стала выше если он падает где-то по середине.
что может пойти не так в where clause самая основная проблема это разростание таблиц допустим вы присоеденили 2-3 таблички и в одной из этих табличек 50 000 найденых записей во второй 20 000 в третей 1 (а может человек ошиьиться и будет не один не один). сколько нужно прочитать байт давай посчитаем,
4 байта ключик 50 000 * 4 + 20 000 * 4 + 1 = 280 000 байт, ну в битах можно сказать 2 мегабита, вообше нефига нету, согласен там больше математических операций. (и после каждого изменения ключа он будет снимать всё с кеша, так что вариант там есть mysql cache очень сомнительный.)

3. 2. order by clause.
тут у нас получаеться перевед медвед.
допустим в табличке 5 000 000 000 записей, (ну время прошло игра работала записывала.), отгодай сколько это выйдет в чтение ?
5 000 000 000 * на размер поля, при insert впринципе опять же будет сбиваться всё нафиг, берём теперь поле Int 4 байта
5 000 000 000 * 4 = 20 000 000 000 байта, ну я в биты даже переводить не стану тут уже понятно что жосткий не потянет без кеша. как будет работать кеш, новый инсерт относительно ключа превед у нас что-то поменялось начинаем читать всё заного, тобиш при очень большом количестве Insert кешируються только статичные таблички все динамичные работают почти в real time постоянно читая данные с жосткого диска, можно канешно построить это всё в оперативную память и будет проше, но факт останеться фактом чтения будет уйма и всё по желанию не закешируеш оперативки не хватит. так же как и в where clause работают запреты, на время пока он сортирует в нужном порядке все значения. не говоря о том что там ещё есть математическая часть которая будет опять же работать ещё дольше чем чтение с жостикх дисков.

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