# How to troubleshoot throughput performance degrade?

**URL:** <https://forums.foundationdb.org/t/how-to-troubleshoot-throughput-performance-degrade/1436>\
**Category:** Using FoundationDB\
**Tags:** performance\
**Created:** [June 10, 2019, 10:09am UTC](https://forums.foundationdb.org/t/how-to-troubleshoot-throughput-performance-degrade/1436 "2019-06-10T10:09:55Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![alexmiller](https://sea1.discourse-cdn.com/foundationdb/user_avatar/forums.foundationdb.org/alexmiller/32/326_2.png) [@alexmiller](https://forums.foundationdb.org/u/alexmiller)\
**Post date:** [June 14, 2019, 8:08pm UTC](https://forums.foundationdb.org/t/how-to-troubleshoot-throughput-performance-degrade/1436/20 "2019-06-14T20:08:36Z")

</div>

> [@rayjcwu](#):
>
> Is it because most of foundationDB keys start with ‘k’ and ‘s’ so most of the traffic fall on 2 storage processes?

I do also find it very suspicious that your first graph had a large number of storage servers all struggling, but your second one had only two.

I don’t see anyone mentioning it here, but if you’re starting from an empty database, then FDB is going to have to compete with your workload to try and split your data sufficiently so that the writes are spread across the servers.

Our own write bandwidth tests pre-load a large volume of data to create enough shards to distribute writes well, wait for data distribution to finish, and then run the actual write bandwidth test.

KrzysFR posted an [example of this](https://forums.foundationdb.org/t/understanding-load-balancing-between-storage-processes-under-bulk-writes/974) with good stats from his tooling before.

---

_[View the full topic](https://forums.foundationdb.org/t/how-to-troubleshoot-throughput-performance-degrade/1436)._