I have fixed the selector in the center of the screen to deal with the scenario of when there are multiple composers open at the same time. Ideally the selector would appear next to the composer it is associated with (i.e. from which the user clicked the emoji button). However the new selector logic assumes there is only one composer open on the screen, so I’ll have to modify that logic directly to handle this issue, and right now I don’t have the time. The fixed positioning will suffice for now.
Hi!
After activation of QM Plugin performance on my forum drastically dropped…
My Discourse is installed on quite good VM 4 vCores x 2.3 GHz / 15 GB RAM / 100 GB SSD RAID Local
But still after activation of QM when few peoples are typing, all CPU’s are 100% and forum starts get really slow…
Do you know what need to be fixed/adjusted to get rid of that performance issues?
Thanks!
Yes, there are definitely optimizations that can be made here.
Keep in mind that this plugin is effectively a different front-end for the same topic-based pm system that Discourse has. I’m not surprised that it may not perform well if you are carrying on multiple conversations at once. This is not a separate pm system.
The benefit of using the same PM system as Discourse is that it allows you to switch between normal Discourse PMs and quick messages. It is not a separate chat system. If you’re after a chat system try Babble.
Every time you make a message it sends it to the server like a normal post, going through all the same processes a normal post goes through, but with a significantly simpler UI.
So, the question is where to start when optimizing this.
From my relatively un-trained perspective, here is how I think of the possibilities:
slimming down the client. Easier. I can do this and will do some.
slimming down the server. Harder. Also something I can attempt, but the result won’t be amazing.
batching on the client (probably not wise)
batching on the server (probably the best place to tackle the problem, but someone more familiar with ruby and rails should do this)
The next question is how we go about executing on one of these approaches. As mentioned, I can probably get some performance gains, but I’m hardly the most technically savvy person around here.
It depends how much it matters to you. Optimizing the performance of quickly posting PMs is not a simple problem, as you’re dealing with functionality that is core to Discourse itself.
Someone like @gdpelican or @joebuhlig could probably get significant performance improvements for a fee.
My first go at this would likely be to instantly post the message to the sending users UI and create a background job via sidekiq to create the real message that populates for other users. That way the load is handled by a single client and distributes the load on the server a bit more. Yes, there may be a lag between posts but I wouldn’t expect it to be more than a few seconds at most and would likely go unnoticed.
Im having a problem with this plugin now. To recreate I have two messages open. I respond to message A. then I respond to message B. The user on Message A replies back. That text is now in the box as me typing to Message B. When I close the box it asks if I was discard the message so it is active.
My Main menu gets hidden if I receive the message. Here is the console error.
TypeError: Cannot create property 'className' on number '1'
at i (_vendor-057c8aaf728aa3bc264d5ff93a70e003efe4f4ecdc16ba0a02d452e6e3ef4402.js:19687)
at i (_vendor-057c8aaf728aa3bc264d5ff93a70e003efe4f4ecdc16ba0a02d452e6e3ef4402.js:19527)
at t.html (_application-223b038256358c50f3c1cd8d4ed0e8484a9137cd8862a2e348d7fbe358d5b575.js:48539)
at t.p [as draw] (_application-223b038256358c50f3c1cd8d4ed0e8484a9137cd8862a2e348d7fbe358d5b575.js:52743)
at t.value (_application-223b038256358c50f3c1cd8d4ed0e8484a9137cd8862a2e348d7fbe358d5b575.js:52887)
at r (_vendor-057c8aaf728aa3bc264d5ff93a70e003efe4f4ecdc16ba0a02d452e6e3ef4402.js:19723)
at i (_vendor-057c8aaf728aa3bc264d5ff93a70e003efe4f4ecdc16ba0a02d452e6e3ef4402.js:19710)
at i (_vendor-057c8aaf728aa3bc264d5ff93a70e003efe4f4ecdc16ba0a02d452e6e3ef4402.js:19079)
at i (_vendor-057c8aaf728aa3bc264d5ff93a70e003efe4f4ecdc16ba0a02d452e6e3ef4402.js:19102)
at i (_vendor-057c8aaf728aa3bc264d5ff93a70e003efe4f4ecdc16ba0a02d452e6e3ef4402.js:19102)
Hi. Are you aware of this issue in Chrome?
The input-textfield keeps extending, but i’m typing “out of the window”, so basically i can’t see what i’m writing after line 4 in the screenshot.
I’m thinking of the possibilities to listen/use the colors from the selected theme, rather than fixed colors if it’s even possible?(assets/stylesheets/quick.scss) I have not look into this kind of solution before.
Any news regarding the theme-colors? As i know, it’s pretty easy to follow the main color-values, for a nice result.
I’m also wonder if it’s possible to add a “Open PM”-button to the quick-message window, making it possible to open up the PM in the normal view. Will you be able to make this?
As always, i really appreciate your help and plugins
Thanks so much for this @angus - just getting around to installing it now.
Not only does it work really well, but it adds that envelope icon so that I can finally get to previous message history easily!
The thing I’m noticing at the moment is that the uploading indicator (from a forum post elsewhere) is ending up in the message window. It actually posts the text from that post in there and you have to cancel the uploading waiting bar thing.
