Performance Issues #962

New Issue

OVERLORD · 2026-02-04T23:27:30+03:00

OVERLORD commented

2026-02-04 23:27:30 +03:00

Originally created by @ncodee on GitHub (Mar 1, 2021).

Describe the Bug

When removing/adding entry on the web Vault, everything because super laggy, and unresponsive.
I have had the page completely freeze with a white screen, the only way to access the page again was to refresh it, which cancels out the current actions.

Steps To Reproduce

Delete/edit any item on the web Vault.

Expected Result

Be responsive, and not freezes the page.

Actual Result

Becomes unresponsive, and freezes.

Environment

Vault Items: 2476
Bitwarden_rs version: v1.19.0
Web-vault version: v2.18.1
Running within Docker: true
Internet access: true
Uses a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Clients used:
Reverse proxy and version:
Other relevant information:

Config (Generated via diagnostics page)

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": false,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_ip_header_enabled": true,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "/data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "/data",
  "database_max_conns": 10,
  "database_url": "/****/**.*******",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://*****.*******.***",
  "domain_origin": "*****://*****.*******.***",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 6,
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": null,
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "/data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "invitation_org_name": "Bitwarden_RS",
  "invitations_allowed": true,
  "ip_header": "X-Real-IP",
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "org_attachment_limit": null,
  "org_creation_users": "",
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "/data/rsa_key",
  "show_password_hint": true,
  "signups_allowed": true,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": null,
  "smtp_debug": false,
  "smtp_explicit_tls": false,
  "smtp_from": "",
  "smtp_from_name": "Bitwarden_RS",
  "smtp_host": null,
  "smtp_password": null,
  "smtp_port": 587,
  "smtp_ssl": true,
  "smtp_timeout": 15,
  "smtp_username": null,
  "templates_folder": "/data/templates",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": true,
  "websocket_port": 8080,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

Originally created by @ncodee on GitHub (Mar 1, 2021). ## Describe the Bug When removing/adding entry on the web Vault, everything because super laggy, and unresponsive. I have had the page completely freeze with a white screen, the only way to access the page again was to refresh it, which cancels out the current actions. ## Steps To Reproduce Delete/edit any item on the web Vault. ## Expected Result Be responsive, and not freezes the page. ## Actual Result Becomes unresponsive, and freezes. # Environment * Vault Items: 2476 * Bitwarden_rs version: v1.19.0 * Web-vault version: v2.18.1 * Running within Docker: true * Internet access: true * Uses a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": false, "_enable_smtp": true, "_enable_yubico": true, "_ip_header_enabled": true, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "/data/attachments", "authenticator_disable_time_drift": false, "data_folder": "/data", "database_max_conns": 10, "database_url": "/****/**.*******", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://*****.*******.***", "domain_origin": "*****://*****.*******.***", "domain_path": "", "domain_set": true, "duo_host": null, "duo_ikey": null, "duo_skey": null, "email_attempts_limit": 3, "email_expiration_time": 600, "email_token_size": 6, "enable_db_wal": true, "extended_logging": true, "helo_name": null, "hibp_api_key": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "/data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "invitation_org_name": "Bitwarden_RS", "invitations_allowed": true, "ip_header": "X-Real-IP", "log_file": null, "log_level": "Info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "org_attachment_limit": null, "org_creation_users": "", "password_iterations": 100000, "reload_templates": false, "require_device_email": false, "rsa_key_filename": "/data/rsa_key", "show_password_hint": true, "signups_allowed": true, "signups_domains_whitelist": "", "signups_verify": false, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": null, "smtp_debug": false, "smtp_explicit_tls": false, "smtp_from": "", "smtp_from_name": "Bitwarden_RS", "smtp_host": null, "smtp_password": null, "smtp_port": 587, "smtp_ssl": true, "smtp_timeout": 15, "smtp_username": null, "templates_folder": "/data/templates", "use_syslog": false, "user_attachment_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "websocket_address": "0.0.0.0", "websocket_enabled": true, "websocket_port": 8080, "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ````

OVERLORD added the enhancement troubleshooting low priority labels 2026-02-04 23:27:30 +03:00

OVERLORD closed this issue

2026-02-04 23:27:33 +03:00

OVERLORD commented

2026-02-04 23:27:40 +03:00

@BlackDex commented on GitHub (Mar 1, 2021):

Please supply more information preferably by using the Generate Support String from the /admin/diagnostics page.
Also provide which database you are using, how many vault items you have etc...

@BlackDex commented on GitHub (Mar 1, 2021): Please supply more information preferably by using the `Generate Support String` from the `/admin/diagnostics` page. Also provide which database you are using, how many vault items you have etc...

OVERLORD commented

2026-02-04 23:27:45 +03:00

@ncodee commented on GitHub (Mar 1, 2021):

Please supply more information preferably by using the Generate Support String from the /admin/diagnostics page.
Also provide which database you are using, how many vault items you have etc...

Updated with more info thanks, unfortuantly the button didn't generate anything.

@ncodee commented on GitHub (Mar 1, 2021): > Please supply more information preferably by using the `Generate Support String` from the `/admin/diagnostics` page. > Also provide which database you are using, how many vault items you have etc... Updated with more info thanks, unfortuantly the button didn't generate anything.

OVERLORD commented

2026-02-04 23:27:48 +03:00

@BlackDex commented on GitHub (Mar 1, 2021):

Im still missing some logs, amount of ciphers etc.. we can't do anything with this. There is nothing we can use as a point of reference.

As a side note, what was the error when trying to generate the support string?

@BlackDex commented on GitHub (Mar 1, 2021): Im still missing some logs, amount of ciphers etc.. we can't do anything with this. There is nothing we can use as a point of reference. As a side note, what was the error when trying to generate the support string?

OVERLORD commented

2026-02-04 23:27:51 +03:00

@ncodee commented on GitHub (Mar 1, 2021):

Im still missing some logs, amount of ciphers etc.. we can't do anything with this. There is nothing we can use as a point of reference.

As a side note, what was the error when trying to generate the support string?

The button didn't function for some reason, with no error. I'm not sure what the issue was, but I've now managed to generate the support string. Please have a look at the OP, thanks.

@ncodee commented on GitHub (Mar 1, 2021): > Im still missing some logs, amount of ciphers etc.. we can't do anything with this. There is nothing we can use as a point of reference. > > As a side note, what was the error when trying to generate the support string? The button didn't function for some reason, with no error. I'm not sure what the issue was, but I've now managed to generate the support string. Please have a look at the OP, thanks.

OVERLORD commented

2026-02-04 23:27:54 +03:00

@BlackDex commented on GitHub (Mar 1, 2021):

Well it all looks ok. Also don't think the amount of vault items it's very much.

Could you provide some logs when performing the actions which takes a lot of time?

docker logs 'bitwarden-container-name'
Or the bitwarden.log

@BlackDex commented on GitHub (Mar 1, 2021): Well it all looks ok. Also don't think the amount of vault items it's very much. Could you provide some logs when performing the actions which takes a lot of time? `docker logs 'bitwarden-container-name'` Or the bitwarden.log

