ULX Lag when adding to any rank

[Jamster]

So, of recent my server has becoming increasingly laggy everytime one of my staff members adds someone to a group.

Now, the gamemode we are running is StarWarsRP on DarkRP base. This means each regiment has it's own "whitelist" in ULX. We'd rather not move to a custom whitelist system due to the need to re-add every user to their needed ranks etc. I'd like to know if there is some issue with the server or ULX as to why when adding someone to a new rank it causes server lag.

I appreciate that's confusing af but it's late, I am tired and might re-type this later.... :3

[Megiddo]

If you have a large number of users in users.txt, it will take some time to write the file. Unfortunately, we have no good news there; we have wanted to port the user and group data to SQLite, but it's not likely to happen in the near future.

I've never heard of StarWarsRP before, and I'm not sure why you need to whitelist each player. Perhaps someone in the Ulysses community can offer an alternative.

[roastchicken]

Not to be rude, but is there a specific reason you aren't going to be porting user and group data to SQLite in the near future? If it's just because of a lack of time I'd be happy to have a go at it and do a pull request.

[Megiddo]

A few reasons...

1. When we designed UCL, we never intended people to add every single user to join. I still don't see why people are doing this, though we definitely empathize that if you want to do so, ULib is not your friend. However, since a minority of users are doing this, it is not a priority change for us.
2. Time, though secondary to #1.
3. We are trying to shift efforts to ULX4. Any time spent doing this is time not spent working on ULX4 -- and because of #1, ULX4 is more important to us.

We'd definitely appreciate a code donation to do this, though it's not as straightforward as you may think. Our requirements would be the following:
1. Match our code style (in particular, no Garry'isms that break normal Lua conventions).
2. Import anything from the current users.txt and groups.txt once.
3. Able to recover from errors/misconfiguration in the database.

[JamminR]

More simply, the original ULib (and the admin mod for ULib's group access controls, ULX) was never intended for so many 'jobs' or 'teams'.
It's meant primarily for a select few special trusted people to maintain a server, act as the server's police so to speak, in a few special groups.

Unfortunately for it's design, but fortunately for fans everywhere, due to how easy ULX is to maintain custom groups and users versus the lack of understanding of many of differences between 'group' administrative control and "team/job/role" access, many use ULib far beyond it's original purpose and make (too) many groups and add (too) many users to all those groups as "jobs".

We're looking towards the future, but the challenge still remains the same.

Jamster, back more on topic to your original question, how large are your /data/ULib users.txt and groups.txt?
How many users and groups do you have?

[Jamster]

JamminR

The file sizes are as follow

Users.txt: 502.723KB
Groups.txt: 11.932KB

The total group number comes to around 53.... A lot more than I thought....

[JamminR]

As Megiddo states, the size of your users and groups file will cause lag.
Half a megabyte of users is, I think, huge.

[Jamster]

Hm.... I see...

So at current there is no way to really get around this?

I suppose then it would be smart for us to move to a dedicated whitelist system, rather than relying on the functionality of ULX for group management?

[Megiddo]

In this case, yes.

[roastchicken]

We'd definitely appreciate a code donation to do this, though it's not as straightforward as you may think. Our requirements would be the following:
1. Match our code style (in particular, no Garry'isms that break normal Lua conventions).
2. Import anything from the current users.txt and groups.txt once.
3. Able to recover from errors/misconfiguration in the database.

I can do 1 and 2 fine, as I don't use Garry's additions to lua anyways. I'm not sure exactly what you mean by recover, but at the very least I can make sure that there are no lua errors if some of the database is edited incorrectly or becomes corrupt.

[Jamster]

Welp, my question is answered

^^ Love the way you've taken this off topic again... Makes me sad 

[roastchicken]

Welp, my question is answered

^^ Love the way you've taken this off topic again... Makes me sad 

I'm sorry, I was just discussing migrating the users.txt and groups.txt to SQL which is related to this thread and is something that would probably help you.

but, ya kno, watever

[Bite That Apple]

(in particular, no Garry'isms that break normal Lua conventions).

I'm not entirely sure what you mean by that, it caught my eye though. If I take a guess, I'd say majority of the "Releases" sectiom are Garry'isms.

[roastchicken]

I'm not entirely sure what you mean by that, it caught my eye though. If I take a guess, I'd say majority of the "Releases" sectiom are Garry'isms.

Mostly operators and other stuff from C, like // comments, !=, ||, &&, etc.

[JamminR]

Mostly operators and other stuff from C, like // comments, !=, ||, &&, etc.

Yes, indeed.
From our Developers Corner "sticky" post 'Want to patch or work on a Ulysses project? Use our codestyle'

Absolutely no usage of garry's modifications to the language
This is a must. You should not use C-style comments "//" and/or "/*...*/", and you should not use the '!', '&&', '||' operators. These were all edited into the lua engine by garry, and non-standard. This means that any code written with these must be modified to work in any other project. This is simply unacceptable.

What about the binary operators '<<', '>>', and '~'? These operators actually serve a purpose and can be useful in certain situations. First, ask if it's absolutely necessary. Is there a way to do what you want another way without making the code more complicated? If the answer is no, then you can use these operators. Otherwise, find another way.