optimize Send Message to Groups by changing Client => encryptMessageForDevices by Mahdi-Ostad · Pull Request #721 · tulir/whatsmeow

Mahdi-Ostad · 2024-12-26T18:14:33Z

hello there
thank you for the library
we are using it on a project of ours with currently about 150 clients. Sending message in them had gotten extremely slow, especially in large groups, so I performed some changes on it to improve the speed. I decided to use some of those changes in the main library as well, in case someone was having the same issue. the changes are as following:

increased send message performance by collecting all neccessary device sessions and keys related to the message encryption and storing them into a cache, then storing them all into the db at once to minimize I/O to the database

…e sessions and keys related to the message encryption and storing them into a cache, then storing them all into the db at once to minimize I/O to the database

HoshenKadosh · 2025-02-08T10:12:22Z

@tulir can this be merged please?

devlikepro

The solution likely will solve the issue, but the price we'll have to pay later on maintenance with that code is too much, IMO.

If we could hide all "caches" inside the Store (so the caller encryptMessageForDevices doesn't care about caches and always get the final result - it'd be great! And reducing number of "caches" would also help, right now you move entities from one to another in a bit complex way.

ℹ️ It's not an official maintainer opinion, I was just passing by the PR :)

devlikepro · 2025-02-10T01:40:29Z

store/store.go

 }