OVERLORD commented

2026-02-04 23:27:58 +03:00

@ncodee commented on GitHub (Mar 1, 2021):

I've monitored the logs, and there's nothing unsual showing. It's weird, because the task occurs, and the page loads after a very long period of time, however the interface just becomes unresponsive/shows blank screen when you bulk delete/add entries.

I'm not sure if this is intended behaviour, but it takes an awfully long time.

The only thing the log shows is:
no .env file found. [2021-03-01 20:52:44.727][response][INFO] GET /icons/<domain>/icon.png (icon) => 404 Not Found

@ncodee commented on GitHub (Mar 1, 2021): I've monitored the logs, and there's nothing unsual showing. It's weird, because the task occurs, and the page loads after a very long period of time, however the interface just becomes unresponsive/shows blank screen when you bulk delete/add entries. I'm not sure if this is intended behaviour, but it takes an awfully long time. The only thing the log shows is: ` no .env file found. [2021-03-01 20:52:44.727][response][INFO] GET /icons/<domain>/icon.png (icon) => 404 Not Found `

OVERLORD commented

2026-02-04 23:27:59 +03:00

@BlackDex commented on GitHub (Mar 2, 2021):

I do not see log lines regarding deletion here.
But, what do you see in the developer console of the browser (F12) when executing this? At the network tab it should show you some kind of timeline or loading time.

@BlackDex commented on GitHub (Mar 2, 2021): I do not see log lines regarding deletion here. But, what do you see in the developer console of the browser (F12) when executing this? At the network tab it should show you some kind of timeline or loading time.

OVERLORD commented

2026-02-04 23:28:04 +03:00

@ncodee commented on GitHub (Mar 2, 2021):

Here's a screenshot, however I didn't manage to capture the freeze as it happens on random occassions.
With this test, I've deleted around 66 passwords from the vault.

https://i.imgur.com/HM2H0ai.png

I will try to monitor when it does hang, and will update you with the results.

Thanks

@ncodee commented on GitHub (Mar 2, 2021): Here's a screenshot, however I didn't manage to capture the freeze as it happens on random occassions. With this test, I've deleted around 66 passwords from the vault. https://i.imgur.com/HM2H0ai.png I will try to monitor when it does hang, and will update you with the results. Thanks

OVERLORD commented

2026-02-04 23:28:06 +03:00

@BlackDex commented on GitHub (Mar 2, 2021):

That image is not readable so i can't determine where to start looking.
I see something is taking long, but not what or which request.
Also these requests should be visible in the bitwarden.log and that should also help together with a readable screenshot.

@BlackDex commented on GitHub (Mar 2, 2021): That image is not readable so i can't determine where to start looking. I see something is taking long, but not what or which request. Also these requests should be visible in the bitwarden.log and that should also help together with a readable screenshot.

OVERLORD commented

2026-02-04 23:28:10 +03:00

@ncodee commented on GitHub (Mar 2, 2021):

That image is not readable so i can't determine where to start looking.
I see something is taking long, but not what or which request.
Also these requests should be visible in the bitwarden.log and that should also help together with a readable screenshot.

You should be able to view the screenshot clearly by zooming in, or do you mean it doesn't provide much info?

I'm using bitwarden_rs as an Home Assistant addon on Ubuntu, and the logs in portainer/docker/addon do not record any data to show this info. Also, I'm not able to find the bitwarden.log file, once I do I will surely attach it here.

@ncodee commented on GitHub (Mar 2, 2021): > That image is not readable so i can't determine where to start looking. > I see something is taking long, but not what or which request. > Also these requests should be visible in the bitwarden.log and that should also help together with a readable screenshot. You should be able to view the screenshot clearly by zooming in, or do you mean it doesn't provide much info? I'm using bitwarden_rs as an Home Assistant addon on Ubuntu, and the logs in portainer/docker/addon do not record any data to show this info. Also, I'm not able to find the `bitwarden.log` file, once I do I will surely attach it here.

OVERLORD commented

2026-02-04 23:28:15 +03:00

@jjlin commented on GitHub (Mar 3, 2021):

This seems unlikely to be a bitwarden_rs issue. More likely it's something about your reverse proxy or networking configuration, or the way your addon has configured that. I'd suggest you take this issue to https://github.com/hassio-addons/addon-bitwarden.

@jjlin commented on GitHub (Mar 3, 2021): This seems unlikely to be a bitwarden_rs issue. More likely it's something about your reverse proxy or networking configuration, or the way your addon has configured that. I'd suggest you take this issue to https://github.com/hassio-addons/addon-bitwarden.

OVERLORD commented

2026-02-04 23:28:21 +03:00

@bit-bat commented on GitHub (Mar 14, 2021):

Hello, I am having some performance issues as well. Here is a small chunk of logs showing the issue #

 [2021-03-13 22:10:29.862][response][INFO] GET /icons/<domain>/icon.png (icon) => 200 OK
 [2021-03-13 22:10:46.422][request][INFO] PUT /api/ciphers/6a7b2e00-b4c0-4342-8753-fb472cf14a1a/delete
 [2021-03-13 22:10:53.235][response][INFO] PUT /api/ciphers/<uuid>/delete (delete_cipher_put) => 200 OK
 [2021-03-13 22:11:43.054][request][INFO] GET /icons/10.10.1.250/icon.png

If you look at the request that started at 22:10:46, you will notice that it took about 7 seconds. This was a delete request. Sometimes update or create requests take much longer (about 20 seconds). Is this normal?

Support String:

Your environment (Generated via diagnostics page)

Bitwarden_rs version: v1.19.0
Web-vault version: v2.18.1
Running within Docker: true
Internet access: true
Uses a proxy: false
DNS Check: true
Time Check: true
Domain Configuration Check: true
HTTPS Check: true
Database type: SQLite
Clients used:
Reverse proxy and version:
Other relevant information:

Config (Generated via diagnostics page)

