big response times in view calls

[behrad]

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.find[Account]("accounts", "byUsername")(
        new Query().setIncludeDocs(true).setReduce(false).setStale(Stale.FALSE).setKey( username )
      ).map { p =>
        TraceRecorder.finish()
      }
    }(context.system)

Am I doing something wrong?

[chenbekor]

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.

[behrad]

3.0.0

[chenbekor]

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 .

[behrad]

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.

[chenbekor]

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.

[behrad]

:+1:

[behrad]

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

[chenbekor]

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.