Ever since I enabled encrypted metadata the Chrome extension is painfully slow, sometimes taking 2 - 3 minutes to load my passwords. It’s virtually unusable at this point. I should also mention that when I open the Passbolt workspace in my browser, it’s also quite slow, though not nearly as bad as the Chrome extension. The workspace takes like 15 - 30 seconds to display my passwords. I have 3,886 passwords stored.
Thanks for creating a new thread @SoBeGuy . Can you tell us about:
- What kind of machine do you have locally (CPU/memory)?
- Is the majority of the resources shared or personal or a mix?
- What kind of key do you use (RSA3072 or 4096)?
- Do you see any error in the browser extension console?
Thank you for helping us investigate this issue.
It happens on all my Macs, for example M4 with 32 GB. 99% of the passwords are personal. My team users aren’t having any issues, I guess because they each only have a few passwords stored. The key is RSA 3072. There are no errors in the console.
That shouldn’t take that much time with these specs, can you send us a message at support@passbolt.com mentioning this thread, we can organize a call with the browser extension developers see what’s up. Cheers,
Hi everyone,
I have the same problem with the firefox plugin. 40 seconds to see my secrets for 541 secrets.
I use the community edition 5.2.0 on a vps with 16 cores and nvme disk.
Follow-up on the performance issue. With the introduction of encrypted metadata, a performance cache layer was implemented. However, it appears that this caching mechanism is not functioning correctly in your case. There could be multiple reasons for this, but the core issue is that the cached information fails validation.
The team is currently working on a fix that will make the cache mechanism self-healing when invalid data is detected. This fix is scheduled for the v5.3.x series.
In the meantime, if you need an immediate workaround, you can manually truncate the contents of the metadata_session_keys table in the database. The first connection will reinitialize the cache, and performance should improve.
Thanks for the info!
I’m now on v5.4.1 and still the same issue. This is so frustrating.
Hi Brad.
Folks who were helping are off on holiday at the moment so I’m happy to take over troubleshooting with you on the support thread if you want to dive in.
I’m sorry it’s so frustrating. Counterintuitively as this is the only case of this type I reckon we should be able to work out which part of the stack is causing this lag for you.
If you could respond to the support email with:
https://www.passbolt.com/docs/hosting/troubleshooting/logs/
- Status Report
- another browser HAR file
- CPU/Memory spikes on your client machine while the timeout is occurring
The idea is to narrow down what exactly is causing the delay. Is it AWS proxy/routing/load balancing? Is it corporate Endpoint Detection and Response (EDR) software interfering, or an incompatible browser plugin?
For such a significant lag in responsiveness something specific must be to blame.
chat soon
Gareth
I just emailed you the requested info.
1 Like
Hey!
We have same Problem… we have around 7000 entrys in our database. Server runs on a 2 core, 4gb, nvme vps. Load is very low. Clients are from i3-8100 up to ryzen 9 9800x … all with the same problem.
G’day Manuel.
How many seconds for the page to load when it’s at its worst?
Does the CPU spike to 100% when it’s blocking?
Cheers
Gareth
Hey Gareth!
it tooks about 30-45 seconds.
On Client-Site the CPU is at ~20% Load at this time (from the Passbolt extention!) whole CPU Load is at around 40% (this Client has an i7-8700t - not the fastest, but on my private Ryzen 9 9800x its the same!).
Server CPU is on the mariadb process for a small amount of seconds at around 15%.
Greetings
Manuel
Yeah Manuel that sounds very similar to Brad’s issue.
I have a current suggestion about moving the sessions to Redis that I’m testing now.
Some of our team are on holiday who are experts on the interaction with metadata and browser extensions but I will post back here with the instructions for enabling Redis once I’ve confirmed them.
I’m not saying that’s the ‘solution’ but it may alleviate the issue until a root cause can be determined.
chat soon.
Gareth
1 Like
Hey Gareth!
thanks for the fast response 
Mmmhm … its not such a big problem, we start passbolt at morning and its open for the whole day, its only on login. So take your time, and holiday is important 
Im not on a Docker installation, so i dont know if the “redis” workaound is a small “operation”?
greetings
Manuel
1 Like
Out of interest Manuel, how are you hosting passbolt?
And it’s just when it starts?
Thanks mate.
Its running on a VM on Proxmox with Debian 12 Package installation.
In front of it i have an Pangolin ReverseProxy/Tunnel (GitHub - fosrl/pangolin: Identity-Aware Tunneled Reverse Proxy Server with Dashboard UI ) Pangolin runs in the same Network as the VM, forwarding over HTTPs to the VM.
The real “problem” is only when it starts, after the “initial start” it runs fine, encryption time of passwords and other secrets are OK.
(we use passbolt CE … we had the Pro hosted, but we migrated when the 10 users gets included, we are only 3 workers that are using it the whole time!)
1 Like
WARN: It’s Sunday, I’m “not working”. If my advice breaks your toys, you get to keep both peices.
That out of the way…
Somehow I missed https://valkey.io becoming the Open Source replacement fork for Redis.
So I thought I’d take a look at implementing Valkey (Redis) in passbolt on docker as there’s a non-zero probability it solves some of the “hang time” for folks who are hitting blocking browser threads in passbolt.
(I can’t replicate the borked state )
It was really simple and worked first go so I thought I would like to share in case this helps anyone or if folks can see why this might be a Terrible Idea ™
Passbolt:passbolt/passbolt:latest-pro is Debian 12
Valkey: image: valkey/valkey:9.0-trixie is Debian 13 (but Works For Me ™)
## docker compose sections changed in my test repo
# passbolt depends on
depends_on:
- db
- keycloak
- valkey
# passbolt > environment
# Valkey sessions
CACHE_CAKECORE_CLASSNAME: Cake\Cache\Engine\RedisEngine
CACHE_CAKECORE_HOST: valkey
CACHE_CAKECORE_PORT: 6379
CACHE_CAKECORE_PASSWORD: ""
CACHE_CAKECORE_DATABASE: 0
SESSION_DEFAULTS: cache
# Valkey container
valkey:
image: valkey/valkey:9.0-trixie
container_name: valkey
restart: unless-stopped
ports:
- "6379:6379"
volumes:
- valkey_data:/data
command: valkey-server --appendonly yes
# Valkey volume
valkey_data:
name: ${COMPOSE_PROJECT_NAME}_valkey_data
If anyone with hanging errors wants to test this on your pre-prod servers, that would be 
Example compose file: github/gareth-passbolt/docker-compose.yml
Testing from Debian 12
Enable backports:
passbolt@ip-10-0-2-15:~$ sudo vi /etc/apt/sources.list.d/bookworm-backports.sources
Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: bookworm-backports
Components: main
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
$ sudo apt update && sudo apt -t bookworm-backports install valkey-server valkey-tools
Package: valkey-server
Version: 8.0.1+dfsg1-1~bpo12+1
Edit passbolt.php:
<?php
return [
...
// Add Valkey (Redis) session handling
'Session' => [
'cookie' => 'passbolt_session',
'defaults' => 'cache',
'handler' => [
'config' => 'session'
]
],
'Cache' => [
'session' => [
'className' => 'Redis',
'duration' => '+1 hours',
'path' => CACHE,
'prefix' => 'cake_session_',
'server' => 'localhost', // ← Valkey running on localhost
'port' => 6379,
'url' => env('CACHE_SESSION_URL', null),
],
],
Sanity checks
passbolt@ip-10-0-2-15:~$ valkey-cli
127.0.0.1:6379> INFO keyspace
# Keyspace
db0:keys=1,expires=1,avg_ttl=3548792
127.0.0.1:6379>
$ valkey-cli --scan --pattern 'cake_session_*' | head
cake_session_tbqsp019tsh9t76r23ssetgosl
$ valkey-cli TTL cake_session_tbqsp019tsh9t76r23ssetgosl
(integer) 3572
$ valkey-cli MEMORY USAGE cake_session_tbqsp019tsh9t76r23ssetgosl
(integer) 6224
1 Like
Sorry, i didnt saw your answer until now … ill test it in our test machine and Report back
Thank you for now!
1 Like