# Benchmarking FoundationDB on AWS

**URL:** <https://forums.foundationdb.org/t/benchmarking-foundationdb-on-aws/410>\
**Category:** Using FoundationDB\
**Created:** [May 14, 2018, 9:55am UTC](https://forums.foundationdb.org/t/benchmarking-foundationdb-on-aws/410 "2018-05-14T09:55:57Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![ajbeamon](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/ajbeamon/32/13_2.png) [@ajbeamon](https://forums.foundationdb.org/u/ajbeamon)\
**Post date:** [May 14, 2018, 4:36pm UTC](https://forums.foundationdb.org/t/benchmarking-foundationdb-on-aws/410/4 "2018-05-14T16:36:16Z")

</div>

> [@cih.y2k](#):
>
> I haven’t figured out where is the bottleneck (fdb go client or go-ycsb)

It doesn’t look like the cluster is saturated in this test, so as you indicate your limit is likely somewhere on the client side. To benchmark the throughput of the cluster, you would need to drive sufficient load, probably with several clients (see [Developer Guide — FoundationDB 7.1](https://apple.github.io/foundationdb/developer-guide.html#throughput-requires-concurrency)).

In a FoundationDB client, there is currently a single thread (called the network thread) which serializes the client operations, does the FDB related client-side processing, and handles the network communication. It’s possible for your client to saturate this thread, at which point you’ve reached the maximum throughput of an individual client. It’s also possible that if you don’t have enough concurrency on the client, you could instead be latency bound. In that case, you could try turning up the concurrency within your clients as well.

---

_[View the full topic](https://forums.foundationdb.org/t/benchmarking-foundationdb-on-aws/410)._