Tato příručka vám pomůže učinit důležitá rozhodnutí o prostředcích, které je třeba použít k provozu Edjet LMS ve vašem prostředí.
Osnova článku:
Před nastavením prostředí (serveru) a nasazením Edjet LMS Server do něj doporučujeme zkontrolovat základní systémové požadavky a také provést několik rozhodnutí o konfiguraci zdrojů (hardwaru) na základě očekávané pracovní zátěže.
Nejprve byste si měli položit několik základních otázek o charakteristikách provozu:
Na základě těchto údajů a několika jednoduchých výpočtů byste měli být schopni se rozhodnout:
Rychlejší procesor je lepší pro latenci aplikace.
Více procesorů (jader) je lepší pro zpracování většího počtu souběžně pracujících uživatelů.
Vzhledem k tomu, že stack LAPP běžící na unixových strojích je velmi dobře škálovatelný pomocí vícevláknové architektury, největší vliv na výkon má více jader (vláken nebo vCPU v cloudu). To je nejdůležitější zejména pro prostředí s vysokou souběžností.
Chcete-li pochopit vliv počtu jader a zjistit, co je možné zvládnout s různými konfiguracemi, podívejte se na výkonostní report níže.
Je důležité mít dostatek paměti pro pracovní zátěž, abyste se vyhnuli swapování do pomalejšího úložiště.
Množství operační paměti má obvykle největší vliv na výkon, pokud jí není dostatek. Získejte jí co nejvíce. Na druhou stranu samozřejmě není hospodárné přeceňovat potřebnou paměť. Může to být velmi drahá chyba.
Pro výpočet operační paměti je třeba odhadnout počet požadovaných souběžných uživatelů, průměrnou velikost procesů (Apache a PostgreSQL) kombinovaných v jednom požadavku HTTP a množství operační paměti využívané operačním systémem a dalšími službami.
Zatížení serveru v určitém okamžiku závisí na počtu současně pracujících uživatelů.
Ne na celkovém počtu uživatelských účtů a ne na počtu přihlášených uživatelů. Pod pojmem "souběžní uživatelé" se rozumí ti uživatelé, pro které server něco aktivně dělá - nejčastěji se jedná o odesílání požadavků HTTP kliknutím.
Vzhledem k tomu, že souběžná aktivita uživatelů je zcela náhodná, je obtížné ji měřit a vypočítat. Při výpočtu přesné souběžnosti je tedy možné striktně myslet pouze počet aktivních procesů webového serveru - souběžných procesů.
Každé kliknutí uživatele generuje požadavek HTTP na server a vyžaduje podproces Apache, a pokud je v dané části aplikace zapojena databáze, také podproces PostgreSQL.
Každý z nich spotřebovává určitou paměť a vyžaduje připojení k webovému serveru a databázi.
Edjet LMS je poměrně komplexní aplikace. Jeden požadavek HTTP, například vykreslení stránky s obsahem kurzu, vyžaduje přibližně 40-75 MB paměti RAM. Statisticky je více procesů složitějších, proto počítáme s průměrnou velikostí 68 MB*. To zahrnuje proces Apache i PostgreSQL.
* To má pouze informativní charakter. Použité prostředí: Edjet LMS Server 3.6.1, Debian 6 s 24 GB paměti. U různých verzí a konfigurací může být velikost opatrná. Velikost procesů Windows Serveru může být zcela odlišná! Prosíme, abyste si tuto otázku prověřili sami ve své konkrétní situaci.
Záleží na mnoha věcech. Nejlepším způsobem je nainstalovat konfiguraci podle vlastního výběru a zjistit, jaké jsou požadavky.
Další informace naleznete na:
Požadavky a nastavení prostředí pro Linux
Požadavky a nastavení prostředí pro systém Windows
Pro standardní linuxové distribuce vhodné pro webový server, pokud s tím nechcete trávit čas, použijte přibližně 1 GB na každých 8 GB instalované paměti.
Pro 150 souběžných procesů je to:
150 x 68 = 10,2 GB paměti RAM.
Takže vaše možnost bude pravděpodobně 16 GB RAM, takže přidejte další 2 GB pro operační systém:
10.2 + 2 = 12,2 GB
A máte také volnou paměť RAM pro další úlohy, jako je spouštění zálohování, např.
Vypočtené odhady* viz následující tabulka:
| Požadované množství souběžných procesů | Odhadované množství potřebné paměti RAM |
|---|---|
| 100 | 8 GB |
| 200 | 16 GB |
| 450 | 32 GB |
| 850 | 64 GB |
| 1700 | 128 GB |
| 3000 | 224 GB |
* pro zjednodušení předpokládejme jeden fyzický server určený pouze pro LMS
Rychlejší úložiště je lepší, zejména pro databázi SQL (viz níže).
Rychlé SSD jsou nejlepší volbou. V cloudu můžete použít volume s vyššími rezervovanými IOPS.
Můžete také nastavit specifické diskové pole pomocí RAID nebo jiné konfigurace/technologie určené pro rychlost.
Pokud používáte síťový disk (NAS), ujistěte se, že je k serveru připojen dostatečně rychlou linkou s nízkou latencí.
Ujistěte se, že je váš server připojen ke stabilní a rychlé lince k internetu.
Měli byste hledat alespoň střední výkon, ale pro větší nasazení se doporučuje připojení se šířkou pásma sítě 1 Gb/s.
Měli byste také zvážit prostředí s více servery nebo konkrétní cloudové řešení a možnosti, jako jsou spravované databáze, vyrovnávače zátěže nebo jiné.
Testování výkonu aplikace/serveru nelze správně provést bez správných nástrojů. Existuje mnoho nástrojů pro zátěžové nebo stresové testy, takže si vybereme alespoň tyto dva:
Apachebench je k dispozici již v základní instalaciApache.
ab je nástroj pro srovnávací testování serveru Apache Hypertext Transfer Protocol (HTTP). Je navržen tak, aby vám poskytl představu o tom, jak vaše současná instalace Apache funguje. To vám zejména ukáže, kolik požadavků za sekundu je vaše instalace Apache schopna obsloužit.
Ovládá se z příkazového řádku. Opensource.
http://httpd.apache.org/docs/2.2/programs/ab.html
Desktopová aplikace Apache JMeter™ je software s otevřeným zdrojovým kódem, 100% čistá aplikace v jazyce Java určená k testování funkčního chování a měření výkonu. Původně byl navržen pro testování webových aplikací, ale od té doby se rozšířil i na další testovací funkce.
JMeter pěkně simuluje souběžné uživatele, umí exportovat logy do CSV,...
Opensource, napsaný v jazyce JAVA. Má uživatelské rozhraní, které umožňuje nastavit zátěžové testy pro neprogramátory.
https://jmeter.apache.org
Stáhněte si papírový report o výkonu serveru Edjet LMS ve formátu PDF se všemi údaji a grafy.
Na straně serveru jsou možné optimalizace, které zrychlí systém LMS.
Předpokládá se, že bude vyladěn na základě analýzy reálné situace, aby se určila úzká místa, a změřen pomocí syntetických testů před uvedením do produkce.
Nejčastější jsou problémy s výkonem databáze.
Databáze je jen tak rychlá, jako vaše úložiště. Rychlé úložiště může výrazně zvýšit výkon Edjet LMS Server.
Pokud vám vadí cena, můžete si nastavit 2 úložiště:
Zvažte také možnost přesunout SQL do specializovaných cloudových služeb, jako je AWS RDS, které nabízejí pokročilé možnosti výkonu.
Konfigurace databáze může pomoci databázi lépe se přizpůsobit pracovnímu zatížení. Edjet LMS Server funguje dobře s výchozím nastavením, pokud nenastanou některé specifické situace.
Tyto optimalizace lze provést poměrně snadno, ale neočekávejte velký nárůst výkonu, pokud databáze nebyla původně špatně nakonfigurována.
Všechny změny doporučujeme provádět pomocí souboru PostgreSQL .conf. Po změnách restartujte PostgreSQL.
Všechna následující nastavení jsou provedena na PostgreSQL 8.4 v Debianu 6 s 24 GB RAM.
| Možnost | Doporučená hodnota |
|---|---|
| shared_buffers* | Nastavení alokace 25 % volné paměti pro PostgreSQL - 5,5 GB. |
| effective_cache_size* | Nastavení přidělení 50 % volné paměti pro PostgreSQL - 11 GB. |
| max_connections | Nastavte alespoň na hodnotu Apache MaxClients. |
* je třeba změnit kernel SHMMAX na hodnotu kombinovaného potřebného množství paměti, v tomto případě 50 % dostupné volné paměti s trochou volného místa - 12 GB.
Příklad: Jak změnit volbu SHMMAX v Debianu 6
Vyladění parametrů Kernel podle potřeb webového serveru a postgresu (SHMMAX atd.).
Problémy s výkonem SQL lze často vyřešit optimalizací databázových dotazů, pohledů a funkcí. Pro zrychlení a snížení zátěže velkých tabulek a často přistupovaných dat lze také vytvořit indexy.
Obě techniky vyžadují úpravu a testování aplikace, ale jsou obvykle velmi účinné, pokud jsou provedeny správně.
K odhalení a odstranění problémů s výkonem SQL by měly být použity specializované nástroje pro profilování SQL.
Pokud je úzkým místem počet připojení, můžete nastavit "pgpool" nebo jiný software pro sdružování připojení.
Výkon můžete zvýšit pomocí různých pokročilých nastavení, jako jsou repliky pro čtení, přesun databází do cloudu, kde je k dispozici funkce automatického škálování (služby jako AWS RDS) atd.
Webový server je zřídkakdy úzkým hrdlem výkonu, ale pokud se vyskytnou problémy, můžete se pokusit podniknout některé kroky i tímto směrem.
Všechny změny doporučujeme provádět pomocí souboru Apache .conf.
Po změnách restartujte webový server (stop+start nemusí stačit).
Všechna následující nastavení jsou provedena na Apache 2.2.16 v Debianu 6
| Možnost | Doporučená hodnota |
|---|---|
| MaxClients | Nastaveno na počet vypočtených souběžných procesů při překročení hodnoty 256 je třeba změnit také volbu ServerLimit (výchozí hodnota je 256), je třeba ji přidat (ve výchozím nastavení není uvedena). |
| KeepAliveTimeout | Pokud se jedná o problém, nastavte toto číslo na nižší hodnoty (např. 5s) a poté na výchozí hodnotu (15s). Doporučujeme ji nastavit na základě reálných testů a reálného publika. |
Zapnutí funkce zlib.output_compression na serveru může pomoci snížit velikost přenášených dat.
Na druhou stranu je potřeba výpočetní výkon pro zpracování komprese za běhu, což může způsobit vysoké zatížení procesoru, což může vést k nižšímu celkovému výkonu.
Kompresi lze nastavit pro různé typy mimetypů:
Celý subsystém cachování je implementován ze dvou důvodů - rychlosti a zatížení serveru (zatížení zpracováním i šířkou pásma). Při interakci mezi serverem a klientem existuje několik typů ukládání do mezipaměti:
| Typ | Úroveň nebo technika |
|---|---|
| Mezipaměť aplikace |
|
| Vyrovnávací paměť prohlížeče | Vypršení mezipaměti v prohlížeči (nastavené pomocí hlaviček HTTP). |
Tento typ mezipaměti je implementován všude tam, kde je obrázek zpracováván prostřednictvím třídy imageGenerator.
Třída ImageGenerator
Tato třída je umístěna v souboru <approot>\class\class_imagegenerator.php
Třída používá tyto metody:
getSrc
Tato třída slouží k ukládání obrázků do mezipaměti. Pokud je na stránce použit obrázek z knihovny médií (kdekoli v systému, v administraci i na webu - v závislosti na použité šabloně), použije se následující postup:
Adresář / cesta k mezipaměti obrázků
Obě hodnoty jsou definovány v souboru config.php.
Výchozí hodnota je: tmp\cache\images
Možnosti formátu názvu souboru v mezipaměti
Tento formát je definován v souboru cfg.ini.php v sekci System v proměnné image_cache_format.
Formát se může skládat z následujících částí:
Výchozí formát je info_hash.ext
Příklad názvu souboru obrázku v mezipaměti
150_150__4f3b0172bb9866239cbf9ba1a3d5c23543a01518.jpg
Příklad syntaxe použití imagegenerátoru v šablonách:
ImageGenerator::loadSrc(security::image_getFullPath($value['image_path'] . $value['image_filename']), 180, 220, true, true, true);
Další příklady najdete v souboru code_examples.tpl.php.
Tento typ mezipaměti je implementován všude tam, kde je lokalizační řetězec zpracováván prostřednictvím třídy Lang.
Složka Cache je umístěna v úložišti systémových souborů: /tmp/cache/localization_strings/
