# How to avoid upstream timeouts?

**URL:** <https://meta.discourse.org/t/how-to-avoid-upstream-timeouts/35483>\
**Category:** Support\
**Created:** [November 12, 2015, 5:17am UTC](https://meta.discourse.org/t/how-to-avoid-upstream-timeouts/35483 "2015-11-12T05:17:57Z")\
**Posts on this page:** 1\
**Showing post:** 14

<div class="post-metadata">

**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\
**Post date:** [September 15, 2017, 5:48pm UTC](https://meta.discourse.org/t/how-to-avoid-upstream-timeouts/35483/14 "2017-09-15T17:48:14Z")

</div>

> [@pfaffman](#):
>
> You’re back!

Packing my stuff and took a minute to check Meta 😊

> [@pfaffman](#):
>
> so with 8CPUs and 12GB
> 
> db\_work\_mem: 40MB
> 
> UNICORN\_WORKERS: 8
> 
> and with 4 CPUs and 8GB
> 
> db\_work\_mem: 40MB
> 
> UNICORN\_WORKERS: 4

Sounds good!

> [@pfaffman](#):
>
> With a huge database (say postgres\_data is 8GB of disk space and there’s 8GB of ram)

At this size, I would split machines:

- DB Machine

- Web Machine(s)

Then you can check timings (the awesome mini\_profiler info should be enough) and scale machines independently.

---

_[View the full topic](https://meta.discourse.org/t/how-to-avoid-upstream-timeouts/35483)._