Twitter / ngrpdev

Sunday, March 20, 2011

Performance Issues - Why is it a problem?

The SA-MP engine can be quite a pickle to code for now-a-days, while it's great that we have an actual engine in which allows us scripters to add our own modifications toward making a gamemode, it also puts puts a serious performance juggling act into our hands. SA-MP originally started out as Vice City Multiplayer with a small player limit, now over the years, it has transformed into more mature multiplayer modification for San Andreas that can hold up to 500 players in a single server instance.

The early days...
While it's great that we can support up to 500 players, it can be a serious problem for us because we have to be extremely careful in what we try to add in toward the server. Let me explain how sa-mp server's architecture really works here, you see the sa-mp client really doesn't process anything that we code in, therefore you might have noticed that when we do update the server, nobody really has to do anything on their end unless sa-mp updates the client and we update the server along with it. Everything is what we call server-side code meaning everything coded for the server is ran by the server. Low population servers really don't have to deal with performance issues - so they can add a lot of really neat stuff, this is what confuses people with our updates. We have to keep a sane amount of efficiency in order for all players to have a smooth lag-free experience, which is a balancing act that we have learned to take very seriously.

~50 commands per 5 seconds, scary!
Let me paint a picture in simple words, imagine single-player gta:sa - with all the variables and logic for just a single person doing a mission, it is at a scale that 1 single server is running that single player 500 times at the same time. Modern MMOs get to use a combination of server-side code and client-side code, also Modern MMos use multiple load balancing servers in order to deliver that crisp smooth experience. We are reaching a point where technical limits are being tested - and if we don't watch out we will lose very quickly. We would much rather have a lag-free environment than a bunch of over-elaborate things that most likely can be RP'd out without needing it.

Let's face it, more players equal more server load, we are never going to have everyone with low pings as if the server was filled with 30 players when we have 300+, the law of physics and technical limits wouldn't exactly allow that with sa-mp. Another thing is the SA-MP server software is single threaded, which means that it won't exactly take advantage over multi-core processors, giving us scripters another pain in the ass to deal with, which is exactly avoid cpu heavy functions that reside in looping timers or player updates.

In the past couple weeks we have been pushing a huge effort to rewrite most of the inner core of the script, to not only give it a cleaner look, but to also make it more efficient and faster when we do have a high player count. Other this weekend, we have been doing a couple of public tests to give us a better idea of what we can do to fix these lag issues. We has seemed to found the source of the problem, being a server misconfiguration and a cpu heavy timer/player update issue. We no longer believe that the cause was directly pinned to those exterior objects and audio plugin, but at this state, we believe that it might have been a direct combination of issues that were summing up to be the problem. So we are still not planning on re-adding them anytime soon. We still have a couple of things to do to fully optimize the script, but at this point, everything should be at a playable state now, thanks for your patience.


That concludes this week's insight, join us next week as we go through the upcoming planned features, such as businesses, transportation faction, etc.

- GhoulSlayeR (Director Of Scripting - Next Generation Gaming, LLC)

1 comment:

  1. I have noticed a little reduction in lag lately. Keep up the good work.

    ReplyDelete