{
  "_duo_akey": null,
  "_enable_duo": false,
  "_enable_email_2fa": true,
  "_enable_smtp": true,
  "_enable_yubico": true,
  "_ip_header_enabled": true,
  "admin_token": "***",
  "allowed_iframe_ancestors": "",
  "attachments_folder": "data/attachments",
  "authenticator_disable_time_drift": false,
  "data_folder": "data",
  "database_max_conns": 10,
  "database_url": "****/**.*******",
  "db_connection_retries": 15,
  "disable_2fa_remember": false,
  "disable_admin_token": false,
  "disable_icon_download": false,
  "domain": "*****://***.************.***",
  "domain_origin": "*****://***.************.***",
  "domain_path": "",
  "domain_set": true,
  "duo_host": null,
  "duo_ikey": null,
  "duo_skey": null,
  "email_attempts_limit": 3,
  "email_expiration_time": 600,
  "email_token_size": 10,
  "enable_db_wal": true,
  "extended_logging": true,
  "helo_name": "*********",
  "hibp_api_key": null,
  "icon_blacklist_non_global_ips": true,
  "icon_blacklist_regex": null,
  "icon_cache_folder": "data/icon_cache",
  "icon_cache_negttl": 259200,
  "icon_cache_ttl": 2592000,
  "icon_download_timeout": 10,
  "invitation_org_name": "Bitwarden @ **********",
  "invitations_allowed": false,
  "ip_header": "X-Real-IP",
  "log_file": null,
  "log_level": "Info",
  "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f",
  "org_attachment_limit": null,
  "org_creation_users": "",
  "password_iterations": 100000,
  "reload_templates": false,
  "require_device_email": false,
  "rsa_key_filename": "data/rsa_key",
  "show_password_hint": true,
  "signups_allowed": false,
  "signups_domains_whitelist": "",
  "signups_verify": false,
  "signups_verify_resend_limit": 6,
  "signups_verify_resend_time": 3600,
  "smtp_accept_invalid_certs": false,
  "smtp_accept_invalid_hostnames": false,
  "smtp_auth_mechanism": "Plain",
  "smtp_debug": false,
  "smtp_explicit_tls": false,
  "smtp_from": "**-*****@************.***",
  "smtp_from_name": "Bitwarden @ *****",
  "smtp_host": "**.************.***",
  "smtp_password": "***",
  "smtp_port": 587,
  "smtp_ssl": true,
  "smtp_timeout": 2,
  "smtp_username": "*****@****.************.***",
  "templates_folder": "data/templates",
  "use_syslog": false,
  "user_attachment_limit": null,
  "web_vault_enabled": true,
  "web_vault_folder": "web-vault/",
  "websocket_address": "0.0.0.0",
  "websocket_enabled": false,
  "websocket_port": 3012,
  "yubico_client_id": null,
  "yubico_secret_key": null,
  "yubico_server": null
}

@bit-bat commented on GitHub (Mar 14, 2021): Hello, I am having some performance issues as well. Here is a small chunk of logs showing the issue # ``` [2021-03-13 22:10:29.862][response][INFO] GET /icons/<domain>/icon.png (icon) => 200 OK [2021-03-13 22:10:46.422][request][INFO] PUT /api/ciphers/6a7b2e00-b4c0-4342-8753-fb472cf14a1a/delete [2021-03-13 22:10:53.235][response][INFO] PUT /api/ciphers/<uuid>/delete (delete_cipher_put) => 200 OK [2021-03-13 22:11:43.054][request][INFO] GET /icons/10.10.1.250/icon.png ``` If you look at the request that started at `22:10:46`, you will notice that it took about 7 seconds. This was a delete request. Sometimes update or create requests take much longer (about 20 seconds). Is this normal? Support String: ### Your environment (Generated via diagnostics page) * Bitwarden_rs version: v1.19.0 * Web-vault version: v2.18.1 * Running within Docker: true * Internet access: true * Uses a proxy: false * DNS Check: true * Time Check: true * Domain Configuration Check: true * HTTPS Check: true * Database type: SQLite * Clients used: * Reverse proxy and version: * Other relevant information: ### Config (Generated via diagnostics page) ```json { "_duo_akey": null, "_enable_duo": false, "_enable_email_2fa": true, "_enable_smtp": true, "_enable_yubico": true, "_ip_header_enabled": true, "admin_token": "***", "allowed_iframe_ancestors": "", "attachments_folder": "data/attachments", "authenticator_disable_time_drift": false, "data_folder": "data", "database_max_conns": 10, "database_url": "****/**.*******", "db_connection_retries": 15, "disable_2fa_remember": false, "disable_admin_token": false, "disable_icon_download": false, "domain": "*****://***.************.***", "domain_origin": "*****://***.************.***", "domain_path": "", "domain_set": true, "duo_host": null, "duo_ikey": null, "duo_skey": null, "email_attempts_limit": 3, "email_expiration_time": 600, "email_token_size": 10, "enable_db_wal": true, "extended_logging": true, "helo_name": "*********", "hibp_api_key": null, "icon_blacklist_non_global_ips": true, "icon_blacklist_regex": null, "icon_cache_folder": "data/icon_cache", "icon_cache_negttl": 259200, "icon_cache_ttl": 2592000, "icon_download_timeout": 10, "invitation_org_name": "Bitwarden @ **********", "invitations_allowed": false, "ip_header": "X-Real-IP", "log_file": null, "log_level": "Info", "log_timestamp_format": "%Y-%m-%d %H:%M:%S.%3f", "org_attachment_limit": null, "org_creation_users": "", "password_iterations": 100000, "reload_templates": false, "require_device_email": false, "rsa_key_filename": "data/rsa_key", "show_password_hint": true, "signups_allowed": false, "signups_domains_whitelist": "", "signups_verify": false, "signups_verify_resend_limit": 6, "signups_verify_resend_time": 3600, "smtp_accept_invalid_certs": false, "smtp_accept_invalid_hostnames": false, "smtp_auth_mechanism": "Plain", "smtp_debug": false, "smtp_explicit_tls": false, "smtp_from": "**-*****@************.***", "smtp_from_name": "Bitwarden @ *****", "smtp_host": "**.************.***", "smtp_password": "***", "smtp_port": 587, "smtp_ssl": true, "smtp_timeout": 2, "smtp_username": "*****@****.************.***", "templates_folder": "data/templates", "use_syslog": false, "user_attachment_limit": null, "web_vault_enabled": true, "web_vault_folder": "web-vault/", "websocket_address": "0.0.0.0", "websocket_enabled": false, "websocket_port": 3012, "yubico_client_id": null, "yubico_secret_key": null, "yubico_server": null } ```

OVERLORD commented

2026-02-04 23:28:24 +03:00

@yverry commented on GitHub (Mar 18, 2021):

SQLite DB is not the best on performance side, do you reproduce on mysql/postgresql?

@yverry commented on GitHub (Mar 18, 2021): SQLite DB is not the best on performance side, do you reproduce on mysql/postgresql?

OVERLORD commented

2026-02-04 23:28:28 +03:00

@bit-bat commented on GitHub (Mar 18, 2021):

I will have to figure out how to switch to postgres. I have a postgres instance running already with other schemas, would that be a security risk, given items in Bitwarden are end to end encrypted?

@bit-bat commented on GitHub (Mar 18, 2021): I will have to figure out how to switch to postgres. I have a postgres instance running already with other schemas, would that be a security risk, given items in Bitwarden are end to end encrypted?

OVERLORD commented

2026-02-04 23:28:30 +03:00

@jjlin commented on GitHub (Mar 18, 2021):

As password managers aren't write-intensive workloads, SQLite will likely perform better than MySQL/PostgreSQL for most users.

BTW, this is not clearly a bitwarden_rs issue, so you should take this to the forums.

@jjlin commented on GitHub (Mar 18, 2021): As password managers aren't write-intensive workloads, SQLite will likely perform better than MySQL/PostgreSQL for most users. BTW, this is not clearly a bitwarden_rs issue, so you should take this to the forums.

