Closed behrad closed 9 years ago
what version of couch are you testing against? On Feb 15, 2015 11:11 AM, "Behrad" notifications@github.com wrote:
My future response time is around 800ms, and this has turned to a bottleneck in my Spray REST server... each request does a view call... around 40 calls/sec, couchbase claims 6 view calls on its console.
TraceRecorder.withNewTraceContext(s"AccViewCall") { val future = coreBucket.findAccount( new Query().setIncludeDocs(true).setReduce(false).setStale(Stale.FALSE).setKey( username ) ).map { p => TraceRecorder.finish() } }(context.system)
Am I doing something wrong?
— Reply to this email directly or view it on GitHub https://github.com/ReactiveCouchbase/ReactiveCouchbase-core/issues/57.
3.0.0
views performance on 3.x is much better than pervious releases especially if running on AWS ebs storage..
still, views are an order or even 2 orders of magnitude slower compared to get by key operations.
usually there is always a workaround to avoid views all together if performance becomes an issue. if you wanna share your design I can try to help with a suggested workaround. On Feb 15, 2015 4:01 PM, "Behrad" notifications@github.com wrote:
3.0.0
— Reply to this email directly or view it on GitHub https://github.com/ReactiveCouchbase/ReactiveCouchbase-core/issues/57#issuecomment-74418445 .
thank you @chenbekor this is actually a findByUsername for check password validation on a per/request basis. I may also have two other options:
1) cache view results (all accounts by user names) in my local process (there won't be more than a few hundred accounts in system)
2) add PREFIX_username -> password
key combinations on couchbase, for the sake of fast key lookups.
we have a very similar use case. In our case we do the following -
we store a dual pointing system (similar to your #2) so that we perform 2 lookups on auth requests.
btw - this is not done per request. once a user is authenticated we generate a access_token with TTL and use it in order to validate future calls. This reduce the lookups back to one fetch instead of 2 fetches per API call.
:+1:
However I saw a very better performance in CouchDB views... they are really faster and sharper... Couchbase adds middleware stuff which degrades their view performance
CouchDB == no scale out. We really can't compare the two products. btw - i think that view performance is something couchbase will continue to heavily invest in since the entire N1QL solution depends on it.
My future response time is around 800ms, and this has turned to a bottleneck in my Spray REST server... each request does a view call... around 40 calls/sec, couchbase claims 6 view calls on its console.
Am I doing something wrong?