Signal Desktop becomes unresponsive when sending a message #2070
Comments
|
Hi there, @Mathias-B. Sorry you're having some delays. We appreciate the partial debug log you provided, but it's not nearly enough to help us debug this issue. There should be an entry that starts with 'Sending message to' which relates to that period of time when we're trying to send the message. The other messages around that entry are important because they'll let us know what else the application is doing at the time. Thanks! |
|
Okay, thanks for the information. |
|
My girlfriend and I have the same problem. Steps to reproduce:Send 2 consecutive Messages. First message is send fast, second takes a long time. (Sometimes even the first one is slow) |
scottnonnenberg
changed the title
|
I have the same problem and I suspect this is some kind of concurrency/locking issue rather than simple resource consumption: In my experience, this happens mostly when sending two messages in quick succession, and when the receipt confirmation (double checkmark) for the previous message is not shown yet. Thus I guess this delay occurs because Signal is still waiting for some step of sending the previous message to finish. (If the recipient is in fact offline, the same thing still happens for some limited timespan even though the double checkmark for the previous message does not show up at all, so I think this is only tangentially related to the checkmark. But there is definitely some correlation.) I've also experienced the same delay when trying to send a message after having received a message a moment ago, supporting the idea that this is somehow related to the scheduling of operations while sending/receiving. |
|
@scottnonnenberg do you need any more information/debug logs? |
|
@MarcSN311 Yes, we definitely need more information. As we can't reproduce these delays on the computers we have access to, we need full debug logs from everyone reporting this. And, your help in being a detective: does slowness happen at other times? When did the slowness start happening - immediately after a new installation, or after it built up a message history? Or did you import from the Chrome app, so you started with a lot of messages? |
|
I did some testing. The long sending times seem to correlate with long conversations. In short conversations the send pre-checks take reproducible 2-10ms. In Long conversations it takes longer: This might be a consequence of #1887 |
|
I'm having this same issue for a while now (at least a couple of months, maybe longer). I've only noticed it intermittently on really large conversations, but it sometimes will hang for almost 10 seconds before a message is sent. I've uploaded two debug logs, both taken shortly after an almost 10-second delay in sending a message. Platform infoSignal version: v1.6.0 Operating System: macOS 10.13.3 Linked Device Version: iOS 11.2.6 Link to debug loghttps://gist.github.com/anonymous/0e2a9364e1d330c5e002ae361eea82cc https://gist.github.com/anonymous/c5eeb013a444aa38c444c03311870b1a |
|
@brianpcurran your log is quite long, it might be helpful if you told us the time and the last 3 digits of the receipients phone number to isolate to corresponding log messages. in your second log there is this portion: but i can't find a simmilar part in your first log. |
|
@scottnonnenberg-signal i did some further debugging: (time was reset after eacht log) |
|
@MarcSN311 Yep, and those are needed roundtrips with the database to get the latest trust state for the contacts you're about to send to. I'm not sure there's much we can do about that, aside from large-scale changes to better cache that information in memory (and update it there when things change). Would you say that your app in general is slow? We've started to see a pattern where continued heavy use of the app makes everything slower. Every database access takes longer, no matter what it's doing. |
|
@MarcSN311 I mean to mention that in both cases the ~10-second delays happened just before I generated the debug logs. |
|
Switching to long conversations (over 10k messages) is very slow (up to 20s), the shorter the conversation, the shorter loading times (down to about a second). This is on a Quadcore i7, SSD, 32GB Ram system. How about loading the trust state when opening a conversation and keeping it in memory (obviously updating it when sending/receiving a new message)? |
|
I'm in the same boat. Sending some messages causes the client to be unresponsive for ~10-20 seconds, as does simply clicking on previous conversations that have a long backlog. |
|
@rubin110 When you say 'unresponsive' you mean that you can't do anything, including opening the OS menu or switching conversations? I want to be very careful about waiting on a loading screen vs. waiting for the app to come back from a true hang. |
|
Mmm, you're right there's a difference here. After typing a message into a conversation with a long backlog and hitting enter, the text of the message will remain in the input text field, however I can still scroll through the conversation and jump over to other conversations. Similarly when clicking on a conversation with a long backlog and getting the loading triple circle throbber animation, I can still click onto other conversations without issue. |
|
What are pre-checks? Because sometimes they take OVER A MINUTE, before my messages send. Debug Log: https://debuglogs.org/a1017f840ec530e8676944218ea3b23a676182a089bb01d6227eb4ea8d693a94
` |
|
If anyone cares, here's two days-ish worth of pre-check lines grepped out of a very large debug.log https://0bin.net/paste/6IQad7O2Sdl6rJW6#HJnp4TmnTzTy1lXyfqPKensjK2eyMGI7TU8bMqIynoc |
|
@dmzpkts Thanks for that detective work! You really do have some outliers in there. First, pre-checks are a series of queries to the database to figure out if the people you're sending to are still trusted. If they take a really long time, I wonder if you're sending to really large groups? Or perhaps your database/app/computer is overloaded - can you tell me anything else about what's going on with your computer, or what has happened recently in Signal Desktop when you see those long delays? Does anything else take a long time like that? |
|
Nope. One on one messages. And no. Only in the conversation that had probably 3-4k messages in it. The slowdown was gradual and progressive as the conversation message length increased. It felt like a bell curve. It started getting exponentially worse. I ended up having to delete %appdata%\local\signal I couldnt take it anymore. It was getting worse and worse. Since doing that my messages send instantly. |
|
@dmzpkts Thanks for the follow-up. Sorry to hear that you needed to start over from scratch! But it is extremely useful for us to know that your performance characteristics changed so radically before and after. The good news is that we're making some pretty big changes to the way we store data that should help! |
|
Same issue here on Windows 10 w/Signal 1.6.1. (Though I've seen it on my Macbook as well.) Debug log: https://debuglogs.org/6a9491ec94a5a48d09eed26e1043f3cd59c887d6b8d3b9943f6fce21b7e3ea6e |
|
@dmzpkts @tfish77 Could you please provide us the size of the macOS: We are working on optimizing the database to improve the overall performance of accessing and interacting with large conversation threads. Your help is greatly appreciated. |
|
IndexedDB is 3.03GB.
Thanks.
…On Tue, Apr 3, 2018 at 12:01 PM, Daniel Gasienica ***@***.***> wrote:
@dmzpkts <https://github.com/dmzpkts> @tfish77
<https://github.com/tfish77> Could you please provide us the size of the
IndexedDB folder in your Signal profile, e.g.
macOS: ~/Library/Application Support/Signal/IndexedDB (or similar)
Windows: %appdata%\Roaming\Signal (or similar)
We are working on optimizing the database to improve the overall
performance of accessing and interacting with large conversation threads.
Your help is greatly appreciated.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2070 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AErv83m9fClR8xx4BM8C6HRI_-3B0OIgks5tk5zwgaJpZM4SSGoy>
.
--
------------------------------------------------
Trainer | Strategist | Comedian | Musician
@JordanHirsch <http://twitter.com/jordanhirsch> | http://jordanhirs.ch
THINK IMPROV <http://www.thinkimprov.com/>
|
|
@tfish77 Thanks, that’s very helpful. We are actively working on reducing the database size by moving attachments to a folder on disk instead of storing them in the database. This should make the app more robust and faster. If you’d like to try this sooner, consider installing our beta: https://github.com/signalapp/Signal-Desktop/tree/3ae17528d3dea1960eb7947922f3163e88d55087#install-the-beta |
|
Awesome, thank you for the quick reply! I'll definitely give that beta a
shot.
…On Wed, Apr 4, 2018 at 3:09 PM, Daniel Gasienica ***@***.***> wrote:
@tfish77 <https://github.com/tfish77> Thanks, that’s very helpful. We are
actively working on reducing the database size by moving attachments to a
folder on disk instead of storing them in the database. This should make
the app more robust and faster. If you’d like to try this sooner, consider
installing our beta: https://github.com/signalapp/Signal-Desktop/tree/
3ae1752#install-the-beta
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2070 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AErv85Re00M1bA39j2x6_Xy8LEedSWWYks5tlRpdgaJpZM4SSGoy>
.
--
------------------------------------------------
Trainer | Strategist | Comedian | Musician
@JordanHirsch <http://twitter.com/jordanhirsch> | http://jordanhirs.ch
THINK IMPROV <http://www.thinkimprov.com/>
|
|
With Signal beta 1.7.0-beta.3 on Debian Sid, after some amount of loading while the app launched, clicking on my conversations now is responsive and takes about ~5-7 seconds for ones with a long backlog. Typing in a message and hitting enter, it posts the message and gives me access back to the text field within a second. As stated in #2163, the process while loading didn't ever go over about 300mb of real memory or about 2.5gb of virtual. Currently idling at 225mb real, 1.86gb virtual. Do note I did just upgrade to a ThinkPad T480s with 24GB of ram, but it looks like whatever change has happened with 1.7.0-beta.3, it hardly used any of that available memory. |
|
Really looking forward to this upgrade ;) I just got a 225 meg strace to help debug, but I guess it's already solved |
|
Problem is beginning to return. |
|
@dmzpkts Thanks for letting us know. That size information is that for |
|
For what it's worth, here's where my Signal user directory currently is after running on 1.7.0-beta3 since its release: You can see what it was 21 days ago when I was running 1.7.0-beta2 here. |
|
@rubin110 Thanks for sharing. I can see that we pulled out 441MB of attachments ( Sadly, IndexedDB does not eagerly compact itself and we don’t have any mechanism / API to trigger compaction. However, we found that repeated writes to the database trigger background compaction. We are hopeful this will improve the situation with continued use of the app. In the meantime, this means disk usage for Signal will grow (as attachments are saved to disk and the database doesn’t shrink right away) in favor of better performance and stability. |
|
Sadly this does not seem to have helped the performance on mine. Here's the size information for Signal 1.7.1: Let me know what I can do to help, if anything. |
|
@frioux Please keep Signal Desktop open, since it is always moving attachments to disk in background. The more files it is able to move out of the database, the better your performance should get. |
|
Oh ok for sure! It's usually open if my laptop is on, which has to be something like 12 hours a day. I do see that there are many, many more attachments (was 1.6M, now it's 248M) so it's doing it's thing. Any idea how to know when it's done or what the progress is? |
|
@frioux If you pop open the log, you'll see log entries that start with |
|
Thanks! Looks like it's about halfway through. |
|
Wow, Signal has been running nonstop whenever my laptop's been awake since he 1.7.0-beta3 update, and it's only up to "2..." in the processedindex. Anyway I can tell Signal to just to max out on all cores and get this done sooner? |
|
@rubin110 We were very conservative in this first take on background export, just a few messages at a time. We expect that it might take ~20 minutes all at once on a big installation, so we haven't enabled the bulk export yet. But it sounds like you want it! Thanks for the feedback. |
|
Yeah I'd love the option to tell this to go quickly right before bed,
instead of it taking a whole week in the background
…--
Sent from a rotary phone rented from Ma Bell
On Wed, Apr 18, 2018, 9:55 AM Scott Nonnenberg ***@***.***> wrote:
@rubin110 <https://github.com/rubin110> We were very conservative in this
first take on background export, just a few messages at a time. We expect
that it might take ~20 minutes all at once on a big installation, so we
haven't enabled the bulk export yet. But it sounds like you want it! Thanks
for the feedback.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2070 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAf48SzUTJCV7c0ObnR08zt-f-bFyfkks5tp2_6gaJpZM4SSGoy>
.
|
|
@gasi-signal It was the indexdb folder. Going back and looking now after the most recent updates, my whole installation is down to ~611MB with 244MB in the attachments folder. IDK what changes you guys made but they seem to help.. I havent noticed any lag after hitting "enter" lately. |
|
6 days later, I'm up to |
|
About a month later...
So close. I'm also noticing Signal 1.11.0-beta.5 eating about 15% - 20% of my CPU now. |
|
Hello there, Thanks all for sharing your insights. As mentioned before the issue has been solved. I no longer encounter theses lags. 🎉 |
ghost
closed this as 
Bug description
When I type a message, then send it, it takes many seconds before the message is effectively sent.
Steps to reproduce
Actual result:
It takes severals seconds for the message to be sent.
Expected result:
The message is sent almost instantly.
Screenshots
Platform info
Signal version:
Signal v1.3.0
Operating System:
macOS 10.13.3
Linked device version:
iOS 11.2.6
Debug log
All other apps on my MacBook works well, I only get lag on this one. It really looks like a lack of performances from the ElectronJs plateforme.
Maybe I sound ridiculous but isn't it a bit odd to use this kind of stuff? I already use a web-browser on daily basis, running a lot of tabs with his engine. Dedicate another one web-browser, with his own engine, to a chat app looks overkill to me.
And I mean, my machine is already a beast: recent CPU, decent amount of RAM, PCI-e storage. Should I buy an IBM Blue Gene/P to exchange encrypted messages through internet?
Thanks in advance!
The text was updated successfully, but these errors were encountered: