IIYAMA

That was already a given, all Lua executions are on a single core afaik. If you know which resource is responsible, then through manually debugging: - Enable/disable code - Tracing chains of function calls - Measuring execution times = getTickCount() - Check meta-tables, that have functions attached to them. - Check for functions that are suppose to be a-sync. - Check the amount of timers (they are CPU hungry), if you use too many, stack them. And use passive timers where possible. You can also measure function executions, maybe you find something there: addDebugHook( "preFunction", onPreFunction) https://wiki.multitheftauto.com/wiki/AddDebugHook

You could check if there is a player who thinks it is funny to spam a command, so that your server starts to lag (no joke, when no limit is applied, it is an absolute vulnerability.): https://wiki.multitheftauto.com/wiki/OnPlayerCommand You could rent another VPS and see if that one performs better. Since it is a VPS and not a dedicated server, you will not be able to monitor the global statistics. If your neighbour uses a lot of data,CPU etc., you might not be able to notice that through your own server statistics, while still receiving bad performance.

Database Are all database requests a-synced? < (check that) Experiment with indexes: https://www.youtube.com/watch?v=uyLy462Fmk8 At limits for search queries: LIMIT 1 triggerClientEvent - personalize the data Combine those related to the group system and only trigger over 1 event name. Combine all triggered events that are executed within 1 function -> In that 1 event, you can give all kinds of instructions that have to be done with the group system. You probably have to create a new file for how that is going to work.

The database can also be an factor. Which fields have you already optimised through applying indexes?

What is the quantity? You can queue it (buffering it). ------------------------ Is there a request? Wait 0,3/0.5 seconds + put the requests in a table. Then send it. While putting it in the table, make sure to only send the latest groups-list to each player.

