Sending messages takes 4-8 seconds

[newhinton]

Hi Everyone!

I recently stumbled into some issues. Deploying broke the bot due to messages getting lost.
After debugging i found a timeout of 2 seconds to short for messages to be send and then getting lost.

So i started debugging, and found that my server takes considerably more time to send messages than my dev machine.

On one hand this makes sense, since the server has an i7-7700 and is quite old. But i would still expect sending messages to be a tad faster than this.

Timing yielded this:

time java -jar build/libs/signal-cli-0.13.24.jar -v send -m "This is a message" +NUMBER

2026-02-27T21:54:41.595+0100 [main] DEBUG org.asamk.signal.App - Starting signal-cli 0.13.24
2026-02-27T21:54:42.178+0100 [main] DEBUG org.asamk.signal.util.IOUtils - XDG_DATA_HOME not set, falling back to home dir
2026-02-27T21:54:42.425+0100 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Starting...
2026-02-27T21:54:42.528+0100 [main] INFO  com.zaxxer.hikari.pool.HikariPool - HikariPool-1 - Added connection org.sqlite.jdbc4.JDBC4Connection@5dcbb60
2026-02-27T21:54:42.529+0100 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Start completed.
1772225684423
2026-02-27T21:54:48.999+0100 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Shutdown initiated...
2026-02-27T21:54:49.219+0100 [main] INFO  com.zaxxer.hikari.HikariDataSource - HikariPool-1 - Shutdown completed.
2026-02-27T21:54:49.220+0100 [msl-cleanup] DEBUG o.a.s.m.s.s.MessageSendLogStore - Stopping msl cleanup thread

real    0m8.375s
user    0m5.142s
sys     0m0.376s

The entire call requires roughly 8 seconds, with starting the vm using 1. I assume the remaining 7 are taken up by the command itself.

The same call (same signal-account) on my dev-machine takes 4.4 seconds, startup ~.7 and the call roughly 3.6 seconds.

Since the bot only starts the cli in json-mode once, the startup is neglible, but sending is not.
I read through some issues, tried using urandom instead of random but that did not seem to improve the speed.

Does anyone have other ideas if i can speed up signal-cli? Would graalvm help? Does the cpu require some extensions like avx to improve speeds?
Thanks for any advice!

[newhinton]

Additionally, i have now deployed the same code to a pi 4.

The code i am using deletes 4 polls, and shows 4 polls, which takes roughly 15 seconds. The time between messages is extremely spotty.

On the pi 4, it takes roughly 4 seconds, and the timing looks extremely consistent and "feels" very fast. I cannot really explain the difference, especially since the pi should be way slower than the i7.

It would be really great if i could get better insight in what is going on.

[newhinton]

I think it got a bit faster, but still around 1 to 2 seconds.

2026-03-15T10:46:51.995+0100 [main] TRACE o.a.s.m.s.i.IdentityKeyStore - Not storing new identity for recipient ID, identity already stored
2026-03-15T10:46:53.233+0100 [main] TRACE o.a.s.m.s.sessions.SessionStore - Contains session ID.1: true (active: true)

There is quite a bit running on this server, but then again it is also an ssd and no io-warnings show up. In the case of slow io i'd expect worse results than your 3ms, but not 500 times worse :D
I might try to set up an tmpfs to rule that out.

[newhinton]

This is weird.

Instead of dealing with tmpfs, i tried moving the config-dir to the most decrepit old hdd i have attached to the server.

It is now slow, around 1-1.1 seconds, but consistently so. Even this would make it work for my bot. I'll have to experiment with different drives.

[AsamK]

Indeed, storing a few kb in an sqlite db shouldn't take that long.

[newhinton]

I have now moved the config to a "not-decades-old-relatively-new"-external harddrive, and now storing takes ~10ms. (i have seen values between 8ms and 15ms, all perfectly fine)

Moving the config-folders solves my problem with signal-cli.

It opens a lot more questions about my ssd and overall setup. Great. But entirely a me-problem :D

Thank you for your help!