Any tip for optimizing DarkRP?

I managed to open 60++ ppl DarkRP server with vanila DarkRP with few addons and the lag and fps drop is really painful. like I used to get 140+ FPS in sandbox 90+ FPS in NutScript on certain RP map but in DarkRP, I’m only getting like 14 fps in 20 ppl on my screen.

Also Massive crashing and joining crashing- sigh

The Network part is pretty suspicious for me right now (suspected for freezing server like 1-5 secs), If you know the problem (please give me constructive problem) of DarkRP, let me know.

Set tickrate 33, install dbugr and look what needs to be optimized

I think DarkRP needs a general remake.
It’s my personal opinion, but let’s think about it:
-FPtje and others started working on it when they were less experienced
-GMod had less functions, was generaly more poor
-It was only getting updated to the newer functions, but not expanded in any way

I thought darkrp was just remade a few months back, making darkrp 2.4.3 or something

I don’t really think he remade it, he could aswell just rename functions, variables and move them to separate files (libraries).

If I recall correctly major of the lag I experienced in the past was related to networking and the draw library. Probably because they were called so often.

Well I see DarkRP is sending RAW Player Data Table via net message without any compression/serialize.

:V

Pull requests and/or tips to improve are welcome.

Much of the slowness can be from FPP. FPP has thise one timer that runs every 0.1 seconds that slows everything down, especially with a lot of players.
There’s a faster version of it on github. It’s on the “faster” branch. Please test it for bugs. If it works well I’ll merge it with master and DarkRP.

To install, install DarkRPMod and disable FPP in the disabled_defaults.lua file.
Then install FPP from the faster branch into addons.

[editline]25th May 2014[/editline]

This is too simplified. Over the years I’ve optimised a lot of DarkRP.
e.g. recent commits containing the word “fast”:


$ git log --grep=fast
commit 379a5ace2767690990c0a81ea4bae76cd2c9e81f
Author: FPtje <fpeijnenburg@gmail.com>
Date:   Mon Dec 30 08:51:20 2013 +0000

    Made flammable props system a lot faster. This might save quite a bit of lag on a server!

commit 578b36c9583246ff4af329841a8698d62ef87fa0
Author: FPtje <fpeijnenburg@gmail.com>
Date:   Sun Dec 22 10:36:14 2013 +0100

    Made agendas faster, also stopped information leak on agendas

commit 9de229756d27b393aa95bd94d9c4ab7f8e0165d2
Author: Bo Anderson <bo@toxicflames.co.uk>
Date:   Sat Sep 7 22:01:07 2013 +0100

    Made the HungerMod HUD a bit faster.

commit 90bc71cc87f89b2241dc747828d7b3a648b32053
Author: FPtje <fpeijnenburg@gmail.com>
Date:   Tue May 21 19:55:26 2013 +0200

    Made HUD a bit faster


Simple != Fast

Link please, sounds about as handy as Robot’s entity inspector.

Please minimize/cache use of UniqueID as it’s slow, you still use it a lot.

[editline]25th May 2014[/editline]

Dbugr causes random freezes each 10 seconds, use it only on test server.

https://www.google.com/#q=site:facepunch.com+dbugr

Anyone know what causes net loss?

I don’t know what you’re talking about, but I meant that his explanation of DarkRP why DarkRP is oversimplified and wrong.

[editline]25th May 2014[/editline]

ply:UniqueID is only used in the database and occasionally when creating timers. The only time it might be called often is in ent:CPPIGetOwner. I can’t remove the :UniqueID there because it would be against the standard.

I don’t think it’s worth caching and I highly doubt it plays a major role in DarkRP being slow. I’m going to ask Pantho to tell us about his experience with the FPP faster branch.

[editline]25th May 2014[/editline]

Pantho’s opinion:

Note: He’s running a custom version of DarkRP based on 2.4.3

Used Dbugr on a live server for 40 hours, no issues? I put it on for 1 session till it crashed for live testing.

Also, I had no idea UniqueID didn’t cache and I use it for my statistic system so threw this in.

[LUA]
function plymeta:UniqueID()
if not self.UIDCache then self.UIDCache = util.CRC( “gm_”…self:SteamID()…"_gm" ) end
return self.UIDCache
end
[/LUA]

Should cut down on that right?

DBugR does have large issues with the way data’s handled. I only really noticed later that I stored it in a very bad way and it meant data (that is, recorded data from profilers) was a lot larger than it needed to be with a lot of repeated text (dictionary based compression gave me a 97% ratio).

Because data was networked to clients, it had very adverse effects on servers. Over time or during spikes of data it could cause clients (all of them) to disconnect because of buffer overflows.

Up until recently, file logging was on by default as well, which meant it would write up to 1mb of data every 30seconds (size depends on how much is profiled), which had very bad performance effects too.

It was too late to change any of that after I noticed, so it needs to be redone. Anyway; it parses DBugR’s effects out, so you can still tell what’s causing performance issues without DBugR itself saturating the results.

On topic:

FPP is the cause of ~70% of DarkRP’s lag issues (not sure if it still does, but it used to run traces serverside for every player every x milliseconds on every player to find out what prop they were looking at, it’d then network that prop to them). It’s also important to remember source is single threaded, so high end CPU’s are pretty much required. VPS’s tend to have fairly slow CPU speeds in single cores.

Can you look into constraints check in faster branch? I can copy printers using that hydraulic right click exploit.

If I were to do this, would any of my data from the original FPP installation (included in DarkRP) be lost? I’d really like to not have to do toolgun restrictions and model blocking again.

No, they’re stored in sql.

Does SteamID64 cache?