search

kangarko / ChatControl-Red

Issue tracker and documentation for the next generation ChatControl Red, the most advanced chat management plugin.
49 stars 23 forks source link

main server thread overloaded CMI [v. latest] #2814

Closed GG-MD closed 1 month ago

GG-MD commented 2 months ago

Are you using MySQL?

Yes

Are you using a proxy?

No

"/version ChatControlRed" - plugin version

10.27.9

Optional: Error log

-

Optional: "/chc debug" file

No response

Steps to reproduce

You recommended to me here that I use MySQL, earlier (issue). But that didn't help either, hikari cp true, using mariadb. The main problem is that you claim to be the best coding training studio. As my coder who we have been working with for many years says:

“any requests to any storage should be done from async thread. Changing the storage from files to MySql, but leaving the logic in the async stream, will not change the situation, or will change very little”

profiler: https://spark.lucko.me/gC6Z9dp6ux (/spark profiler start --only-ticks-over 135)

How long do we have to wait for the fixes? If it takes longer than 7 days, I will then leave your plugin immediately, please let me know.

image
GG-MD commented 2 months ago

It's a shit plugin. I don't recommend it to anyone. Your performance will suffer forever, the coder is crooked. Assessment I left everywhere, acquaintances will also leave, good luck.

image

new spark profiler: https://spark.lucko.me/C5JJXj8RxB

broken1arrow commented 1 month ago

Are you using MySQL?

Yes

Are you using a proxy?

No

"/version ChatControlRed" - plugin version

10.27.9

Optional: Error log

Optional: "/chc debug" file

No response

Steps to reproduce

You recommended to me here that I use MySQL, earlier (issue). But that didn't help either, hikari cp true, using mariadb. The main problem is that you claim to be the best coding training studio. As my coder who we have been working with for many years says:

“any requests to any storage should be done from async thread. Changing the storage from files to MySql, but leaving the logic in the async stream, will not change the situation, or will change very little”

profiler: https://spark.lucko.me/gC6Z9dp6ux (/spark profiler start --only-ticks-over 135)

I see, the commit from your developer clear up what you mean. I can't say exactly how he built the system around the send message, but either way when you fix the issue with the database, you did now revealed more clearly another issue (can't say if it is linked to the database or not), but it shows it is costly to send messages.

What for placeholders and text do you send with every message to player? Do you using JavaScript?

“any requests to any storage should be done from async thread. Changing the storage from files to MySql, but leaving the logic in the async stream, will not change the situation, or will change very little”

GG-MD commented 1 month ago

I see, the commit from your developer clear up what you mean. I can't say exactly how he built the system around the send message, but either way when you fix the issue with the database, you did now revealed more clearly another issue (can't say if it is linked to the database or not), but it shows it is costly to send messages. What for placeholders and text do you send with every message to player? Do you using JavaScript?

You really can't tell from the reports?! Even I understand a lot of things already. Think better if you're the developer of this shit.

Tip:

image
broken1arrow commented 1 month ago

I see, the commit from your developer clear up what you mean. I can't say exactly how he built the system around the send message, but either way when you fix the issue with the database, you did now revealed more clearly another issue (can't say if it is linked to the database or not), but it shows it is costly to send messages. What for placeholders and text do you send with every message to player? Do you using JavaScript?

You really can't tell from the reports?! Even I understand a lot of things already. Think better if you're the developer of this shit.

I'm not the developer, I just trying to understand your situation.

If I am to interpret, the problem laying in when message is sent to server. High chance when translate the raw message and all placeholders is translated to a value + JavaScript (if you use placeholders with just JavaScript) and also hex colors specially gradients is costly.

As I not the developer of this plugin, I don't know exact how he handle each part and keep in mind some placeholders can't be set async.

GG-MD commented 1 month ago

I see, the commit from your developer clear up what you mean. I can't say exactly how he built the system around the send message, but either way when you fix the issue with the database, you did now revealed more clearly another issue (can't say if it is linked to the database or not), but it shows it is costly to send messages. What for placeholders and text do you send with every message to player? Do you using JavaScript?

You really can't tell from the reports?! Even I understand a lot of things already. Think better if you're the developer of this shit.

I'm not the developer, I just trying to understand your situation.

If I am to interpret, the problem laying in when message is sent to server. High chance when translate the raw message and all placeholders is translated to a value + JavaScript (if you use placeholders with just JavaScript) and also hex colors specially gradients is costly.

As I not the developer of this plugin, I don't know exact how he handle each part and keep in mind some placeholders can't be set async.

/channel send global
 message by player, using the symbol !

zip archive plugin. https://file.io/tcaB5oJD702b

CodingWithAnxiety commented 1 month ago

I see, the commit from your developer clear up what you mean. I can't say exactly how he built the system around the send message, but either way when you fix the issue with the database, you did now revealed more clearly another issue (can't say if it is linked to the database or not), but it shows it is costly to send messages. What for placeholders and text do you send with every message to player? Do you using JavaScript?

You really can't tell from the reports?! Even I understand a lot of things already. Think better if you're the developer of this shit.

Tip: image

I've used CCRED for some time, and I've never had the performance issues you speak of.

On that note, can you please be civil, especially on the github page? I understand your frustration-- seriously, I do, but also-- there's legitimately no reason to be hostile on here, especially to another person simply trying to understand your situation.

kangarko commented 1 month ago

If it is a shit plugin then stop using it immediately.

Our database queries are async by default, and they do not show up in the new spark report.

The spart report from your initial message points to some delay in how ProtocolLib decodes the message. The easiest fix is to set Integration.ProtocolLib.Listen_For_Packets to false in settings.yml. You will lose access to the [X] feature and packet rules, all other things will remain.

In the upcoming ChatControl 11 we'll speed up the packet manipulation thanks to native Adventure support. However I can't speak for ProtocolLib, we got other reports too complaining of its performance, I might need to switch to PacketEvents or have it disabled by default.

CodingWithAnxiety commented 1 month ago

If it is a shit plugin then stop using it immediately.

Our database queries are async by default, and they do not show up in the new spark report.

The spart report from your initial message points to some delay in how ProtocolLib decodes the message. The easiest fix is to set Integration.ProtocolLib.Listen_For_Packets to false in settings.yml. You will lose access to the [X] feature and packet rules, all other things will remain.

In the upcoming ChatControl 11 we'll speed up the packet manipulation thanks to native Adventure support. However I can't speak for ProtocolLib, we got other reports too complaining of its performance, I might need to switch to PacketEvents or have it disabled by default.

I think disabled by default would be a sane default. Protocollib is something that I think only more advanced users will use. I'd like to stay, generally speaking, protocol lip integration does decrease the performance of certain events in a lot of chat programs-- this isn't a CC-red issue

GG-MD commented 1 month ago

If it is a shit plugin then stop using it immediately.

Our database queries are async by default, and they do not show up in the new spark report.

The spart report from your initial message points to some delay in how ProtocolLib decodes the message. The easiest fix is to set Integration.ProtocolLib.Listen_For_Packets to false in settings.yml. You will lose access to the [X] feature and packet rules, all other things will remain.

In the upcoming ChatControl 11 we'll speed up the packet manipulation thanks to native Adventure support. However I can't speak for ProtocolLib, we got other reports too complaining of its performance, I might need to switch to PacketEvents or have it disabled by default.

I'm glad your response is adequate, I'll check it out, thank you so much for your patience. Yes I support disabling the default, because not everyone is as clear as me for example, because my English is bad.

kangarko commented 1 month ago

No worries, let us know how it goes and if you see anything else on the spark report, please post it, I am happy to help.