# Review request for "Elasticsearch Survival Guide for Developers" blog post **URL:** \ **Category:** Elasticsearch\ **Created:** [May 29, 2019, 7:27pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411 "2019-05-29T19:27:45Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [May 29, 2019, 7:52pm UTC](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411/2 "2019-05-29T19:52:45Z")
A few comments from a quick scan: There is, as far as I can see, no mention of oversharding, and this is pretty much the #1 problem we see with users. I think it's worth a mention and maybe a link to a blog post [like this one](https://www.elastic.co/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster). > Start first by setting `index.translog.durability` to `async` . **Please don't recommend this**. It will cause less experienced users to experience data loss. The default durability setting is much safer, and normally performs just fine on good hardware. In fact I think that whole paragraph on translog tuning is a little misleading for a "survival guide". There are lots of other things I'd look at for performance gains before turning to these settings. > Adapt `index.refresh_interval` to your needs. It might be best to leave this setting unset too. In recent versions, if you're indexing but not searching then there will be no refreshes taking place. From [the docs](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html#dynamic-index-settings): > If this setting is not explicitly set, shards that haven’t seen search traffic for at least `index.search.idle.after` seconds will not receive background refreshes until they receive a search request. > Compare-and-swap over `_version` field is poor man’s transactions The preferred CAS operation uses `_primary_term` and `_seq_no`, since `_version` [has known issues](https://github.com/elastic/elasticsearch/issues/19269). --- _[View the full topic](https://discuss.elastic.co/t/review-request-for-elasticsearch-survival-guide-for-developers-blog-post/183411)._