Database performance considerations for multi-instance deployment #366
Replies: 3 comments
-
The main performance issue is fixed but the note is remained in docs. Any other usages are welcome for high availability, but I want to leave it to users. As far as I know, most users has only ability to use docker, let alone k8s. So I didn't put much thing about how to use k8s, just a demo with tiny explanations there. I think it's not my duty to teach people about cloud native stuff. However, if you want to help me make the docs better, that's definitely welcomed. |
Beta Was this translation helpful? Give feedback.
-
if you want to contribute to the docs, please make pr to github.com/gzctf/website And you are welcome to join the discord and telegram group if you want. |
Beta Was this translation helpful? Give feedback.
-
Yes, such PR is definitely welcomed. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
https://gzctf.gzti.me/guide/issues/qa.html#anything-worth-noting-when-deploying-to-a-multi-node-cluster
The experienced performance issues might be because of the overhead of creating/closing connections. This is due to the lack of using a "connection pooler". Its job is to minimize this overhead.
It is recommended to use PgPool or PgBounder. So instead of deploying a simple raw YAML manifest to deploy postgres. A sophisticated HA setup should be deployed. For example postgresql-ha helm chart created by bitnami.
I have been recently working on a helm chart that instantly deploys GZCTF with redis-ha (ArgoCD uses this) and postgresql-ha as chart dependencies with a single command. If such contributions are welcome let me know I can submit a PR
Beta Was this translation helpful? Give feedback.
All reactions