Thread: amxbans 4.0
View Single Post
GIR
Junior Member
Join Date: Apr 2004
Old 04-19-2004 , 14:32  
#21

[quote="ymboc"]No the same thing doesnt happen when myself or a user spams with say messages -- My ping doesnt budge at all. Clearly you havent tested.

Really what settings did you change to test this. And what script did you use, don't tell me you did it by hand. Give me a place and time and I'll be happy to demonstrate the effects of a proper spam script. The AMX X spam filter isn't there for nothing. It's there to keep losers from spamming your server and effectively crashing it.

Quote:
Yes, I run a fairly popular server myself with several stubborn users who insist on hammering the server until they get in. No, the effect of this introduced lag isnt huge, but it is still there. It is certainly not big enough for me to stop using this lovely time-saving plugin. However, the constant denials and jabs that I must be an 'idiot' for even testing if this plugin introduces lag is *really getting old*.
I never said that, but the way you are making a huge deal out of a fly (as you have just adminitted) is annoying to say the least. As I recall from your other thread you we're about to sound the air-raid horn just because this pluguin causes lag, admittedly now you have over exadurated your claims. Thank you for waisting my time.

Although I never said you were an idiot for claiming this plugin causes lag, if I thought you were an idiot I would've never tested wether it does cause lag, but you are an idiot for exadurating and making people believe that their server is going to lag out when they install this plugin.

Quote:
Clearly you weren't paying attention when you looked at the code... You did look at the code first didnt you? I shudder to think if you just spewed info without looking for facts to back them up. The sql query executed on connect is actually more complex.
Actually the query in my plugin is a little more complex because it uses LIKE so I don't have to punch in the whole name or id.

My amx_find query:
Code:
"SELECT bid,ban_created,ban_length,ban_reason,admin_nick,admin_id,player_nick FROM amx_bans WHERE player_id LIKE '%s' OR player_nick LIKE '%s" order by ban_created desc"
As you can see I use the LIKE statement twice in my query, which is sure to be a bigger resource hog then the relatively simple connect query.

Quote:
Good for you! As I've already stated how much lag you see (if any at all) is proportional to the length taken to complete the query. In fact, it should be roughly equal to the sum of the network latency between the sql server and game server plus the length of time required to complete the query. The effect on my server is about a 10-30ms blib when someone connects - hard to notice indeed.
It sounds to me that you are trying to run a server on mediocre hardware and mediocre lines at best. My server is a Athlon XP 1800 which is more then enough to handle the extra load of this plugin and a MySQL server.

And if the effects are hard to notice then what are you complaining about? Why are you trying to convince people that this plugin causes lag? What is the whole point in stating that this plugin could cause lag when the added load of the plugin is unnoticable, or even hard to notice at best.

Quote:
I love how you decide for everyone else what is feasible or not. That just rocks! In addition, I don't believe anyone specifically asking you to do this - it was just put out there.
That's the whole point of some research. If I had concluded that infact the plugin would benefit from the multithreading then I would've implemented myself. Seeing as my conclusion is that it's not really feasible and pretty much useless, I won't do it.

I never decided anything for anybody. I just shared my conclusions with the rest of you. It's upto you to decide wether you want to believe me or not.

Quote:
I do have a couple ideas on how to do the thread business -- 'simply' start a new thread from within client_authorized(id) that performs the query and handles its outcome. However as previously mentioned, mthread is reportedly not working with amxmodx (I haven't confirmed this myself yet). Furthermore, as mentioned I do not have the time at the moment to test my ideas -- if I did I would have already put the modification out there.
I thought of that myself but the fact still remains that you can't work away the original load, the line latency and the overhead caused by spawning threads, which is the hart of this problem. HLDS already spawns a thread for every user that connects so one blocking function in the connect function of one user wouldn't cause any lag to other users unless the hardware couldn't handle the load.

Quote:
Now, I dont know about you but this spat (between you and I) and the constant denials + jabs are getting old... maybe we should put it to rest and leave it as is.
Is there a spat? I took you seriously up untill now, but seeing as you have made this into somekinda personal vendeta I won't anymore. I even investigated wether there was a remote chance of my own server not being able to handle the load of this plugin. Yes there is a chance but the scenario for that is so outragous that I won't help along in working it away. The load caused by this plugin in normal use is minimal like you've stated yourself. Only after I had a script spam the server with find queries I was able to have some noticeable lag.
GIR is offline