Hardwarové požadavky

Hardwarové požadavky

Při zajišťování hardwaru pro provoz Overleafu je hlavním faktorem, kolik souběžných uživatelů bude spouštět kompilace.

Pokud máte například licenci pro celkem 100 uživatelů, ale očekáváte, že současně jich bude pracovat jen ~5, postačí minimální instalace. Pokud očekáváte, že současně bude pracovat (a kompilovat) větší podíl uživatelů, měli byste zvážit server s vyššími parametry.

Minimální instalace

Pro základní provoz s přibližně 5 souběžnými uživateli jsou minimálním požadavkem 2 jádra a 3 GB paměti. Tento minimální požadavek bude stačit i pro větší skupiny s nižším souběžným využitím nebo tam, kde nevadí delší doby kompilace při vyšší zátěži.

Pokud pro svou malou instanci zvažujete souborový systém založený na NFS (Network File System), podívejte se prosím na tuto pasáž v části Řešení problémů.

Škálování

Jako orientační pravidlo platí, že pro zajištění vysoké a stálé úrovně služby je třeba k minimální instalaci přidat 1 jádro CPU a 1 GB paměti na každých 5–10 souběžných uživatelů.

Berte to pouze jako vodítko, protože potřebnou úroveň prostředků ovlivňují faktory jako velikost typických dokumentů (větší dokumenty spotřebují více prostředků pro kompilaci), jak často uživatelé kompilují a jaká je tolerance k delším dobám kompilace při vysoké zátěži.

Mnoho našich zákazníků chce nasadit Server Pro v celé organizaci nebo napříč velkými týmy. V takových situacích je pro nás obtížné doporučit konkrétní požadavky na nastavení, protože případy použití a dostupný hardware se mohou značně lišit.

Příklad 1	Příklad 2
Pokud provozujete instalaci Server Pro pro celkem 300 uživatelů a pravidelně očekáváte, že 30–60 z nich bude současně kompilovat dokumenty, 8 GB a 7 jader (5 jader + 5 GB + základ 2 jádra a 3 GB) by mělo poskytnout dostatek prostředků, aby vaši uživatelé měli trvale vysokou úroveň služby.	Jako příklad hardwarových požadavků pro větší nasazení: instalace Server Pro pro celkem 1 000 uživatelů byla úspěšně provozována na jediném serveru se dvěma 4jádrovými procesory a 32 GB systémové paměti. To potřebám týmu stačilo po celý uplynulý rok používání.

Zákazníci, kteří překračují limity jednoho velkého serveru, se mohou podívat na Horizontální škálování pro Server Pro.

Úložiště

U větších nasazení nedoporučujeme pro úložiště projektů a historie používat Network File System (NFS)/Amazon EFS/Amazon EBS a pro horizontální škálování je výslovně nepodporujeme.

Chování těchto souborových systémů neposkytuje výkon a spolehlivost, které Server Pro při provozu ve velkém měřítku potřebuje. Když souborový systém nestíhá zátěž, aplikace se zasekává kvůli příliš mnoha blokujícím IO operacím. Tato zaseknutí mohou vést k překročení zámků založených na Redisu, což může následně vést k poškození dat projektů.

Místo toho doporučujeme používat objektové úložiště kompatibilní s S3. Pomalý výkon S3 ovlivňuje pouze nahrávání a stahování souborů, což vede jen ke zvýšenému počtu otevřených spojení k vašemu poskytovateli S3 a neovlivňuje chování zbytku aplikace. Server Pro navíc může pro požadavky S3 nastavit rozumné časové limity, což u operací souborového systému/IO na úrovni aplikace není možné.

Pro srovnání, GitLab zastává u své self-managed nabídky podobný postoj a nepodporuje NFS/Amazon EFS.

Konfigurace Nginx pro velká nasazení

Ve výchozím nastavení instance Overleaf Server omezuje počet spojení na 768. To zahrnuje trvalá spojení Websocket, navigaci HTML nejvyšší úrovně i požadavky AJAX. Po dosažení limitu se editor nemusí být schopen připojit, stránka editoru se nemusí načíst celá a požadavky na kompilaci mohou selhat. Nginx bude vracet odpovědi se stavem 500 a do var/log/nginx/error.log uvnitř kontejneru sharelatex zapíše worker_connections are not enough while connecting to upstream.

Nastavení worker_connections omezuje počet souběžných spojení, která nginx přijme na jeden worker. Počet workerů je řízen nastavením worker_processes a v naší konfiguraci nginx je ve výchozím stavu nastaven na 4.

Nginx ve srovnání s ostatními částmi systému nevykonává mnoho práce, takže tyto limity slouží jako pojistka, která brání tomu, aby systém zahltilo příliš mnoho spojení. Je lepší zahodit některá nadbytečná spojení včas, než zpomalit všechna spojení.

Instance Overleaf Server zpřístupňují proměnné prostředí pro úpravu těchto nastavení nginx:

• NGINX_WORKER_PROCESSES pro worker_processes (výchozí 4)

• NGINX_WORKER_CONNECTIONS pro worker_connections (výchozí 768)

• NGINX_KEEPALIVE_TIMEOUT pro keepalive_timeout (výchozí 65)

  Pokud před kontejnerem sharelatex běží další proxy (např. pro ukončení TLS), musí být NGINX_KEEPALIVE_TIMEOUT v instanci Overleaf Server větší než u předřazené proxy. Například s dalším procesem nginx na hostiteli Dockeru nginx-host uvádíme dva příklady:

• Výchozí hodnota NGINX_KEEPALIVE_TIMEOUT: použijte keepalive_timeout 60s (výchozí hodnota v upstreamu) v nginx-host

• Vlastní hodnota NGINX_KEEPALIVE_TIMEOUT=100s: použijte keepalive_timeout 90s (vlastní hodnota v upstreamu) v nginx-host

Rychlost CPU

LaTeX je jednovláknový program, což znamená, že může v jednu chvíli využívat pouze jedno jádro CPU. CPU je také hlavním omezením při kompilaci dokumentu. Čím rychlejší je jednojádrový výkon vašeho CPU, tím rychleji budete moci dokument zkompilovat. Více jader pomůže pouze tehdy, pokud se snažíte kompilovat více dokumentů, než máte volných jader CPU.