GMCP inducing freezing/lagginess (formerly TW testing)

Moirean

Didn't Oleis post a few weeks ago that they had coded that in? And then we fought Xiuhcoatl and noticed it was still being stupid crazy?

Daskalos

It's how GMCP handles plants. I can't brew more than about 75 brews without completely locking out. Did some testing with @Razmael and he discovered that over 9000 GMCP messages were being sent while I brewed. He said that they could probably do something backend to help fix that. I know that if I get more than about 60 single stacks of plants in my inventory, if I do INV I lockup. The GMCP data is really doing some wonky stuff. Help @Oleis \ @Razmael. 

Ishin

Holy CRAP.

Irruel

@daskalos
I assumed that 9000 figure was just a reference to Oprah.

Good to hear you chime in though; it's obviously not just mudlet.

Daskalos

The 9000 was the number from Raz :P 

Irruel

I know, I read your quote of that in another thread.
Pretty sure Raz made a joke referencing Oprah's 9000 penises.

The real number is still going to be big though.

Oleis

There are a lot of changes like this.. where you change it in one spot but Aetolia has five or six duplicated places because some goober in 2004 couldn't be arsed to write a subroutine call.

We definitely need to clean up our GMCP handling in a lot of places.

Daskalos

It seems to have gotten worse in the last month or so, if that helps. Heck, the other day I killed (Sheirosa?) and they dropped so many herbs I crashed out.

Irruel

Changed the title of the thread; seemed to make sense given people on other systems and clients are reporting it.
I'll try to catch a lesser this evening with as must gmcp stuff in TW off as possible, and see if it seems different or not.

Daskalos

Raz just messaged me and said the concoctions issue should be fixed.

Irruel

