Edit: I'm sure there's a good reason for this, but why exactly do you send all details of all server bans to people with access to the xgui bans menu when they join? Surely it would make more sense to send the information when they request it - i.e. when they open the bans menu?
I think there is a slight but noticeable lag in most cases when you receive the bandata. When you get the data on join it tends to be less noticeable since everything else is loading, and most people expect there to be some lag when they first get into a server. I have tested XGUI with a couple thousand bans before, but they didn't contain any extraneous information (just the SteamID and unban "0"), so this partly an issue that I haven't done proper testing of. (When I originally designed the ban menu I didn't really think about servers having so many bans-- I don't run a server, if you can't tell.
)
Also the banmenu is one of the things I haven't optimized extensively yet. I do have plans to change the ban menu to only display a "page" of bans at a time (25 or so), then add cool features like searching/filtering, but I haven't gotten around to it.
I'll probably make the new ban menu a priority (Well, that and getting XGUI working for Gmod13), but for filtering my idea was to allow clients to filter any fields on ban information so they can pinpoint bans they're looking for. I have two options for doing this:
1) Send all of the ban information once to the clients that have access to it, but at a slower, more reliable rate, then have all of the filter processing done client-side.
2) Have the clients send filter data to the server, the server will then process the filter and send the results back to the client.
Option 1 or 2 is better depending on how often the ban menu and the filtering tools will be used-- Theoretically, on a server with 500 bans and a filter that returns 25 results per page, if a filter is performed more than 20 times per admin per mapchange/rejoin (that includes going to additional pages of results), it will be better for the server to send all of the ban data once and then not have to do any extraneous processing. If it's performed less often than that, then it would certainly be better to have the server process the filters and send only the current page of results that the client needs.
(Actually, having typed that up and looked at it, to me it seems like the server processing of filters would be the better option, even with the rare exception that an admin goes ban-filter happy)
Either way, I believe I can fix the current problem temporarily by slowing down the chunks of bandata sent (or by changing the size of each chunk). Yes, I could send brief information about all of the bans to start with, then send the extra ban information on request when the user wants to see more details, but I have to see how everything is going to play out. And do more testing!
