Skip to content
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

Closed
qmhu opened this issue Aug 5, 2015 · 14 comments
Closed

low get performance when use auth #3223

qmhu opened this issue Aug 5, 2015 · 14 comments
Assignees
Milestone

Comments

@qmhu
Copy link

qmhu commented Aug 5, 2015

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.

@yichengq
Copy link
Contributor

yichengq commented Aug 5, 2015

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

@qmhu
Copy link
Author

qmhu commented Aug 7, 2015

any ideas?
my project is a web project which build by php + wordpress and I need get some config from etcd, i want to perceive config change from etcd real time. so I have to get config very frequently.

but consider 0.17s every request's latency, I have to reduce request to etcd as much as possible.

@citywander
Copy link

Maybe you can cache, plaintext and hash.

@xiang90 xiang90 added this to the v2.2.0-rc0 milestone Aug 10, 2015
@xiang90
Copy link
Contributor

xiang90 commented Aug 10, 2015

@qmhu @citywander We are going to investigate more and try to solve it soon. Stay tuned.

@xiang90 xiang90 self-assigned this Aug 10, 2015
@xiang90
Copy link
Contributor

xiang90 commented Aug 17, 2015

@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?)

@barakmich
Copy link
Contributor

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.

@xiang90
Copy link
Contributor

xiang90 commented Aug 17, 2015

@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.

@xiang90
Copy link
Contributor

xiang90 commented Aug 24, 2015

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.

@xiang90 xiang90 removed this from the v2.2.0-rc0 milestone Aug 24, 2015
@qmhu
Copy link
Author

qmhu commented Aug 31, 2015

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.

@xiang90 @barakmich

@thepwagner
Copy link

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.

@roboll
Copy link
Contributor

roboll commented Nov 25, 2015

#3916 implements authentication using common name, that should solve this.

@xiang90
Copy link
Contributor

xiang90 commented Jul 21, 2016

closed by #5991

@xiang90 xiang90 closed this as completed Jul 21, 2016
@ZeaLoVe
Copy link

ZeaLoVe commented Mar 22, 2017

@xiang90 Could you please tell me how this problem solved? any docs?
I tried version 3.1, performance still bad. In my case, I try to use etcd with http+auth.

@andybrown668
Copy link

I have the same issue using the latest (?) docker image 3.3.9
I guess I'm using authentication in the wrong way because the performance degradation using basic auth makes it a complete non-starter.
My implementation (in go) makes use of an etcd client with this config:

	cfg := client.Config{
		Endpoints: endpoints,
		Username: os.Getenv("ETCD_USERNAME"),
		Password: os.Getenv("ETCD_PASSWORD"),
		Transport: client.DefaultTransport,
		// set timeout per request to fail fast when the target endpoint is unavailable
		HeaderTimeoutPerRequest: time.Second,
	}
	c, err := client.New(cfg)

I then retain the connection and also retain the keys api I get from calling NewKeysAPI
It looks like I get the same order of slowdown as the orginal reporter of this issue but the issue was closed a long time ago.

What should I be doing to get authenticated access and performance?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

9 participants