Eu peguei seus CouchbaseTests, comentei os bits não-Couchbase. Corrigida a consulta a ser selecionada da coleção ( myCollection ) em vez do jobcache e removida a opção Métricas. E criou um índice em JobId.create índice mybucket_JobId em default:myBucket.myScope.myCollection (JobId) Ele insere os 100.000 documentos em 19 segundos e kv-busca os documentos em média 146 usec e consulta por JobId em média 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).
Isso foi no 7.0 build 3739 em um Mac Book Pro com o cbserver rodando localmente.
################################################# ####################
Eu tenho um pequeno aplicativo LoadDriver para o SDK Java que usa a API kv. Com 4 threads, apresenta um tempo médio de resposta de 54 microssegundos e uma taxa de transferência de 73.238 solicitações/segundo. Ele usa o bucket travel-sample em um servidor cb no localhost. [email protected]:mikereiche/loaddriver.git
Execução:segundos:10, encadeamentos:4, tempo limite:40000us, limite:8000us solicitações/segundo:0 (máximo), intervalo GC forçado:0mscount:729873, solicitações/segundo:72987, máximo:2796us avg:54us, agregado rq/ s:73238
Para a API de consulta, recebo o seguinte, que é 18 vezes mais lento.
Execução:segundos:10, encadeamentos:4, tempo limite:40000us, limite:8000us solicitações/segundo:0 (máximo), intervalo GC forçado:0mscount:41378, solicitações/segundo:4137, máximo:12032us avg:965us, agregado rq/ s:4144