Something like this: (untested) local eventUsage = {} function onPreEvent( sourceResource, eventName, eventSource, eventClient, luaFilename, luaLineNumber, ... ) local args = { ... } local srctype = eventSource and getElementType(eventSource) local resname = sourceResource and getResourceName(sourceResource) local plrname = eventClient and getPlayerName(eventClient) if not eventUsage[eventName] then eventUsage[eventName] = {} end eventUsage[eventName][#eventUsage[eventName] + 1] = "preEvent" .. " " .. tostring(resname) .. " " .. tostring(eventName) .. " source:" .. tostring(srctype) .. " player:" .. tostring(plrname) .. " file:" .. tostring(luaFilename) .. "(" .. tostring(luaLineNumber) .. ")" .. " numArgs:" .. tostring(#args) .. " arg1:" .. tostring(args[1]); end addDebugHook( "preEvent", onPreEvent ) setTimer(function () { local eventUsageSorted = {} for eventName, eventData in pairs (eventUsage) do eventUsageSorted[#eventUsageSorted + 1] = {eventName = eventName, eventData = eventData} end table.sort(eventUsageSorted, function(a, b) return #a.eventData > #b.eventData end) iprint("1 = ", eventUsageSorted[1].eventName, "\n2 = ",eventUsageSorted[2].eventName, "\n3 = ", eventUsageSorted[3].eventName) eventUsage = {} }, 60000, 0) https://wiki.multitheftauto.com/wiki/AddDebugHook

Caching on clientside is important, that way serverside doesn't have to send data twice or send large amount of data. Yes, it takes longer to send the data and therefore other messages have to wait longer. (like opening a panel)

Have you considered to send only the groupID and let the client remove the data by itself?

Some data doesn't have to be updated every time. Like: playTime Server sends it to the client 1x (or maybe once per 30 mins). Then each client keeps per player the following data: { [player] = { serverPlayTime = 1453436465, clientPlayTimeStart = getTickCount() } } With that, at any moment the client can compute the playTime of itself and other players, without the need of a continuous synchronization rate with the server. local playTime = serverPlayTime + (getTickCount() - clientPlayTimeStart) There might occur some small differences over an amount of time (0.1 > 1 seconds ???), because the operation and execution time may differ: client VS server But that is just a little sacrifice for an enormous performance boost. This can also be applied to values like: "hunger", "time cycles", "health restore". (some values require a correction from serverside) Every update that has a continuous value change without randomization, can be optimised like that.

- It requires a lot of management. - Missing documentation, examples and benchmarks. (So I can't you all of them yet, but maybe you can give them to us by trying the functions out) You probably have to unsubscribe all the other players to make that work.

Using triggerClientEvent/triggerServerEvent instead of elementdata doesn't reduce network usage while using them the exact same way. In some cases it will be come worse or it might also improve depending on the context. trigger(Client/Server)Event is like an 1 way trip. That starts at 1 side and stops at 1 side. This trip uses more data than element data, for each client and server. But when some clients are excluded from this trip, data reduction can occur. Like triggerServerEvent(1 client to server) or triggerClientEvent(send to a % of clients, instead of all) When using elementData, you are enhancing an element with a specific property. The best practice of using this is to inform all clients about this specific property. This trip uses less data than trigger(client/server)Event, for each client and server. Before the latest update there was no data reduction possible, now there is: https://wiki.multitheftauto.com/wiki/AddElementDataSubscriber Before the addElementDataSubscriber, we had no way to stop the data from spreading to all clients and server. Each time the data was set on either side, all clients and the server were busy receive and process the data. It has a benefit of auto sharing the information new joiners. (this can also be seen as a downside) Nice to know, but it is not just picking the right tool for the right job. You need to reduce your data rate. A double player count shouldn't double the activity of the triggerClientEvent function. The data may scale, but the rate should remain the same.

There is. You can add a debug hook. https://wiki.multitheftauto.com/wiki/AddDebugHook This can be used to monitor the activity of MTA functions and events. Attach the hook to (in the voice resource): https://wiki.multitheftauto.com/wiki/SetPlayerVoiceBroadcastTo https://wiki.multitheftauto.com/wiki/SetPlayerVoiceIgnoreFrom Monitor the activity of all functions every 1min. Then log the result and restart counting. Do this for 30 mins. If the activity is for example around than 100 (per 1 min). Then you need to monitor a bit more. If the activity is higher than 1000 (per 1 min), you know something is wrong. Your developer must be able to do this.

ah sorry, I forgot to reply to your previous topic. It is not very complex to test that assumption, just disable voice and check if the problem still occurs. (fastest way would be out-comment all export functions in the meta.xml of the voice resource, you will see a lot of errors, but it will do it's job) <!-- --> --- If your assumption is correct, then still that doesn't mean that the resource is fully responsible. Since voice is just an API, that receive instructions from another resource. That will be a second objective in that case.

Please ask for support in your language section, for a higher chance of success. (because of language barrier) https://forum.multitheftauto.com/forum/94-other-languages/ Topic locked

no, each resource has it's own unique environment. But you can use export functions to retrieve variable values from other resources. https://wiki.multitheftauto.com/wiki/Call Keep in mind that: Tables are deep-copied. (loaded) Functions can't be past over. There is also elementdata, that can be act as an in-between storage place, but that has the same restrictions as exports.

Every line of code can be validated, if it does what it is suppose to do. By only looking at the end result will only give you one type of answer, which is: success or failure. Note, this ain't a lecture. But telling me that something isn't working, without actually trying to figure out what went wrong through various debug techniques doesn't sit right with me. I know that it can be a pain to debug everything (that ain't death staring at a debug console), but now it feels more like unwillingness. Please learn it, for your own sake.

In that case, swap these 2 lines: setTimer(function() local thePlayer = source local thePlayer = source setTimer(function() And then start working on the other functions. Like this one: function JAIL(thePlayer,commandName,sendToName,ido,...) And add a debug command: addCommandHandler("idozito", function () iprint("idozito:",idozito) end) So that you can monitor your table: idozito

Removing code is not the same as fixing code. You need to fix your first iteration.

This is still old. Source is not available in async functions (created by setTimer). Therefore you need to redefine it before using the async functions. local thePlayer = source There is no timer saved here.

You can also use the account (pointer) or accountName instead. You may have tried it, but it seems like you didn't do it correctly. Try to use the accountName (since it seems you are using that) and if it doesn't work, post the code again with the changes.

Save(and load) it based on serial. idozito[toPlayer] = setTimer(function() idozito[getPlayerSerial(toPlayer)] = setTimer(function()

There is no global Lua environment afaik, atleast not that I am aware of. Each resource has it's own environment. But that doesn't mean a resource can't get information through http. If you want MTA to native support custom Lua env. variables, you probably need to create a module or modify MTA itself.

Just use the config file. https://wiki.multitheftauto.com/wiki/GetResourceConfig While the syntax might be different, it's goal is exactly the same.

That is because the `return` keyword stops the whole function. You are currently executing the following code, while I left most of the details out of it. How many times do you think this loop will run? (no matter what outcome of math.random is) for i=1, 1000 do if math.random(2) == 1 then return true else return false end end A : 1000 times B : 0 times C : 1 time Try to move the NOT state (as in no team has been found), after the loop. --[[ ... ]] local thePlayer = source for _, v in pairs(teams) do if teamName == v[1] then setTimer(function() spawnPlayer(thePlayer ,v[2],v[3],v[4],v[5],v[6],0,0,playerTeam) giveWeapon(thePlayer , v[7],ammo,false) giveWeapon(thePlayer , v[8],ammo,false) giveWeapon(thePlayer , v[9],ammo,false) end,2000,1) return -- this stops the whole function... end end setTimer(function() spawnPlayer(thePlayer,guestSpawns[num][1],guestSpawns[num][2],guestSpawns[num][3],guestSpawns[num][4],guestSpawns[num][5],0,0,playerTeam) end,2000,1) --[[ ... ]] By the way, this is just 1 out of many solutions.

Use a table, so that you can separate player data. And if you do not know how to work with a table, then go watch table tutorials on Youtube. local allPlayerData = {} addEventHandler("onPlayerJoin", root, function () allPlayerData[source] = {} -- initial state end) addEventHandler("onPlayerQuit", root, function () allPlayerData[source] = nil end, true, "low") local box = createObject(1271, x, y, z) allPlayerData[player]["box"] = box -- save local box = allPlayerData[player]["box"] -- load