Поиск ищу аналог mysqlq

Сообщения
678
Реакции
56
Помог
16 раз(а)
Обратите внимание, если вы хотите заключить сделку с этим пользователем, он заблокирован
BiZaJe, разве? А как же переполнение канала клиенту при отсылке множества информации и забивания ему каналов?))) Думаю тут от начинки сервера все зависит, ибо виновник то переполнения как раз таки и является сервер. Ибо на чистом то сервере все нормально?)
Ну а так да, ответ ему дали:
1. Перебрать плагины что думаю не особо нужно хотя и важно поставить стабильные версии.
2. Сменить тупо БД на нормальную, а если возможность есть и вовсе проще использовать локальную БД. 💁‍♂️
13 Дек 2022
zhorzh78, ну зная твои плагины и что там есть против ничего не скажу, ибо в некоторых моментах в плагинах БД также имеются настройки связанные с работой с БД в плане запросов, когда и какую информацию сохранять/обновлять ну и в какой момент ее выгружать в БД. Так что как ни крутить все упирается чисто в БД. Ибо используя локальную БД сразу 90% всех трабл с БД отлетает сразу, на что она в принципе и локальная.
 
Сообщения
1,041
Реакции
206
Предупреждения
1
Помог
6 раз(а)
XyLiGaN, Ну у меня прилично так худ сообщений выходит, в чате норм да и с игроком есть пару мессаг, тоже такой варнинг получал, решил проблему киком игроков с пингом от 120 и выше
 
Сообщения
678
Реакции
56
Помог
16 раз(а)
Обратите внимание, если вы хотите заключить сделку с этим пользователем, он заблокирован
BiZaJe, ну ты проблему не решил по факту, а тупо решил избавиться от игроков с пингом выше 120мс. Эт не решение проблемы по сути даже не попытка, а чисто какой то костыль если конечно его так можно назвать хд
Если интересно можешь глянуть свой серв что и скок кушает через rescount ну и детально reslist
Мои значения rescount на скрине.
 

Вложения

Последнее редактирование:

RockTheStreet

Саппорт года
Сообщения
1,743
Реакции
344
Помог
40 раз(а)
Обратите внимание, если вы хотите заключить сделку с этим пользователем, он заблокирован
Нормально так два типа сменили тему. Сначала речь была о мускуле, теперь о переполнении канала.
 
Сообщения
1,041
Реакции
206
Предупреждения
1
Помог
6 раз(а)
RockTheStreet, Да подожди ты, сейчас ещё за 2007 год поговорим )
 
Сообщения
1,031
Реакции
827
Помог
10 раз(а)
zhorzh78, именно по такому алгоритму он и работает, при смене карты все модули выгружаются и если у мускула есть очередь он будет ждать пока все ответы не прилетят обратно не дав сменить карту, если база плохая то и ответ будет долгим и не важно асинхронные нативы юзаешь или синхронные. Проверяя наличие коннекта перед пулом не даст результата, коннект к базе будет, он просто будет долгим.

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

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

Проведи искусственные тесты с запросами со sleep во время смены карты, убедишься сам. А плагины твои я видел, ничего в них сверхественного нету, что бы это могло решить проблемы. Повторюсь просто, если не видел ты - это не значит, что не видели другие и козырять своим эго не нужно.
 
Сообщения
1,041
Реакции
206
Предупреждения
1
Помог
6 раз(а)
Javekson, Вопрос господин, можно подобное провернуть используя amxx?
Также сохранить локально , а потом выгрузить
 
Сообщения
1,031
Реакции
827
Помог
10 раз(а)
BiZaJe, костыльно можно, но зачем? Такая анамалия происходит только из-за медленной бд, проще базы поменять.

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

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

Итого мы получим кейс когда при выходе игроков запросы не сразу пойдут в базу а накопленная пачка полетит в пределах 1 коннекта, затем ждать ответ, если ответ успешен отправлять новую пачку, если нет то делать ретри через n время. По умолчанию mysql_timeout стоит в 60 секунд, это на 1 коннект, его как упомянули выше стоит уменьшить до 5-10 секунд.

Что нам это даст? Мы уже сможем отловить plugin_end так как в нем будем проверять наличие накопленных данных в массиве, когда попробуем отправить 1 пачку мы сразу поймем, если база медленная, то получим ошибку по таймауту в течение 5-10 секунд и сервер зависнет только на это время, что уже не критично чем ждать 32 * 5-10 секунд времени.

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

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

Не буду утверждать, но мне в какой то момент показалось, что если отправить 50 запросов то есть 50 коннектов, то запросы прилетают в базу не в том порядке в каком ты их отправил, возможно снизу вверх, это тоже надо проверить и в кейсе выше учесть.
 
Сообщения
1,041
Реакции
206
Предупреждения
1
Помог
6 раз(а)
Javekson, да это целый плагин со своим апи
13 Дек 2022
Javekson, Может попробовать , может что-то годное выйдет
 
Сообщения
1,031
Реакции
827
Помог
10 раз(а)
BiZaJe, для этого rest придумали ) и никаких зависаний сервера ) не зря же gmx на грип перешел в свое время ) хотя в нем тоже проблемы )
 
Сообщения
1,041
Реакции
206
Предупреждения
1
Помог
6 раз(а)
Javekson, А есть пример работы с бд на gRIP?
 
Сообщения
1,031
Реакции
827
Помог
10 раз(а)
BiZaJe, ну собственно сам gm-x пример так же от фантома есть в самой теме модуля
13 Дек 2022
BiZaJe, AmxxEasyHttp лучше юзай, там исправили багу о которой я говорил в gRIP когда половина данных просто не отправлялась на скрипт
 
Сообщения
1,041
Реакции
206
Предупреждения
1
Помог
6 раз(а)
Javekson, Так мысли в кучу соберу
Получается по такому принципу
Игровой сервер -> Веб сервер -> бд
Потом в обратном порядке и дергаем результат с веб на игровой?
 
Сообщения
1,031
Реакции
827
Помог
10 раз(а)
BiZaJe, ну да, дергать результат так же сервер - веб - бд - ответ (придет на сервер)
 
Сообщения
78
Реакции
110
Помог
4 раз(а)
проблема, например, в плагинах статистики могут быть, которые данные отправляют при disconnect, или в конце раунда, т.к. запросы начинают идти синхронно то и получается 30 игроков при 0.5 сек на запрос на игрока уже 15 секунд. А если таких плагинов пара, то уже 30 сек.
Это можно немного и плагинами самими разрулить как Javekson описал ну или костылями типа mysqlq, ну или в идеале обновлением mysql модуля. Можно конечно и не так костыльно делать, а написать свой amxx плагин, который управлять этим делом будет и дёргать его нативы, а он уже чтобы с БД коммуницировал.
 

Пользователи, просматривающие эту тему

Сейчас на форуме нет ни одного пользователя.
Сверху Снизу