Ho preso i tuoi CouchbaseTests, ho commentato i bit non Couchbase. Corretta la query per selezionare dalla raccolta ( myCollection ) invece di jobcache e rimossa l'opzione Metrics. E creato un indice su JobId.create index mybucket_JobId on default:myBucket.myScope.myCollection (JobId)Inserisce i 100.000 documenti in 19 secondi e kv-preleva i documenti in media 146 usec e interroga per JobId in media 965 usec.
Couchbase Q: 0 187
Couchbase Q: 1 176
Couchbase Q: 2 143
Couchbase Q: 3 147
Couchbase Q: 4 140
Couchbase Q: 5 138
Couchbase Q: 6 136
Couchbase Q: 7 139
Couchbase Q: 8 125
Couchbase Q: 9 129
average et: 146 ms per 1000 -> 146 usec / request
Couchbase Q: 0 1155
Couchbase Q: 1 1086
Couchbase Q: 2 1004
Couchbase Q: 3 901
Couchbase Q: 4 920
Couchbase Q: 5 929
Couchbase Q: 6 912
Couchbase Q: 7 911
Couchbase Q: 8 911
Couchbase Q: 9 927
average et: 965 ms per 1000 -> 965 usec / request. (coincidentally exactly the same as with the java api).
Questo era su 7.0 build 3739 su un Mac Book Pro con cbserver in esecuzione localmente.
############################################################### ########################
Ho una piccola applicazione LoadDriver per java sdk che utilizza l'API kv. Con 4 thread, mostra un tempo di risposta medio di 54 microsecondi e un throughput di 73238 richieste/secondo. Utilizza il bucket del campione di viaggio su un server cb su localhost. [email protected]:mikereiche/loaddriver.git
Esegui:secondi:10, thread:4, timeout:40000us, soglia:8000us richieste/secondo:0 (max), intervallo GC forzato:0 mscount:729873, richieste/secondo:72987, max:2796us avg:54us, aggregate rq/ s:73238
Per l'API di query ottengo quanto segue, che è 18 volte più lento.
Esegui:secondi:10, thread:4, timeout:40000us, soglia:8000us richieste/secondo:0 (max), intervallo GC forzato:0 mscount:41378, richieste/secondo:4137, max:12032us avg:965us, aggregate rq/ s:4144
