Взех вашите CouchbaseTests, коментирах битовете, които не са Couchbase. Коригирана е заявката за избор от колекцията ( myCollection ) вместо кеш за задания и е премахната опцията Метрики. И създаде индекс на JobId.create index mybucket_JobId по подразбиране:myBucket.myScope.myCollection (JobId)Той вмъква 100 000 документа за 19 секунди и kv-извлича документите средно 146 usec и запитване от JobId средно
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).
Това беше на 7.0 build 3739 на Mac Book Pro с cbserver, работещ локално.
################################################### #####################
Имам малко приложение LoadDriver за java sdk, което използва kv api. С 4 нишки, той показва средно време за реакция от 54 микросекунди и пропускателна способност от 73238 заявки/секунда. Той използва пакета за проби за пътуване на cb сървър на localhost. [email protected]:mikereiche/loaddriver.git
Изпълнение:секунди:10, нишки:4, изчакване:40000us, праг:8000us заявки/секунда:0 (макс.), принудителен GC интервал:0mscount:729873, заявки/секунда:72987, макс:2796us4usr avg:avg. s:73238
За API на заявката получавам следното, което е 18 пъти по-бавно.
Изпълнение:секунди:10, нишки:4, изчакване:40000us, праг:8000us заявки/секунда:0 (макс.), принудителен GC интервал:0mscount:41378, заявки/секунда:4137, макс:12032us avg, ag96us avg:ag96us avg s:4144