OVERLORD commented

2026-02-04 23:28:34 +03:00

@kmahyyg commented on GitHub (Aug 13, 2021):

Another performance problem here, I met now. Cloudflare continously give me 524 error after importing hundreds of password from 1p.

After check the discussion here: https://github.com/dani-garcia/bitwarden_rs/discussions/1470

I think things are not that clear.

I changed the worker number via ENV when running with docker, the workers are limited to 4 concurrently.

However, the log reveals that The web page were trying to downloading all the favicon of the items recorded in my account, since today my server network is under a heavy load, it becomes slow, Then finally /icons/<domain>/icon.png request goes to DDoS the server.

I personally recommend two solution for my situation, either should be good:

Do not show 500 items in a page, use pagination, 100 should be good. This means there won't be such much concurrent icon request.
Give user an option to download the favicon or not.

I personally like the second one.

@jjlin @BlackDex

BTW, I'll increase the worker number and have a try.

@kmahyyg commented on GitHub (Aug 13, 2021): Another performance problem here, I met now. Cloudflare continously give me 524 error **after** importing hundreds of password from 1p. After check the discussion here: https://github.com/dani-garcia/bitwarden_rs/discussions/1470 I think things are not that clear. I changed the worker number via ENV when running with docker, the workers are limited to 4 concurrently. However, the log reveals that The web page were trying to downloading all the favicon of the items recorded in my account, since today my server network is under a heavy load, it becomes slow, Then finally `/icons/<domain>/icon.png` request goes to DDoS the server. I personally recommend two solution for my situation, either should be good: 1. Do not show 500 items in a page, use pagination, 100 should be good. This means there won't be such much concurrent icon request. 2. Give user an option to download the favicon or not. I personally like the second one. @jjlin @BlackDex BTW, I'll increase the worker number and have a try.

OVERLORD commented

2026-02-04 23:28:39 +03:00

@BlackDex commented on GitHub (Aug 13, 2021):

@kmahyyg, well the first option is something you should request at upstream bitwarden since that is a client item

And the second is already built into all the clients. You can disable icon downloading per client in your user settings.

You can also disable icon downloading on the server side, but that does not prevent the client from downloading.

@BlackDex commented on GitHub (Aug 13, 2021): @kmahyyg, well the first option is something you should request at upstream bitwarden since that is a client item And the second is already built into all the clients. You can disable icon downloading per client in your user settings. You can also disable icon downloading on the server side, but that does not prevent the client from downloading.

OVERLORD commented

2026-02-04 23:28:40 +03:00

@lanceliao commented on GitHub (Oct 26, 2021):

I've met a similar issue: after editing an item, there is a chance to trigger batch update of icons, which will freeze the server.

To resolve the issue I configured nginx to use CDN for icon downloading:

 location /icons/ {
    rewrite ^/icons/(.*)$ https://icons.bitwarden.net/$1 permanent;
}

@lanceliao commented on GitHub (Oct 26, 2021): I've met a similar issue: after editing an item, there is a chance to trigger batch update of icons, which will freeze the server. ![icons](https://user-images.githubusercontent.com/4986217/138805780-dbca0aa6-8acd-4803-89ac-8dc2360873b0.JPG) To resolve the issue I configured nginx to use CDN for icon downloading: ``` location /icons/ { rewrite ^/icons/(.*)$ https://icons.bitwarden.net/$1 permanent; } ```

OVERLORD commented

2026-02-04 23:28:42 +03:00

@triqster commented on GitHub (Nov 9, 2021):

For those running Vaultwarden on Kubernetes this ingress example solved the crashes for me (using ingress-nginx). Thanks @lanceliao

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: https://icons.bitwarden.net$1$2
  name: vaultwarden-icons
spec:
  ingressClassName: nginx
  rules:
  - host: <your vaultwarden hostname>
    http:
      paths:
      - backend:
          service:
            name: vaultwarden
            port:
              number: 80
        path: /icons(/|$)(.*)
        pathType: Prefix
  tls:
  - hosts:
    - <your vaultwarden hostname>
    secretName: vaultwarden-tls

This rewrites all requests to /icons to https://icons.bitwarden.net

...
    nginx.ingress.kubernetes.io/rewrite-target: https://icons.bitwarden.net$1$2
...
        path: /icons(/|$)(.*)
...

@triqster commented on GitHub (Nov 9, 2021): For those running Vaultwarden on Kubernetes this ingress example solved the crashes for me (using ingress-nginx). Thanks @lanceliao ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: nginx.ingress.kubernetes.io/rewrite-target: https://icons.bitwarden.net$1$2 name: vaultwarden-icons spec: ingressClassName: nginx rules: - host: <your vaultwarden hostname> http: paths: - backend: service: name: vaultwarden port: number: 80 path: /icons(/|$)(.*) pathType: Prefix tls: - hosts: - <your vaultwarden hostname> secretName: vaultwarden-tls ``` This rewrites all requests to `/icons` to `https://icons.bitwarden.net` ``` ... nginx.ingress.kubernetes.io/rewrite-target: https://icons.bitwarden.net$1$2 ... path: /icons(/|$)(.*) ... ```

OVERLORD commented

2026-02-04 23:28:45 +03:00

@elvismercado commented on GitHub (Dec 27, 2021):

Another performance problem here, I met now. Cloudflare continously give me 524 error after importing hundreds of password from 1p.

After check the discussion here: #1470

I think things are not that clear.

I changed the worker number via ENV when running with docker, the workers are limited to 4 concurrently.

However, the log reveals that The web page were trying to downloading all the favicon of the items recorded in my account, since today my server network is under a heavy load, it becomes slow, Then finally /icons/<domain>/icon.png request goes to DDoS the server.

I personally recommend two solution for my situation, either should be good:
1. Do not show 500 items in a page, use pagination, 100 should be good. This means there won't be such much concurrent icon request.

2. Give user an option to download the favicon or not.
I personally like the second one.

@jjlin @BlackDex

BTW, I'll increase the worker number and have a try.

I have also experienced this after switching from the old bitwarden_rs container to the vaultwarden container.
Adding the rewrite as @lanceliao mentioned fixed it for me.

@elvismercado commented on GitHub (Dec 27, 2021): > Another performance problem here, I met now. Cloudflare continously give me 524 error **after** importing hundreds of password from 1p. > > After check the discussion here: #1470 > > I think things are not that clear. > > I changed the worker number via ENV when running with docker, the workers are limited to 4 concurrently. > > However, the log reveals that The web page were trying to downloading all the favicon of the items recorded in my account, since today my server network is under a heavy load, it becomes slow, Then finally `/icons/<domain>/icon.png` request goes to DDoS the server. > > I personally recommend two solution for my situation, either should be good: > > 1. Do not show 500 items in a page, use pagination, 100 should be good. This means there won't be such much concurrent icon request. > > 2. Give user an option to download the favicon or not. > > > I personally like the second one. > > @jjlin @BlackDex > > BTW, I'll increase the worker number and have a try. I have also experienced this after switching from the old bitwarden_rs container to the vaultwarden container. Adding the rewrite as @lanceliao mentioned fixed it for me.