Unfortunately, I missed the lesser (by -that- much... it was over when I logged in. Maybe I'll manage another tonight, not sure, but I won't get to tomorrow. ANYWAY!

I'd like to hear whether people (of any client/system) feel it has improved after Raz's work on it today.

If anyone from TW is still seeing some slowdown, here is an easy way to disable the gmcp functions:

1. Open script editor window, search for "gmcp.Char.Items"
2. As per the attached screenshot, change the TITLE (title only) of the scripts that are hits. I just added "OFF" to the titles, but it can be anything.
   

And that is all. See if it helps.

Irruel

A new test for people.

Attached is a package with two aliases, two triggers, and a timing script. It is fully self-contained so you can use it with any mudlet system, not just tripwire or whatever.



To install it, open the package manager (alt+o in the windows build).

Click 'install', browse to the file below and install it. You do not need to unzip the file first, though you can if you wish to.



To use the package...

Alias: "Cough" (capital C required)

Alias: "I" (capital I required)

The triggers will return the time, in milliseconds, that it took to receive confirmation from Aetolia. The cough command is the baseline/control. Repeat this a few times to get a feel your your latency.

The I command checks your inventory. Repeat this a few times to see if there is a difference. Then:

outc 1000 ginseng (or whatever herb)

split ginseng into stacks of 1 (repeat until the whole stack is split into 1000)


Now repeat the "I" test. You should notice a significant increase - 2-3 times as long as the Cough is. Now try the test with debug mode on, and timestamps showing. Also, try with gmcp off (the I test with lots of split herbs still more than doubles the time for me, but is not as long as with gmcp on).



This is true for blank mudlet profiles, tripwire, serenity and avalanche (my old system). The figures to vary between them, i.e. some are worse than others, but it still shows something not so great happening server-side.

Irruel

I apologise for the poor formatting above. Maybe someday we'll get forums we don't need to type raw html into.

Nalor

@Irruel‌ if you still need help witht the GMCP.Item stuff give me a message here o in game, or tell and I'll tell you how I do it in my system... as I dont use it like he does but I still get the same outcome (without the freezing/lag)

Irruel

@Nalor‌
While TW results are definitely worse than other systems in the above test, it isn't by a huge amount. I will definitely hit you up for a lesson in efficient GMCP processing however - thanks heaps for the offer.

I suppose I should mention my results.

On a completely blank mudlet profile, with no triggers/scripts etc other than that package I attached, 1000 herbs, 270 vials, a bunch of other random inventory items AND with GMCP turned off...

"Cough" takes ~300ms
"I" takes ~650ms

Turning gmcp on increases that a little, but basically - there seems to be something on the Aetolian server side that isn't working that well.

I'm going to do more tests on a blank profile (basically, repeating the test for the gmcp portion only, not the text portion, and also testing with different quantities of inventory items, and with other people in the room) before I go to Oleis/Raz, but to me that time increase is concerning.

Nalor

@Irruel I call GMCP for precache, things in room etc etc but I do it a different way so I dont send the commands 100000 times, I send them only at certain times it might speed you up.. but the out come is the same result..

I think your issue is your sending gmcp too many times so it lags you with all the different commands/event handlers TW does...

Toz

With 1.6k moss out in individual stacks, the I command is giving me between 600 and 1k. Cough is somewhere around 110 on average.

Razmael

@Irruel‌ Most of the inventory lag should now be fixed.

Irruel

@Razmael‌
I can confirm that this is true, at least within the bounds of this test script anyway. Increasing the number of individual stacks even to ridiculous amounts has no effect at all.

Everyone else (including @Kaeus‌ )
With the above fixed, the TW results are much more stable (the results were varying rather wildly, from 700ms - 3000ms).
With 2000 unstacked slices, the test returns 600-800ms
With 4000 unstacked slices, the test returns 900-1200ms
It also sort of disconnected me a couple of times, but I don't know if that was related or just coincidence. Probably wasn't TW at any rate.

The problem?
get_room_items, get_char_items, and shrine_capture were all turned off during those test results. Turning them back on, doesn't change the results.

So unless there are more GMCP functions that I haven't found, the problem is somewhere else.
(tried with all trigs disabled, which also disables the hooks system. I also tried with the qemistry queuing system removed entirely (!tw.queue = nil at the command line). None of this affects the results.)

Lastly, to check that it isn't normal for a system to do this, I tried with the serenity and avalanche systems, and the results are good: 300-350ms for 2000 unstacked herbs.

Lim

Hey @Irruel‌:

Thank you so much for the hard work with testing.

I do experience the kind of lag that you describe.

On top of your described symptoms, it seems to get much worse for me when I use the TW queue command a lot. "q blah blah". I use that a lot for fights so that I don't send output off-balance, and do checks for the appropriate attack only when I'm ready to attack. I'm not sure if that might be a cause, or worth an investigation.

Restarting mudlet helps. Although not when the server is laggy in general/there are too many people at the lesser focus (>10 from both sides).

Thanks again!

Irruel

Thanks for the response. I mostly don't use the queue system anymore as it doesn't always fire right after I regain balance - but I'll check it out and see if it has something to do with the problem.

Moirean

I was playing with my basher and wrote one that cycles through items in the room, based on gmcp.char.items.list.items.#.id. After a bit of testing, I realized that it was basically counting my inventory as a room, so if I checked that last before the basher looped to check the next item...well. Time for a smoke break while things caught up. I talked to Oleis about this and he says it's basically a quirk of gmcp and there is a gmcp command you can send to ensure it is checking your physical room (which I promptly forgot). Unsure if that's helpful, but maybe it is. I suspect whatever your core problem is, it's not TW specific. Citadel runs some heavy gmcp stuff and lately in team fights it's gotten insanely chuggy and that chugginess persists until I restart everything. Could be new gmcp, could just be because team fights are 2-3 times as big as they used to be. Memory usage on task manager jumps up from around 20-30k to 150-200k.

Oleis

You want to ensure that gmcp.char.items.list.location == "room"

Nalor

Moirean said:

I was playing with my basher and wrote one that cycles through items in the room, based on gmcp.char.items.list.items.#.id. After a bit of testing, I realized that it was basically counting my inventory as a room, so if I checked that last before the basher looped to check the next item...well. Time for a smoke break while things caught up. I talked to Oleis about this and he says it's basically a quirk of gmcp and there is a gmcp command you can send to ensure it is checking your physical room (which I promptly forgot). Unsure if that's helpful, but maybe it is.

I suspect whatever your core problem is, it's not TW specific. Citadel runs some heavy gmcp stuff and lately in team fights it's gotten insanely chuggy and that chugginess persists until I restart everything. Could be new gmcp, could just be because team fights are 2-3 times as big as they used to be. Memory usage on task manager jumps up from around 20-30k to 150-200k.

I run GMCP in my own system and I dont lag or anything from it... So its not GMCP I have precache, basher, inv checker, etc etc all running of gmcp and a few other things and Ive not had no issues... @Moirean

Roux

Not entirely on topic, but I wasn't sure where else to address it. GMCP is causing weird feedback issues in my window. It only happens when there's an excess if items either in a room, or in my own inventory. I know that at least one other person is experiencing the same thing, but it's isolated to zMud, and the new setup on a different computer. IE: new laptop has the problem, but the old desktop doesn't despite running the same system and same version of zMud.

Below is a -small- example of what I see when it procs. It goes on and on and lists everything in my inventory or in the room like that. You can imagine what it does to go into my full stockroom.

You possess 67 items.
rackled blue and gold vial" }, { "id": "236751", "name": "a crackled blue and gold vial" }, { "id": "236816", "name": "a crackled blue and gold vial" }, { "id": "236823", "name": "a crackled blue and gold vial" }, { "id": "253162", "name": "a vial of the hunt" }, { "id": "253196", "name": "a vial of the hunt" }, { "id": "253197", "name": "a vial of the hunt" }, { "id": "253299", "name": "a vial of the hunt" }, { "id": "253383", "name": "a vial of the hunt" }, { "id": "220882", "name": "a vial of the hunt" } -etc

I thought it might be related to this lag issue people were experiencing, but considering the msg about it being fixed or addressed and no difference to me, I was wondering if anyone had any ideas on what this is or how to fix it.

Oleis

That, to me, looks like a memory management issue within zMud.

Moirean

I get that often, and randomly, but I've been getting it ever since I started using Citadel and I've not noticed that stuff in conjunction with slowdown in performance. It just seems to happen when there's a ton of input.

Irruel

Mudlet can get that if there is enough spam and MCCP is on.

Have you tried turning it off in cmud/zmud preferences?

Roux

Just did. Doesn't seem to have made a difference. I fill my inventory with herbs and then once it hits that magic number it starts showing up again. It's all the time too, not random. If it does it once, it keeps doing it every time I check ql/inventory until I either leave the location or clear out my inventory.

Daskalos

Moirean said:

I get that often, and randomly, but I've been getting it ever since I started using Citadel and I've not noticed that stuff in conjunction with slowdown in performance. It just seems to happen when there's a ton of input.

Of note, I've never, ever had that pop up, and it's not something I would of changed. Are you on the latest cmud build? (3.34?)