Семь кругов ада одного дня хайпа (МТА и Массовый вход)

[PrototypeX]

[PrototypeX]

Disinterpreter - ОГРОМНОЕ СПАСИБО ЗА ПОМОЩЬ!

[rapgod1]

23 hours ago, AfterAll14 said:

Если у Вас все написано в таком стиле, как Вы показали - то проблема может быть в злоупотреблении setElementData. Вообще использовать setElementData с синхронизацией данных для всех игроков Я бы советовал в исключительных случаях. Это загружает CPU на сервере в экспоненциальной зависимости от кол-ва игроков.

PS. кстати, что за проект?

PPS. случаем не оно ? Если да, то у меня для Вас плохие новости касательно радара)

Что лучше использовать вместо setElementData?

[Fabervox]

@rapgod1, в элементдату, нужно отправлять то, что требует простой синхронизации между игроками. В остальном же, нужно контролировать всё ручками, передавать через triggerClientEvent и triggerServerEvent. Это то что нужно всем понимать.

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

И ладно б только скриптинг:
 

Spoiler

 

 

 

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

[PrototypeX]

4 hours ago, fabervox said:

@rapgod1, в элементдату, нужно отправлять то, что требует простой синхронизации между игроками. В остальном же, нужно контролировать всё ручками, передавать через triggerClientEvent и triggerServerEvent. Это то что нужно всем понимать.

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

И ладно б только скриптинг:
 

  Hide contents

 

 

 

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

Тобишь хранить всё в обычных переменных?

Как быть например с массивом домов, подгруженных с MySQL?

Как в клиент игроку который подошел к дому выдавать инфу об обьекте стоящим перед ним?

[PrototypeX]

Вопрос:

Если подобного рода текущая структура:

setElementData(house[houseID], "house.id", tonumber(houseInfo["id"]))
setElementData(house[houseID], "house.type", tostring(houseInfo["type"]))
.....

Изменится на: 

local houseInfo = {}
houseInfo["id"] = tonumber(houseInfo["id"])
houseInfo["type"] = tonumber(houseInfo["type"])
...
setElementData(house[houseID], "house.info", houseInfo)

Будет ли прирост быстродействия синхронизации между игроками и пикапом?

[AfterAll14]

У setElementData есть 4-й аргумент, который отвечает за синхронизацию. По умолчанию он устанавливается в true, т.е. все данные посылаются всем игрокам, это и увеличивает нагрузку. Если Вам нужно сохранить какие-то данные только в пределах сервера или клиента надо писать setElementData(element, "key", value, false). Также если нужно послать данные одному конкретному игроку - используйте triggerClientEvent. И да, лучше группировать данные кучами т.к. каждый вызов setElementData стоит процессорного времени, большие пакеты обрабатываются быстрее.

[PrototypeX]

2 hours ago, AfterAll14 said:

У setElementData есть 4-й аргумент, который отвечает за синхронизацию. По умолчанию он устанавливается в true, т.е. все данные посылаются всем игрокам, это и увеличивает нагрузку. Если Вам нужно сохранить какие-то данные только в пределах сервера или клиента надо писать setElementData(element, "key", value, false). Также если нужно послать данные одному конкретному игроку - используйте triggerClientEvent. И да, лучше группировать данные кучами т.к. каждый вызов setElementData стоит процессорного времени, большие пакеты обрабатываются быстрее.

Благодарю. Да я и так использую триггеры для обращений от пользователя к пользователю (например при предложении что то купить с клиента продавца идет триггер на сервер, формируется запрос и отсылается от сервера к покупателю триггером на клиент). Я написал сервер за три месяца, о чем жалею, что на середине разработки, когда освоился не стал переписывать часть кода, а продолжил разработку. Сейча сижу и мучаюсь, 40к строк кода впереди.

Кстати в моём случае, не так нагружался проц, как нагружались клиенты из-за большого количества синхронизируемых elementData в стриме. Благо разработчики МТА или не знаю, это луа такая - сервер не ложился а отпралял запросы в очередь.

Можете дать советы по оптимизации, что бы я дров больше не наломал? Спасибо!

Edited December 31, 2016 by PrototypeX

[Disinterpreter]

Проводить юнит-тесты на ботах.

[PrototypeX]

11 minutes ago, Disinterpreter said:

Проводить юнит-тесты на ботах.

Спасибо за подсказку.

 

Кстати. Я использую абсолютно во всех файлах (клиентских), следующий параметр в мете:

cache="false"

Это не может повлиять?

Edited December 31, 2016 by PrototypeX

[PrototypeX]

Тест на ботах нагруженных элементдатой не дал результатов:

    local peds = {}
    for i = 1, 140 do
        local x = -2324.0505 + math.random(0,30)
        local y = -1652.8665 + math.random(0,30)
        peds[i] = createPed(math.random(0,200), x, y, 484.6073)
        exports.npc_hlc:enableHLCForNPC(peds[i], "walk")
        local walkX = x - math.random(0,60)
        local walkY = y - math.random(0,60)
        exports.npc_hlc:setNPCTask(peds[i], {"walkToPos", walkX, walkY, 484.6073, 1})
        setElementData(peds[i], "dog.name", tostring(math.random(0, 99999)))
        for j = 1, 25 do
            setElementData(peds[i], "info"..tostring(j), tostring(math.random(0, 99999)))
        end
        local blip = createBlip(x, y, 484.6073, 0, 5, 51, 255, 102)
        setElementData(blip, 'blipIcon', 'player')
    end

При таком раскладе, при нахождении рядом с ботами, все операции проходят моментально.

 

Edited December 31, 2016 by PrototypeX

[Fabervox]

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

Обращение из одной части в другую, занимает время и ресурсы. В этом проблема БД. И тут общий совет, для высокой нагрузки, нужно стараться что-бы такого общения не было. Т.е. грубо говоря есть бд, lua-машина,ядро мта, движок игры, шейдеры, вот тяжелые задачи, должны выполняться в большей мере в одной части. Совет конечно не идеальный, но если не проводить тестирование различных вариантов, лучше ему следовать.

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

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

Элементдата, создает нагрузку при наличии большого количества клиентов, поэтому нужно обеспечить наличие клиентов. И делать надо то что надо, а не то что приспичило. Вон у вас с бензином судя по perfomancebrowser проблемы. Это значит что нужно взять чистый мод, вообще без всего, протестировать нагрузку самого hlс, затем протестировать нагрузку с бензином, при тех же самых задачах npc. При этом клиентов(это могут быть не только игроки, а к примеру в виртуалках запущенные мта), нужно не так уж и много, где-то 10-30 человек. Вот видя нагрузку, постарайтесь добиться лучших показателей.

Если же речь о стресс-тестировании, то тут стоит просто в предыдущее, добавить ограничение мощности. Можно просто ограничить серверу, а можно создать постоянную нагрузку, на уязвимый элемент, вероятно элементдата в данном случае. Соответственно смотреть просто npc, npc+нагрузка и затем уже добавить и сам тестируемый ресурс.