Tomé sus CouchbaseTests, comenté los bits que no son de Couchbase. Se corrigió la consulta para seleccionar de la colección ( myCollection ) en lugar de la caché de trabajo y se eliminó la opción Métricas. Y creó un índice en JobId.create index mybucket_JobId por defecto:myBucket.myScope.myCollection (JobId) Inserta los 100.000 documentos en 19 segundos y busca los documentos en promedio 146 usec y consulta por JobId en promedio 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).
Esto fue en 7.0 compilación 3739 en una Mac Book Pro con cbserver ejecutándose localmente.
############################################## ###################
Tengo una pequeña aplicación LoadDriver para java sdk que usa kv api. Con 4 subprocesos, muestra un tiempo de respuesta promedio de 54 microsegundos y un rendimiento de 73238 solicitudes/segundo. Utiliza el cubo de muestra de viaje en un servidor cb en localhost. [email protected]:mikereiche/loaddriver.git
Ejecutar:segundos:10, subprocesos:4, tiempo de espera:40000us, umbral:8000us solicitudes/segundo:0 (máx.), intervalo de GC forzado:0mscount:729873, solicitudes/segundo:72987, máx.:2796us promedio:54us, rq agregado/ s:73238
Para la API de consulta, obtengo lo siguiente, que es 18 veces más lento.
Ejecutar:segundos:10, subprocesos:4, tiempo de espera:40000us, umbral:8000us solicitudes/segundo:0 (máx.), intervalo de GC forzado:0mscount:41378, solicitudes/segundo:4137, máx.:12032us promedio:965us, rq agregado/ s:4144
