-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
low get performance when use auth #3223
Comments
The cause is that we use bcrypt to hash the password, and it needs ~100ms to check the password could match the hash value. Any idea to improve this? @barakmich |
any ideas? but consider 0.17s every request's latency, I have to reduce request to etcd as much as possible. |
Maybe you can cache, plaintext and hash. |
@qmhu @citywander We are going to investigate more and try to solve it soon. Stay tuned. |
@philips @barakmich Any opinion on this one? We can either cache the result or just use plain test as password (does etcd really need to protect the passwords stored in it?) |
NO. We should not save passwords in plaintext. Come on, guys. Bcrypt is there for a reason. Now, that said... Basic Auth is sending plaintext on the wire. This is why we have TLS. If you generate a bearer token (a la OAuth) after the first auth and store it etcd-side with a TTL, you can get a plaintext token, the comparison speedup that will eventually timeout gracefully. So your first request will still be ~100ms, but the subsequent ones can be considerably faster. |
@barakmich If we do want the security, the bcrypt is probably the only option and the slowness is one of its feature. To speedup, we need to go the plaintext token way. It changes both the server side and client side. If we go that way, we probably need to move this to a lower priority for 2.2 release. |
Lower priority of this issue since this is not a block, but a performance improvement. I am still not sure which is the best way to solve it. /cc @philips @yichengq @barakmich @citywander @qmhu Any suggestion would be appreciated. |
From my side, we can't stand for 0.1s+'s latency for every request. I support using plaintext but enable cache in server side is fine to me as long as the latency can regain back to a normal level. by the way, if etcd can support multiple get, we can reduce the get request times,and this will help to improve my site's performance. |
In the HTTPS case, why not pull the "username" from the client's X509 DN? That would sidestep the bcrypt() bottleneck, and smarter clients could KeepAlive to perform multiple requests with a fixed authentication cost. |
#3916 implements authentication using common name, that should solve this. |
closed by #5991 |
@xiang90 Could you please tell me how this problem solved? any docs? |
I have the same issue using the latest (?) docker image 3.3.9
I then retain the connection and also retain the keys api I get from calling NewKeysAPI What should I be doing to get authenticated access and performance? |
When enable auth for etcd, request latency increase a lot. the test result is as below:
test env: Ubuntu14.04 Server virtual machine+16G
test case: php script to put a value in etcd and send 100 sequence get request and record the time cost for 100 get request then calculate average latency for every get request.
http: 0.0006s
http+auth: 0.14s
https: 0.08s
https+auth:0.17s
besides, enable https in etcd also make latency increase a lot.
The text was updated successfully, but these errors were encountered: