Wziąłem twoje CouchbaseTests, skomentowałem bity spoza Couchbase. Naprawiono zapytanie, aby wybrać z kolekcji ( myCollection ) zamiast Jobcache i usunięto opcję Metryki. I utworzyłem indeks na JobId.create index mybucket_JobId na default:myBucket.myScope.myCollection (JobId)Wstawia 100 000 dokumentów w 19 sekund i kv-pobiera dokumenty średnio 146 usec i zapytania według JobId średnio 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).
Było to w wersji 7.0 kompilacja 3739 na Mac Book Pro z serwerem cb działającym lokalnie.
################################################## ####################
Mam małą aplikację LoadDriver dla zestawu sdk java, który używa interfejsu API kv. Przy 4 wątkach pokazuje średni czas odpowiedzi 54 mikrosekundy i przepustowość 73238 żądań na sekundę. Wykorzystuje wiadro próbki podróży na serwerze cb na hoście lokalnym. [email protected]:mikereiche/loaddriver.git
Uruchom:sekundy:10, wątki:4, limit czasu:40000us, próg:8000us żądań/sekundę:0 (max), wymuszony interwał GC:0mscount:729873, żądania/sekundę:72987, max:2796us avg:54us, zagregowane rq/ s:73238
W przypadku interfejsu API zapytań otrzymuję następujące, które jest 18 razy wolniejsze.
Uruchom:sekundy:10, wątki:4, limit czasu:40000us, próg:8000us żądań/sekundę:0 (max), wymuszony interwał GC:0mscount:41378, żądania/sekundę:4137, max:12032us avg:965us, zagregowane rq/ s:4144
