max 10 spojeni na 1 cpu jadro
Je potřeba se zamyslet nad tím, z čeho tohle doporučení vychází. Tohle předpokládá, že se v té DB bude skutečně něco počítat. Pokud v DB nic nepočítáte, tak jednak se nemusí nutně používat PG, ale taky by to doporučení vypadalo jinak. Třeba podle toho, kolik tam máte disků. Klasické rotační disky více než jednoho klienta stejně nezvládnou (protože jedna hlavička), takže nemá smysl nad 10 disky nastavovat 500 klientů. Jen to zbytečně zvýší latence. A ve skutečnosti je to zvýší mnohem více, než to vypadá. Protože jeden rotační disk má pro jednoho klienta opravdu velmi vysoký výkon. Ale už se dvěma to padá mnohem níže než na polovinu. Takže zaplavit "rotačák" mnoha klienty je stejně blbost.
Právě proto je lepší, jak už tady bylo psáno, nastavit ty limity velmi rozumně dle HW pod tím, a aktuální nedostupnost toho HW si vyřídit jinde.
Třeba tak, že příklad: mám db; nad tím apache se všema modama pro python, php; nad tím je nginx. DB má nastavení počet connexí, apache má nastaven počet workerů menší než počet conn do db. Nginx, při nemožnosti se dostat na apache, tak klientovi pošle statickou stránku. A ta statická stránka může být generovaná. Takže "jednou za 10 minut" se vygeneruje statická stránka s nějakými informacemi a tyto informace klient dostane v případě, že backend nestíhá. Takže všechny vrstvy jedou v nějakém svém pohodlném režimu. DB rozumně využívá HW (mnohem lépe, než při absurdním počtu připojení), apache je nastaven dle db a dle cpu a nginx dělá to, co mu jde nejlépe, tedy servíruje statický obsah. A ten statický obsah se dynamicky mění ;-). Jednou za "hodinu".
Vsude, kde se clovek podiva, vsude je nejaky fyzicky limit (silnice, chodniky, trubky etc). Vzdy dojde k zpomaleni "provozu", posklada se to tam, nikdy se to "nevyhodi".
Tahle analogie vůbec nefunguje. Stačí se podívat třeba na elektřinu. Velká zátěž, snížení frekvence, rozfázování sítě, globální blackout. Proto je nutné v nějaký případech části sítě odpojit.