OVERLORD commented

2026-02-04 23:28:48 +03:00

@kmahyyg commented on GitHub (Dec 27, 2021):

Hi, I almost forget this issue here. First, I switched to MySQL when deploying to the production environment. Second, I disabled favicon auto-fetching on both client and server. Since I hate nginx, disabling favicon is the best option I have. (And I really do not need any favicon since all my login items are well organized)

@kmahyyg commented on GitHub (Dec 27, 2021): Hi, I almost forget this issue here. First, I switched to MySQL when deploying to the production environment. Second, I disabled favicon auto-fetching on both client and server. Since I hate nginx, disabling favicon is the best option I have. (And I really do not need any favicon since all my login items are well organized)

OVERLORD commented

2026-02-04 23:28:53 +03:00

@jjlin commented on GitHub (Dec 27, 2021):

People having issues with icon requests preventing Rocket from servicing other API requests can consider setting an external icon service (#2158). This is similar to redirecting icon requests via reverse proxy, but implemented within Vaultwarden.

This feature is currently only available in the testing images though.

@jjlin commented on GitHub (Dec 27, 2021): People having issues with icon requests preventing Rocket from servicing other API requests can consider [setting an external icon service](https://github.com/dani-garcia/vaultwarden/blob/6bf8a9d93d596294b03017c30de08c8194104e3d/.env.template#L132-L143) (#2158). This is similar to redirecting icon requests via reverse proxy, but implemented within Vaultwarden. This feature is currently only available in the `testing` images though.

OVERLORD commented

2026-02-04 23:29:00 +03:00

@RealOrangeOne commented on GitHub (Dec 28, 2021):

Since https://github.com/dani-garcia/vaultwarden/pull/1545 (which I wrote to solve a very similar issue), the browser should be caching icons like this, for a very long time, meaning no requests should be hitting the server at all. It appears it's actually the browser causing the issue. When loading the vault after logging in, the browser makes all the icon requests for all entries. If you wait for those to complete, switch to the "Send" tab and then come back, the images are correctly cached and no extra requests are made. Which is odd!

Unfortunately, throwing a bunch of requests at a thread-based server will cause it to lock up. Once the port to Rocket's async implementation comes in, that will absolutely help with all this. In the mean time using an external service should work, although personally I'd really rather not do that. Alternatively, cranking the number of rocket worker should help, or putting a cache in nginx instead, as that's more suited to handling this many concurrent requests.

It's possible using some different caching methods, along with actually lazy-loading the images will make a huge difference. I'll have a play around this afternoon, see what comes out...

@RealOrangeOne commented on GitHub (Dec 28, 2021): Since https://github.com/dani-garcia/vaultwarden/pull/1545 (which I wrote to solve a very similar issue), the browser should be caching icons like this, for a very long time, meaning no requests should be hitting the server at all. It appears it's actually the browser causing the issue. When loading the vault after logging in, the browser makes all the icon requests for all entries. If you wait for those to complete, switch to the "Send" tab and then come back, the images are correctly cached and no extra requests are made. Which is odd! Unfortunately, throwing a bunch of requests at a thread-based server will cause it to lock up. Once the port to Rocket's async implementation comes in, that will absolutely help with all this. In the mean time using an external service should work, although personally I'd really rather not do that. Alternatively, cranking the number of rocket worker should help, or putting a [cache in nginx](https://www.nginx.com/blog/nginx-caching-guide/) instead, as that's more suited to handling this many concurrent requests. It's possible using some different caching methods, along with actually lazy-loading the images will make a huge difference. I'll have a play around this afternoon, see what comes out...

OVERLORD commented

2026-02-04 23:29:07 +03:00

@RealOrangeOne commented on GitHub (Dec 28, 2021):

I've opened a change upstream which should help with that influx of icon requests. On the one hand it's great to improve the application performance, and cache the responses, but not making said requests in the first place will likely help out even more! https://github.com/bitwarden/jslib/pull/591

@RealOrangeOne commented on GitHub (Dec 28, 2021): I've opened a change upstream which should help with that influx of icon requests. On the one hand it's great to improve the application performance, and cache the responses, but not making said requests in the first place will likely help out even more! https://github.com/bitwarden/jslib/pull/591

OVERLORD commented

2026-02-04 23:29:11 +03:00

@salixh5 commented on GitHub (Feb 27, 2022):

If you wonder how to do this with Caddy reverse proxy, adding this to my server config seems to work just fine for me:

handle_path /icons/* {
  redir https://icons.bitwarden.net{uri} permanent
}

The handle_path directive automatically removes /icons from the path which means a simple redir can be used.

@salixh5 commented on GitHub (Feb 27, 2022): If you wonder how to do this with Caddy reverse proxy, adding this to my server config seems to work just fine for me: ``` handle_path /icons/* { redir https://icons.bitwarden.net{uri} permanent } ``` The [`handle_path`](https://caddyserver.com/docs/caddyfile/directives/handle_path) directive automatically removes `/icons` from the path which means a simple [`redir`](https://caddyserver.com/docs/caddyfile/directives/redir) can be used.

OVERLORD commented

2026-02-04 23:29:15 +03:00

@BlackDex commented on GitHub (Feb 27, 2022):

If you wonder how to do this with Caddy reverse proxy, adding this to my server config seems to work just fine for me:
handle_path /icons/* {
  redir https://icons.bitwarden.net{uri} permanent
}
The handle_path directive automatically removes /icons from the path which means a simple redir can be used.

That isn't needed at all anymore since this is already a build-in option.
You can select between the default internal, google, duckduckgo and bitwarden, other options needed in any reverse proxy.

@BlackDex commented on GitHub (Feb 27, 2022): > If you wonder how to do this with Caddy reverse proxy, adding this to my server config seems to work just fine for me: > > ``` > handle_path /icons/* { > redir https://icons.bitwarden.net{uri} permanent > } > ``` > > The [`handle_path`](https://caddyserver.com/docs/caddyfile/directives/handle_path) directive automatically removes `/icons` from the path which means a simple [`redir`](https://caddyserver.com/docs/caddyfile/directives/redir) can be used. That isn't needed at all anymore since this is already a build-in option. You can select between the default `internal`, `google`, `duckduckgo` and `bitwarden`, other options needed in any reverse proxy.

OVERLORD commented

2026-02-04 23:29:18 +03:00

@salixh5 commented on GitHub (Feb 27, 2022):

Thanks, didn't know this already landed in a release.

@salixh5 commented on GitHub (Feb 27, 2022): Thanks, didn't know this already landed in a release.

OVERLORD commented

2026-02-04 23:29:19 +03:00

@perkons commented on GitHub (Mar 25, 2022):

Vault Items: 921
Vaultwarden version: 1.24.0
Web-vault version: 2.25.1
Running within Kubernetes: true
Database type: PostgreSQL 13

I have done some testing with different kind of data. Tested with url fields and without. I do not think that the performance issues are related to the icon loading.

Tested the web vault loading with:
50 items: load time ~5sec
100-300 items: load time ~10sec
921 items: load time ~22sec

I think you can see where this is going. To more ciphers there will be the slower the web vault will become.

@perkons commented on GitHub (Mar 25, 2022): Vault Items: 921 Vaultwarden version: 1.24.0 Web-vault version: 2.25.1 Running within Kubernetes: true Database type: PostgreSQL 13 I have done some testing with different kind of data. Tested with url fields and without. I do not think that the performance issues are related to the icon loading. Tested the web vault loading with: 50 items: load time ~5sec 100-300 items: load time ~10sec 921 items: load time ~22sec I think you can see where this is going. To more ciphers there will be the slower the web vault will become.

OVERLORD commented

2026-02-04 23:29:21 +03:00

@perkons commented on GitHub (Apr 13, 2022):

now we have
1209 items: load time ~31sec

@perkons commented on GitHub (Apr 13, 2022): now we have 1209 items: load time ~31sec

OVERLORD commented

2026-02-04 23:29:29 +03:00

@BlackDex commented on GitHub (Apr 13, 2022):

What is load time exactly btw?
The transfer from vaultwarden, the loading of the page it self? Or a combination?
If it is a combination, what is the actual transfer time from vaultwarden to the browser, and then what is the time after that for loading the content on screen?

@BlackDex commented on GitHub (Apr 13, 2022): What is load time exactly btw? The transfer from vaultwarden, the loading of the page it self? Or a combination? If it is a combination, what is the actual transfer time from vaultwarden to the browser, and then what is the time after that for loading the content on screen?

OVERLORD commented

2026-02-04 23:29:36 +03:00

@perkons commented on GitHub (Apr 14, 2022):

So to add some more details. The PostgreSQL database host is hosted in the same data center (latency <1ms). We did enable slow query logging. We saw that all the DB queries happen very fast.
We also looked inside the pod, the load with top is idle.

With the load time I mean when you login to Vaultwarden, refresh the page or go to settings and then back to the organization. I have the developer tools open, network tab and there you can see "/api sync?excludeDomains=true" takes ~32s. It is the same when we use the python module. It is the same for the official Bitwarden client, once you logout and login again, it will take the 32s to load. If you close the client or lock, it will load instantly. For the official client it seems that it clears the cache once you logout.

@perkons commented on GitHub (Apr 14, 2022): So to add some more details. The PostgreSQL database host is hosted in the same data center (latency <1ms). We did enable slow query logging. We saw that all the DB queries happen very fast. We also looked inside the pod, the load with top is idle. With the load time I mean when you login to Vaultwarden, refresh the page or go to settings and then back to the organization. I have the developer tools open, network tab and there you can see "/api sync?excludeDomains=true" takes ~32s. It is the same when we use the python module. It is the same for the official Bitwarden client, once you logout and login again, it will take the 32s to load. If you close the client or lock, it will load instantly. For the official client it seems that it clears the cache once you logout.

OVERLORD commented

2026-02-04 23:29:40 +03:00

@karlism commented on GitHub (Apr 14, 2022):

@BlackDex, hi, I'm colleague of @perkons so will answer questions on his behalf and provide more details.

Logging in into the Vaultwarden web-ui happens quickly, almost instantly, but then it stays like this for about 30 seconds before the list of our passwords appear:

By looking at at the browsers developer tools, I can see that it takes this long to open /api/sync?excludeDomains=true endpoint:

Other than loading initial list of passwords vaultwarden interface responses are quick and there are no issues. RTT between my laptop with browser to vaultwarden is about 7ms.

We have also some scripts that are using python bitwardentools module to add and retrieve passwords and they are also experiencing same performance issues while doing the sync, to show you an example:

$ cat /tmp/bitwarden.py     
#!/usr/bin/python

from bitwardentools import Client
from bitwardentools import client as bwclient
from datetime import datetime

try:
    client = Client('https://bitwarden.example.com', 'username@example.com', 'password')
except bwclient.LoginError:
    print("login error")

print("before sync: %s" % datetime.now().strftime("%d/%m/%Y %H:%M:%S"))
client.sync()
print("after sync: %s" % datetime.now().strftime("%d/%m/%Y %H:%M:%S"))

$ time python3 /tmp/bitwarden.py
before sync: 14/04/2022 13:57:09
after sync: 14/04/2022 13:57:41
python3 /tmp/bitwarden.py  1.38s user 0.88s system 6% cpu 35.606 total

Also, we enabled SQL query performance logging on our PostgreSQL server and can see that all vaultwarden SQL queries are executed very quickly, maximum time for the SQL query execution that we've seen was around 10ms, so we can exclude an issue with SQL backend performance.

@karlism commented on GitHub (Apr 14, 2022): @BlackDex, hi, I'm colleague of @perkons so will answer questions on his behalf and provide more details. Logging in into the Vaultwarden web-ui happens quickly, almost instantly, but then it stays like this for about 30 seconds before the list of our passwords appear: <img width="1011" alt="image" src="https://user-images.githubusercontent.com/19568035/163383715-f2d0f892-6183-4b6e-bdce-0a86bd836c71.png"> By looking at at the browsers developer tools, I can see that it takes this long to open `/api/sync?excludeDomains=true` endpoint: <img width="922" alt="image" src="https://user-images.githubusercontent.com/19568035/163384003-4ca3faa2-7370-4735-a728-94e92a491158.png"> Other than loading initial list of passwords vaultwarden interface responses are quick and there are no issues. RTT between my laptop with browser to vaultwarden is about 7ms. We have also some scripts that are using python [bitwardentools module](https://pypi.org/project/bitwardentools/) to add and retrieve passwords and they are also experiencing same performance issues while doing the sync, to show you an example: ``` $ cat /tmp/bitwarden.py #!/usr/bin/python from bitwardentools import Client from bitwardentools import client as bwclient from datetime import datetime try: client = Client('https://bitwarden.example.com', 'username@example.com', 'password') except bwclient.LoginError: print("login error") print("before sync: %s" % datetime.now().strftime("%d/%m/%Y %H:%M:%S")) client.sync() print("after sync: %s" % datetime.now().strftime("%d/%m/%Y %H:%M:%S")) $ time python3 /tmp/bitwarden.py before sync: 14/04/2022 13:57:09 after sync: 14/04/2022 13:57:41 python3 /tmp/bitwarden.py 1.38s user 0.88s system 6% cpu 35.606 total ``` Also, we enabled SQL query performance logging on our PostgreSQL server and can see that all vaultwarden SQL queries are executed very quickly, maximum time for the SQL query execution that we've seen was around 10ms, so we can exclude an issue with SQL backend performance.

OVERLORD commented

2026-02-04 23:29:44 +03:00

@BlackDex commented on GitHub (Apr 14, 2022):

I'm not sure which version of Vaultwarden you are running. But it would like to know if running the latest testing tagged version if not used currently does make a difference or not.

I do suggest to create a backup of the database (Or maybe even clone it and run a different container).

@BlackDex commented on GitHub (Apr 14, 2022): I'm not sure which version of Vaultwarden you are running. But it would like to know if running the latest `testing` tagged version if not used currently does make a difference or not. I do suggest to create a backup of the database (Or maybe even clone it and run a different container).

OVERLORD commented

2026-02-04 23:29:49 +03:00

@perkons commented on GitHub (Apr 14, 2022):

Vaultwarden version: 1.24.0
Web-vault version: 2.25.1
Running within Kubernetes: true
Database type: PostgreSQL 13

@perkons commented on GitHub (Apr 14, 2022): Vaultwarden version: 1.24.0 Web-vault version: 2.25.1 Running within Kubernetes: true Database type: PostgreSQL 13

OVERLORD commented

2026-02-04 23:29:52 +03:00

@karlism commented on GitHub (Apr 14, 2022):

@BlackDex, we're running 1.24.0-alpine image, I will update our dev environment to testing to see if that helps

$ kubectl -n bitwarden get pods -o yaml | grep image:
      image: vaultwarden/server:1.24.0-alpine@sha256:f8e5df1a87cfb7ee180414dc53401694d27820c00ada7cd5f1d5804ab087db87

And I also forgot to previously mention, that we've tried enabling debug logging for vaultwarden, but that didn't produce any useful logs about this issue.

@karlism commented on GitHub (Apr 14, 2022): @BlackDex, we're running 1.24.0-alpine image, I will update our dev environment to testing to see if that helps ``` $ kubectl -n bitwarden get pods -o yaml | grep image: image: vaultwarden/server:1.24.0-alpine@sha256:f8e5df1a87cfb7ee180414dc53401694d27820c00ada7cd5f1d5804ab087db87 ``` And I also forgot to previously mention, that we've tried enabling debug logging for vaultwarden, but that didn't produce any useful logs about this issue.

OVERLORD commented

2026-02-04 23:29:55 +03:00

@BlackDex commented on GitHub (Apr 14, 2022):

@karlism Nice. A few notes on the testing image and why it could be helpful with speed.

It's async now.
Using the latest libraries available at the time of build of which some had performance improvements.
The Alpine image is now using a different memory allocator (MiMalloc) which improves performance.

@BlackDex commented on GitHub (Apr 14, 2022): @karlism Nice. A few notes on the testing image and why it could be helpful with speed. 1. It's async now. 2. Using the latest libraries available at the time of build of which some had performance improvements. 3. The Alpine image is now using a different memory allocator (MiMalloc) which improves performance.

OVERLORD commented

2026-02-04 23:29:57 +03:00

@karlism commented on GitHub (Apr 14, 2022):

@BlackDex, thanks for your help!

I've updated it to latest testing image:

$ kubectl -n bitwarden get pods -o yaml | grep image: 
      image: vaultwarden/server:testing-alpine
      
$ kubectl -n bitwarden logs bitwarden-rs-7d857c857b-qn2w2| more
/--------------------------------------------------------------------\
|                        Starting Vaultwarden                        |
|                      Version 1.24.0-37fff3ef                       |
|--------------------------------------------------------------------|
| This is an *unofficial* Bitwarden implementation, DO NOT use the   |
| official channels to report bugs/features, regardless of client.   |
| Send usage/configuration questions or feature requests to:         |
|   https://vaultwarden.discourse.group/                             |
| Report suspected bugs/issues in the software itself at:            |
|   https://github.com/dani-garcia/vaultwarden/issues/new            |
\--------------------------------------------------------------------/

Unfortunately I do not see any difference as sync operation still takes around 30 seconds to complete:

$ time python3 /tmp/bitwarden.py
before sync: 14/04/2022 15:14:06
after sync: 14/04/2022 15:14:34
python3 /tmp/bitwarden.py  1.31s user 0.94s system 7% cpu 31.543 total

This is output of the top command from within the container during the sync operation, as you can see it's basically idle:

Mem: 14678744K used, 1508024K free, 800800K shrd, 571256K buff, 9828264K cached
CPU:   0% usr   0% sys   0% nic  98% idle   0% io   0% irq   0% sirq
Load average: 0.08 0.07 0.07 3/805 62
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    7     1 10802    S     314m   2%   3   0% /vaultwarden
   53     0 10802    S     1664   0%  11   0% /bin/sh
   60    53 10802    R     1592   0%   0   0% top
    1     0 10802    S      208   0%   7   0% /usr/bin/dumb-init -- /start.sh

@karlism commented on GitHub (Apr 14, 2022): @BlackDex, thanks for your help! I've updated it to latest testing image: ``` $ kubectl -n bitwarden get pods -o yaml | grep image: image: vaultwarden/server:testing-alpine $ kubectl -n bitwarden logs bitwarden-rs-7d857c857b-qn2w2| more /--------------------------------------------------------------------\ | Starting Vaultwarden | | Version 1.24.0-37fff3ef | |--------------------------------------------------------------------| | This is an *unofficial* Bitwarden implementation, DO NOT use the | | official channels to report bugs/features, regardless of client. | | Send usage/configuration questions or feature requests to: | | https://vaultwarden.discourse.group/ | | Report suspected bugs/issues in the software itself at: | | https://github.com/dani-garcia/vaultwarden/issues/new | \--------------------------------------------------------------------/ ``` Unfortunately I do not see any difference as `sync` operation still takes around 30 seconds to complete: ``` $ time python3 /tmp/bitwarden.py before sync: 14/04/2022 15:14:06 after sync: 14/04/2022 15:14:34 python3 /tmp/bitwarden.py 1.31s user 0.94s system 7% cpu 31.543 total ``` This is output of the `top` command from within the container during the `sync` operation, as you can see it's basically idle: ``` Mem: 14678744K used, 1508024K free, 800800K shrd, 571256K buff, 9828264K cached CPU: 0% usr 0% sys 0% nic 98% idle 0% io 0% irq 0% sirq Load average: 0.08 0.07 0.07 3/805 62 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 7 1 10802 S 314m 2% 3 0% /vaultwarden 53 0 10802 S 1664 0% 11 0% /bin/sh 60 53 10802 R 1592 0% 0 0% top 1 0 10802 S 208 0% 7 0% /usr/bin/dumb-init -- /start.sh ```

OVERLORD commented

2026-02-04 23:29:59 +03:00

@BlackDex commented on GitHub (Apr 14, 2022):

Well, the main thing is loading those entries and converting them to json.
To try and improve that it will take a while i think.

The strange thing is, on my test environment i have a lot more items, but it loads a lot faster.
Also, the size of the transfer is on my test environment is like +1MB larger and thus it looks like it has more data to process.
But it is much quicker in loading, it only takes about 1s to load, while on your environment it looks like it takes about +30s.

Also running that test script i get the following result:

time python3 vaultwarden-sync.py 
before sync: 14/04/2022 15:48:25
after sync: 14/04/2022 15:48:25

real	0m2,018s
user	0m0,227s
sys	0m0,030s

I do use sqlite here, i would need to test a postgresql an other time

@BlackDex commented on GitHub (Apr 14, 2022): Well, the main thing is loading those entries and converting them to json. To try and improve that it will take a while i think. The strange thing is, on my test environment i have a lot more items, but it loads a lot faster. Also, the size of the transfer is on my test environment is like +1MB larger and thus it looks like it has more data to process. But it is much quicker in loading, it only takes about 1s to load, while on your environment it looks like it takes about +30s. Also running that test script i get the following result: ```bash time python3 vaultwarden-sync.py before sync: 14/04/2022 15:48:25 after sync: 14/04/2022 15:48:25 real 0m2,018s user 0m0,227s sys 0m0,030s ``` I do use sqlite here, i would need to test a postgresql an other time

OVERLORD commented

2026-02-04 23:30:07 +03:00

@karlism commented on GitHub (Apr 14, 2022):

@BlackDex, can you please share items from your test enviroment so we can try it out here? Or we can just try generating CSV list of 2,000 passwords like these ourselves:

username1,password1
username2,password2
etc.

Just to exclude the possibility that it's something related to our passwords.

@karlism commented on GitHub (Apr 14, 2022): @BlackDex, can you please share items from your test enviroment so we can try it out here? Or we can just try generating CSV list of 2,000 passwords like these ourselves: ``` username1,password1 username2,password2 etc. ``` Just to exclude the possibility that it's something related to our passwords.

OVERLORD commented

2026-02-04 23:30:10 +03:00

@BlackDex commented on GitHub (Apr 14, 2022):

bitwarden_org_export_test-data.csv.zip

Attached is a list i have loaded into my test vault (With a bunch of other items not listed there).
Those are 1500 login items and 1500 note items.

It does take a long time for them to be imported. It may even happen that it reports a gateway timeout, but those items will still be loaded into the database, but again that could take a few minutes maybe.

I still need to create a good json file for this to really test all the separate features and items. But until now not really needed. Might do that this weekend maybe

@BlackDex commented on GitHub (Apr 14, 2022): [bitwarden_org_export_test-data.csv.zip](https://github.com/dani-garcia/vaultwarden/files/8489906/bitwarden_org_export_test-data.csv.zip) Attached is a list i have loaded into my test vault (With a bunch of other items not listed there). Those are 1500 login items and 1500 note items. It does take a long time for them to be imported. It may even happen that it reports a gateway timeout, but those items will still be loaded into the database, but again that could take a few minutes maybe. I still need to create a good json file for this to really test all the separate features and items. But until now not really needed. Might do that this weekend maybe

OVERLORD commented

2026-02-04 23:30:12 +03:00

@jjlin commented on GitHub (Apr 14, 2022):

@perkons @karlism

MySQL/PostgreSQL performance issues are more likely related to network latency, as in #1402. You mention you have less than 1 ms latency, which may not sound like much, but since Vaultwarden uses a lot of small queries, this can really add up. This model is something an in-process database like SQLite excels at (unless its database file is placed on network storage). If you try running a PostgreSQL server on the same machine as Vaultwarden, I expect you would see much better performance.

N.B. Upstream Bitwarden uses a lot of stored procedures to address performance issues like this, but it has its own drawbacks, like a lot more maintenance burden.

@jjlin commented on GitHub (Apr 14, 2022): @perkons @karlism MySQL/PostgreSQL performance issues are more likely related to network latency, as in #1402. You mention you have less than 1 ms latency, which may not sound like much, but since Vaultwarden uses a lot of small queries, this can really add up. This model is something an in-process database like SQLite excels at (unless its database file is placed on network storage). If you try running a PostgreSQL server on the same machine as Vaultwarden, I expect you would see much better performance. N.B. Upstream Bitwarden uses a lot of stored procedures to address performance issues like this, but it has its own drawbacks, like a lot more maintenance burden.

OVERLORD commented

2026-02-04 23:30:15 +03:00

@BlackDex commented on GitHub (Apr 15, 2022):

Regarding this issue and #1402 i just did some logging of all the queries done during a sync. I definitely think there is room for improvement. During the query logging i saw that some queries which are exactly the same are run as much times as there are items within an organization. We might be able to cache those for like 30s or i would even like to prevent them from running multiple times at all. Ill see if i have some time to take a better look at it.

But it could take some time, since this is not very easy i think with all the dependencies of all functions and conversion from/to json etc..

@BlackDex commented on GitHub (Apr 15, 2022): Regarding this issue and #1402 i just did some logging of all the queries done during a sync. I definitely think there is room for improvement. During the query logging i saw that some queries which are exactly the same are run as much times as there are items within an organization. We might be able to cache those for like 30s or i would even like to prevent them from running multiple times at all. Ill see if i have some time to take a better look at it. But it could take some time, since this is not very easy i think with all the dependencies of all functions and conversion from/to json etc..

OVERLORD commented

2026-02-04 23:30:17 +03:00

@karlism commented on GitHub (Apr 20, 2022):

Sorry, but I've previously misled you, after further testing I noticed that database and pod, where Vaultwarden is running, were in different datacenters (with 6-7ms latency in between them). After moving pod to the same datacenter, where database is running (and latency is below 1ms), the problem resolved and 921 password load time dropped from 22 seconds to below 1 second. @jjlin was spot on regarding database latency impact on Vaultwarden performance.

@karlism commented on GitHub (Apr 20, 2022): Sorry, but I've previously misled you, after further testing I noticed that database and pod, where Vaultwarden is running, were in different datacenters (with 6-7ms latency in between them). After moving pod to the same datacenter, where database is running (and latency is below 1ms), the problem resolved and 921 password load time dropped from 22 seconds to below 1 second. @jjlin was spot on regarding database latency impact on Vaultwarden performance.

OVERLORD commented

2026-02-04 23:30:19 +03:00

@BlackDex commented on GitHub (Apr 20, 2022):

Nice to see that it solved that issue.
But, i still think that we can improve. Running a lot of queries because of the N+1 issue we currently do.
I am working on this already, i have fixed a lot already by just using a single query for most items.
Still need to do some performance testing if that actually is faster or not, but still i think it's better then having a N+1 issue.

@BlackDex commented on GitHub (Apr 20, 2022): Nice to see that it solved that issue. But, i still think that we can improve. Running a lot of queries because of the N+1 issue we currently do. I am working on this already, i have fixed a lot already by just using a single query for most items. Still need to do some performance testing if that actually is faster or not, but still i think it's better then having a N+1 issue.

OVERLORD commented

2026-02-04 23:30:23 +03:00

@BlackDex commented on GitHub (May 11, 2022):

Solved via #2429

@BlackDex commented on GitHub (May 11, 2022): Solved via #2429

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#962