+type CacheStore interface {
+	GetSessions(addresses []string) map[string][]byte


Instead of using primitives (string/byte) we should try using already defined types, like types.JID (likely there's something for Session/IdentityKeys as well)

IdentityKeys and Session types are both []byte in the code which is the reason I chose that

devlikepro · 2025-02-10T01:42:45Z

store/store.go

+	Cache         CacheStore
 	Container     DeviceContainer

 	DatabaseErrorHandler func(device *Device, action string, attemptIndex int, err error) (retry bool)
+
+	//Cache to Temporary save sessions and identity keys for faster group send
+	SessionsCache     map[string][]byte
+	IdentityKeysCache map[string][32]byte


Looks like too many Caches here, I lost the idea when we use SessionCache, when we use IdentityKeysCache and when just Cache.

Hello
Sorry for the delay, I didn't check my github in a while
So the idea of CacheStore is to a have a way that implements the method to get all the required IdentityKeys and Sessions at once
SessionsCache and IdentityCache save the result of said query. While doing it on redis will certainly improve speed, I would be forcing the implementation of the library to be dependent on that DB

devlikepro · 2025-02-10T01:43:56Z

send.go

+		cli.Store.Cache.StoreIdentityKeys(cli.Store.IdentityKeysCache)
 	}
+	//clear the cache once the encryption is done to release memory
+	clear(cli.Store.SessionsCache)


interesting that we clear cache after every call - why does it need to be available global then?

Since the I/O to the db is being used inside LoadSession and IsTrustedIdentity in store/signal.go, the check had to be made whether we already have it or not. Since both of these functions are whatsmeows implementation of another library, this was the only suitable place I could find to place it in

purpshell · 2025-02-10T06:22:48Z

I think that, like @devlikepro said, having multiple ambiguous caches isn't very sustainable.

I'd suggest you implement your own SQLStore layer that hits your own custom cache first. You can also look into other options like Redis at that point.

Nubuki-all · 2025-02-27T16:03:44Z

@tulir any chance you or any other maintainer are working on something that fixes this ?

tulir · 2025-02-27T16:05:38Z

The proper solution is updating libsignal-protocol-go as well as the sql store to use contexts, after which the code can use a native db transaction. Not planned in the near future, but will probably be added at some point

Mahdi-Ostad · 2025-02-28T09:52:29Z

I think that, like @devlikepro said, having multiple ambiguous caches isn't very sustainable.

I'd suggest you implement your own SQLStore layer that hits your own custom cache first. You can also look into other options like Redis at that point.

Hello
Sorry for the late response
I didn't want to force the library to be dependent on a DB like redis
That said, I like the idea of merging the caches into a single cache entity. beyond that do you have any suggestions that improves this approach?

Mahdi-Ostad · 2025-02-28T09:54:19Z

The proper solution is updating libsignal-protocol-go as well as the sql store to use contexts, after which the code can use a native db transaction. Not planned in the near future, but will probably be added at some point

If I'm not mistaken the approach you're suggesting is wrapping the entire process in a transaction, which wouldn't really solve the main issue which is too many I/Os to the database.
Or did I misinterpret something there?

Thank you for your response

purpshell · 2025-03-01T10:15:37Z

I think that, like @devlikepro said, having multiple ambiguous caches isn't very sustainable.
I'd suggest you implement your own SQLStore layer that hits your own custom cache first. You can also look into other options like Redis at that point.

Hello Sorry for the late response I didn't want to force the library to be dependent on a DB like redis That said, I like the idea of merging the caches into a single cache entity. beyond that do you have any suggestions that improves this approach?

I meant implementing this on your own outside of the library, in my original approach.

theeusmartins · 2025-03-24T00:52:07Z

i need this

GustavoGSA · 2025-03-25T00:55:52Z

I try this PR in my fork and o have this error

GustavoGSA · 2025-03-25T01:36:24Z

Individual mesage @http://s.whatsapp.net no working to with this PR, i send mutiples message and stop send

Mahdi-Ostad · 2025-03-30T19:20:50Z

I try this PR in my fork and o have this error

You have to share the version you're using for me to understand what's wrong in your fork
The line you have logged is 'queryValues += ","' in my fork which has no relation to the error you are displaying

GustavoGSA · 2025-03-30T19:36:53Z

I try this PR in my fork and o have this error

You have to share the version you're using for me to understand what's wrong in your fork The line you have logged is 'queryValues += ","' in my fork which has no relation to the error you are displaying

I use the current version of the main branch, I forked it and then applied this PR

GustavoGSA · 2025-06-26T01:38:43Z

I didn't understand, I forked the current version and merged this pull request and fixed all the conflicts, I didn't notice any difference, sending it to a group of 1000 people with the original version took 10s and with this PR it took 9.6s, it wasn't 1s as noted in the code.
I'm using PostgreSQL

Mahdi-Ostad added 2 commits December 26, 2024 21:40

increased send message performance by collecting all neccessary devic…

78b0603

…e sessions and keys related to the message encryption and storing them into a cache, then storing them all into the db at once to minimize I/O to the database

trim-whitespace

7d93bc8

devlikepro reviewed Feb 10, 2025

View reviewed changes

ghost approved these changes Mar 30, 2025

View reviewed changes

Merge branch 'main' into improve-sendmessage-performance

5badbde

purpshell mentioned this pull request Aug 15, 2025

perf(send): Parallelize per-device encryption for large group messages #900

Open

Uh oh!

Conversation

Mahdi-Ostad commented Dec 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HoshenKadosh commented Feb 8, 2025

Uh oh!

devlikepro left a comment

Choose a reason for hiding this comment

Uh oh!

devlikepro Feb 10, 2025

Choose a reason for hiding this comment

Uh oh!

Mahdi-Ostad Feb 28, 2025

Choose a reason for hiding this comment

Uh oh!

devlikepro Feb 10, 2025

Choose a reason for hiding this comment

Uh oh!

Mahdi-Ostad Feb 28, 2025

Choose a reason for hiding this comment

Uh oh!

devlikepro Feb 10, 2025

Choose a reason for hiding this comment

Uh oh!

Mahdi-Ostad Feb 28, 2025

Choose a reason for hiding this comment

Uh oh!

purpshell commented Feb 10, 2025

Uh oh!

Nubuki-all commented Feb 27, 2025

Uh oh!

tulir commented Feb 27, 2025

Uh oh!

Mahdi-Ostad commented Feb 28, 2025

Uh oh!

Mahdi-Ostad commented Feb 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

purpshell commented Mar 1, 2025

Uh oh!

theeusmartins commented Mar 24, 2025

Uh oh!

GustavoGSA commented Mar 25, 2025

Uh oh!

GustavoGSA commented Mar 25, 2025

Uh oh!

Mahdi-Ostad commented Mar 30, 2025

Uh oh!

GustavoGSA commented Mar 30, 2025

Uh oh!

GustavoGSA commented Jun 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

Mahdi-Ostad commented Dec 26, 2024 •

edited

Loading

Mahdi-Ostad commented Feb 28, 2025 •

edited

Loading