# How to simulate to see the values for client\_read\_error and client\_write\_error

**URL:** <https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260>\
**Category:** Monitoring\
**Created:** [June 13, 2017, 6:01pm UTC](https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260 "2017-06-13T18:01:06Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![rayc](https://avatars.discourse-cdn.com/v4/letter/r/d78d45/32.png) [@rayc](https://discuss.aerospike.com/u/rayc)\
**Post date:** [June 13, 2017, 6:01pm UTC](https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260/1 "2017-06-13T18:01:06Z")

</div>

I’m testing the aerospike metrics and would like to see the non-zero values for client\_read\_error and/or client\_write\_error by any means. I tried Aerospike provided benchmark java client and I could see the errors for read/write in the cli with tweaking the tps and some other parameters, but those monitoring metrics just report zeroes.

The doc says the client\_read\_error indicates Number of client read transaction errors. Is this for the aerospike error itself for any reason or could it happen with a wrong query from user?

---

<div class="post-metadata">

**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\
**Post date:** [June 13, 2017, 6:22pm UTC](https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260/2 "2017-06-13T18:22:33Z")

</div>

Could you provide applicable portions of the benchmark log? Would like to see what errors were being reported by the client.

---

<div class="post-metadata">

**Author:** ![rayc](https://avatars.discourse-cdn.com/v4/letter/r/d78d45/32.png) [@rayc](https://discuss.aerospike.com/u/rayc)\
**Post date:** [June 13, 2017, 6:55pm UTC](https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260/3 "2017-06-13T18:55:30Z")

</div>

Sure, I’m testing this on RHEL7.2 with aerospike community version.

```auto
# ./run_benchmarks -h 127.0.0.1 -p 3000 -n test -k 100000000 -b 1 -o B:1400 -w RU,50 -g 20000 -T 2 -z 50

Benchmark: 127.0.0.1 3000, namespace: test, set: testset, threads: 50, workload: READ_UPDATE
read: 50% (all bins: 100%, single bin: 0%), write: 50% (all bins: 100%, single bin: 0%)
keys: 100000000, start key: 0, transactions: 0, bins: 1, random values: false, throughput: 20000 tps
read policy:
    socketTimeout: 2, totalTimeout: 2, maxRetries: 2, sleepBetweenRetries: 0
    consistencyLevel: CONSISTENCY_ONE, replica: SEQUENCE, reportNotFound: false
write policy:
    socketTimeout: 2, totalTimeout: 2, maxRetries: 2, sleepBetweenRetries: 500
    commitLevel: COMMIT_ALL
Sync: connPoolsPerNode: 1
bin[0]: byte[1400]
debug: false
2017-06-13 14:53:43.525 INFO Thread main Add node BB9ACB2B93E16FA 127.0.0.1 3000
2017-06-13 14:53:44.900 write(tps=16595 timeouts=1891 errors=1178) read(tps=16403 timeouts=1945 errors=1059) total(tps=32998 timeouts=3836 errors=2237)
2017-06-13 14:53:45.901 write(tps=9920 timeouts=294 errors=9) read(tps=10130 timeouts=300 errors=12) total(tps=20050 timeouts=594 errors=21)
2017-06-13 14:53:46.901 write(tps=9884 timeouts=1861 errors=1156) read(tps=10169 timeouts=1891 errors=1095) total(tps=20053 timeouts=3752 errors=2251)
2017-06-13 14:53:47.903 write(tps=10034 timeouts=409 errors=98) read(tps=10102 timeouts=419 errors=88) total(tps=20136 timeouts=828 errors=186)
2017-06-13 14:53:48.903 write(tps=10134 timeouts=1035 errors=243) read(tps=9923 timeouts=998 errors=278) total(tps=20057 timeouts=2033 errors=521)
2017-06-13 14:53:49.904 write(tps=9999 timeouts=652 errors=78) read(tps=10073 timeouts=595 errors=73) total(tps=20072 timeouts=1247 errors=151)
2017-06-13 14:53:50.904 write(tps=9986 timeouts=741 errors=368) read(tps=10076 timeouts=727 errors=356) total(tps=20062 timeouts=1468 errors=724)
2017-06-13 14:53:51.904 write(tps=10124 timeouts=446 errors=164) read(tps=9924 timeouts=457 errors=213) total(tps=20048 timeouts=903 errors=377)

```

---

<div class="post-metadata">

**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\
**Post date:** [June 13, 2017, 7:25pm UTC](https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260/4 "2017-06-13T19:25:26Z")

</div>

If a read were to fail for reasons other than **timeout** or **not\_found** then **client\_read\_error** is incremented, otherwise either **client\_read\_timeout** or **client\_read\_not\_found** will increment.

Likewise, if a write were to fail for reasons other than **timeout** then **client\_write\_error** is incremented.

See [Java Client error codes](https://discuss.aerospike.com/t/java-client-error-codes/708) for a list of errors reported by the Java client.

---

<div class="post-metadata">

**Author:** ![rayc](https://avatars.discourse-cdn.com/v4/letter/r/d78d45/32.png) [@rayc](https://discuss.aerospike.com/u/rayc)\
**Post date:** [June 13, 2017, 8:22pm UTC](https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260/5 "2017-06-13T20:22:35Z")

</div>

Okay thanks very much. My timeout parameter was too small. Now I can see the metrics having the non-zero values.

---

<div class="post-metadata">

**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\
**Post date:** [June 13, 2017, 8:41pm UTC](https://discuss.aerospike.com/t/how-to-simulate-to-see-the-values-for-client-read-error-and-client-write-error/4260/6 "2017-06-13T20:41:49Z")

</div>

If I follow, the server timeouts are likely less than the client timeouts because the server had sent the response and the client issued a client-side timeout while the response was in transit.
