J'ai pris vos CouchbaseTests, commenté les bits non-Couchbase. Correction de la requête pour sélectionner dans la collection ( myCollection ) au lieu de jobcache et suppression de l'option Metrics. Et créé un index sur JobId.create index mybucket_JobId on default:myBucket.myScope.myCollection (JobId)Il insère les 100 000 documents en 19 secondes et kv-récupère les documents en moyenne 146 usec et interroge par JobId en moyenne 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).
C'était sur 7.0 build 3739 sur un Mac Book Pro avec le cbserver exécuté localement.
################################################# ####################
J'ai une petite application LoadDriver pour le sdk java qui utilise l'api kv. Avec 4 threads, il affiche un temps de réponse moyen de 54 microsecondes et un débit de 73238 requêtes/seconde. Il utilise le bucket travel-sample sur un serveur cb sur localhost. [email protected]:mikereiche/loaddriver.git
Exécution :secondes :10, threads :4, délai :40 000 us, seuil :8 000 us demandes/seconde : 0 (max), intervalle GC forcé :0 mscount :729 873, demandes/seconde :72 987, max :2796 us s :73238
Pour l'API de requête, j'obtiens ce qui suit qui est 18 fois plus lent.
Exécution :secondes :10, threads :4, délai :40 000 us, seuil :8 000 us requêtes/seconde : 0 (max), intervalle GC forcé :0 mscount :41 378, requêtes/seconde :4137, max :12 032 us s : 4144
