WiFi

Zátěžové testování. Standardní zátěžový test Zátěžový test 1s

Systém 1C zaujímá dominantní postavení na trhu automatizace pro malé a střední podniky. Pokud se společnost rozhodla účetní systém 1C, v ní pak většinou pracují téměř všichni zaměstnanci, od běžných specialistů až po management. V souladu s tím rychlost obchodních procesů společnosti závisí na rychlosti 1C. Pokud 1C pracuje neuspokojivou rychlostí, pak to přímo ovlivňuje práci celé společnosti a zisk.

Ve skutečnosti existuje tři způsoby zrychlení 1C:

Zvyšování kapacity hardwaru.
Optimalizace nastavení operačního systému a DBMS.
Optimalizace kódu a algoritmů v 1C.

První způsob vyžaduje nákup vybavení a licencí, třetí vyžaduje mnoho práce pro programátory a v důsledku toho oba způsoby znamenají značné finanční náklady. V první řadě je třeba věnovat pozornost programovací kód, protože žádné zvýšení kapacity serveru nemůže kompenzovat nesprávný kód. Každý programátor ví, že s několika řádky kódu je možné vytvořit proces, který plně zatíží zdroje jakéhokoli serveru.

Pokud je společnost přesvědčena o optimálnosti programového kódu a stále běží pomalu, obvykle se management rozhodne navýšit kapacitu serveru. V tuto chvíli se nabízí logická otázka: co chybí, jak moc a co je ve výsledku potřeba přidat.

Společnost 1C dává poměrně vágní odpověď na otázku, kolik zdrojů je potřeba, psali jsme o tom dříve v našich příspěvcích. A tak musíte nezávisle provádět experimenty a zjistit, na čem závisí výkon 1C. Experimenty s výkonem na EFSOL jsou popsány níže.

Při práci s 1C 8.2, zejména s konfiguracemi, které používají spravované formuláře, byl zaznamenán zvláštní fakt: 1C běží rychleji na pracovní stanici než na výkonném serveru. Navíc všechny vlastnosti pracovní stanice jsou horší než vlastnosti serveru.

Tabulka 1 – Konfigurace, na kterých bylo provedeno počáteční testování

Pracovní stanice vykazuje výkon o 155 % vyšší než server 1C s vynikajícím výkonem. Začali jsme zjišťovat, o co jde, a zužovali jsme okruh hledání.

Obrázek 1 - Měření výkonu na pracovní stanici pomocí Gilevova testu

První podezření bylo, že Gilevův test byl nedostatečný. Měření otevírání formulářů, odesílání dokumentů, generování zpráv atd. pomocí instrumentačních nástrojů ukázalo, že Gilevův test poskytuje proporcionální odhad skutečnou rychlost práce v 1C.

Počet a frekvence paměti RAM

Analýza informací dostupných na internetu ukázala, že mnozí píší o závislosti výkonu 1C na frekvenci paměti. Je to z frekvence a ne z hlasitosti. Rozhodli jsme se tuto hypotézu otestovat, protože na serveru máme frekvenci RAM 1066 MHz oproti 1333 MHz na pracovní stanici a množství RAM na serveru je již mnohem vyšší. Rozhodli jsme se dát ne 1066 Mhz, ale hned 800 Mhz, abychom více zviditelnili vliv závislosti výkonu na frekvenci paměti. Výsledek - produktivita klesla o 12 % a činila 39,37 jednotek. Nainstalovali jsme na server paměť s frekvencí 1333 Mhz místo 1066 Mhz a dosáhli mírného nárůstu výkonu - asi 11%. Produktivita byla 19,53 jednotek. V souladu s tím nejde o paměť, i když její frekvence mírně zvyšuje.

Obrázek 2 - Měření výkonu na pracovní stanici po snížení frekvence paměti RAM

Obrázek 3 - Měření výkonu na serveru po zvýšení frekvence RAM

Diskový subsystém

Další hypotéza se týkala diskového subsystému. Okamžitě vyvstaly dvě hypotézy:

SSD jsou lepší než disky SAS, i když jsou v raid 10.
iSCSI je pomalé nebo nefunguje správně.

Do pracovní stanice byl proto místo SSD nainstalován běžný SATA disk a se serverem totéž - základna byla umístěna na lokální SATA disk. V důsledku toho se měření výkonu nijak nezměnilo. S největší pravděpodobností se to děje, protože RAM je dostatek a disky se během testu prakticky žádným způsobem nepoužívají.

procesor

Procesory na serveru jsou samozřejmě výkonnější a jsou dva, ale frekvence je o něco nižší než na pracovní stanici. Rozhodli jsme se ověřit vliv frekvence procesoru na výkon: pro server nebyly po ruce žádné procesory s vyšší frekvencí, a tak jsme frekvenci procesoru na pracovní stanici snížili. Okamžitě jsme ji snížili na 1,6, aby se korelace projevila jasněji. Test ukázal, že výkon výrazně klesl, ale i s 1.6 procesorem pracovní stanice vydal téměř 28 kusů, což je téměř 1,5x více než na serveru.

Obrázek 4 - Měření výkonu na pracovní stanici s procesorem 1,6 GHz

grafická karta

Na internetu jsou informace, že grafická karta může ovlivnit výkon 1C. Zkusili jsme použít integrované video pracovní stanice, profesionální adaptér Nvidia NVIDIA® Quadro® 4000 2 Gb DDR5, stará grafická karta GeForce 16MbSDR. Během testu Gilev nebyl zaznamenán žádný významný rozdíl. Možná grafická karta stále ovlivňuje, ale v reálných podmínkách, když potřebujete otevřít spravované formuláře atd.

PROTI tento moment Existují dvě podezření, proč pracovní stanice běží rychleji i s výrazně horším výkonem:

PROCESOR. Typ procesoru na pracovní stanici je vhodnější pro 1C.
Čipová sada. Pokud jsou ostatní věci stejné, naše pracovní stanice má novější čipovou sadu, což může být důvod.

Plánujeme nákup potřebných komponent a pokračování v testech, abychom konečně zjistili, na čem výkon 1C ve větší míře závisí. Zatímco probíhá proces schvalování a nákupu, rozhodli jsme se provést optimalizaci, zejména proto, že to nic nestojí. Byly identifikovány následující kroky:

Fáze 1. Nastavení systému

Nejprve proveďte následující nastavení v systému BIOS a operačním systému:

V BIOSu serveru deaktivujte všechna nastavení, abyste šetřili výkon procesoru.
V operačním systému vyberte plán „Maximální výkon“.
Procesor je také vyladěn pro maximální výkon. To lze provést pomocí nástroje PowerSchemeEd.

Fáze 2. Nastavení serveru SQL a serveru 1C:Enterprise

V nastavení serveru DBMS a 1C:Enterprise provádíme následující změny.

Konfigurace protokolu sdílené paměti:
- Sdílená paměť bude povolena pouze na platformě počínaje 1C 8.2.17, v dřívějších verzích bude povoleno Named Pipe - poněkud nižší v rychlosti. Tato technologie funguje pouze v případě, že jsou na stejném fyzickém nebo virtuálním serveru nainstalovány služby 1C a MSSQL.
Doporučuje se přepnout službu 1C do režimu ladění, paradoxně to zvyšuje výkon. Ve výchozím nastavení je ladění na serveru zakázáno.
Nastavení SQL serveru:
- Potřebujeme pouze server, zbytek služeb, které k němu patří a možná je někdo používá, jen zpomalují práci. Zastavujeme a deaktivujeme takové služby jako: Fulltextové vyhledávání (1C má vlastní mechanismus fulltextového vyhledávání), Integrační služby atd.
- Nastavte maximální množství paměti přidělené serveru. To je nutné, aby sql server počítal s tímto množstvím a předem vyčistil paměť.
- Nastavte maximální počet vláken (Maximum work threads) a nastavte zvýšenou prioritu serveru (Boost priority).

Fáze 3. Nastavení fungující databáze

Po optimalizaci DBMS serveru a 1C:Enterprise přistoupíme k nastavení databáze. Pokud základ ještě nebyl rozbalen ze souboru .dt a znáte jeho přibližnou velikost, je lepší ihned označit inicializační velikost primárního souboru pomocí „>=“ velikosti základny, ale jedná se o věc vkusu, při nasazení ještě poroste. Ale musí být specifikováno automatické zvýšení velikosti: přibližně 200 MB na databázi a 50 MB na protokol, protože. výchozí hodnoty - růst o 1 MB a o 10 % velmi zpomalit server, když potřebuje zvětšit soubor s každou 3. transakcí. Je také lepší určit úložiště základního souboru a souboru protokolu na jiném fyzické disky nebo skupiny RAID, pokud používáte pole RAID, a omezit růst protokolu. Doporučuje se přesunout soubor Tempdb do vysokorychlostního pole, protože k němu DBMS přistupuje poměrně často.

Fáze 4. Nastavení naplánovaných úloh

Naplánované úlohy se vytvářejí zcela jednoduše pomocí Plánu údržby v sekci Správa pomocí grafických nástrojů, takže nebudeme podrobně popisovat, jak se to dělá. Pojďme se pozastavit nad tím, jaké operace je potřeba provést pro zlepšení výkonu.

Indexy by měly být defragmentovány a statistiky denně aktualizovány. pokud je fragmentace indexu > 25 %, výrazně to sníží výkon serveru.
Defragmentace a aktualizace statistik – provádí se rychle a nevyžaduje odpojování uživatelů. Doporučuje se také provádět denně.
Úplná reindexace – provádí se se zámkem databáze, doporučuje se ji provádět alespoň jednou týdně. Po úplném přeindexování jsou indexy přirozeně defragmentovány a statistiky jsou okamžitě aktualizovány.

V důsledku toho se nám pomocí doladění systému, SQL serveru a pracovní základny podařilo zvýšit produktivitu o 46 %. Měření byla provedena pomocí přístroje 1C a pomocí Gilevova testu. Ten ukázal 25,6 jednotek oproti 17,53, které byly původně.

Stručný závěr

Výkon 1C moc nezávisí na frekvenci RAM. Při dosažení dostatečného objemu nemá další rozšiřování paměti smysl, protože nevede ke zvýšení výkonu.
Výkon 1C nezávisí na grafické kartě.
Výkon 1C nezávisí na diskovém subsystému za předpokladu, že není překročena fronta pro čtení nebo zápis disků. Pokud je nainstalován SATA disky a nepřekročili tedy frontu Instalace SSD nezlepší výkon.
Výkon je dost závislý na frekvenci procesoru.
Při správné konfiguraci operačního systému a MSSQL serveru je možné dosáhnout zvýšení výkonu 1C o 40-50% bez jakýchkoliv materiálových nákladů.

POZORNOST! Velmi důležitý bod! Všechna měření byla provedena na testovací základně pomocí Gilevova testu a instrumentačních nástrojů 1C. Chování skutečné databáze se skutečnými uživateli se může lišit od získaných výsledků. Například v testovací databázi jsme nenašli žádnou závislost výkonu na grafické kartě a velikosti RAM. Tyto závěry jsou spíše pochybné a v reálných podmínkách mohou mít tyto faktory významný vliv na výkon. Při práci s konfiguracemi, které používají spravované formuláře, je grafická karta důležitá a výkonná. GPU urychluje práci z hlediska kreslení rozhraní programu, vizuálně se to projevuje více rychlá práce 1C.

Běží váš 1C pomalu? Objednejte si IT údržbu počítačů a serverů u specialistů EFSOL s mnohaletými zkušenostmi nebo přeneste své 1C na výkonný virtuální server 1C odolný proti chybám.

Systémová integrace. Poradenství

Hlavním účelem psaní článku není opakovat zjevné nuance těm správcům (a programátorům), kteří ještě nezískali zkušenosti s 1C.

Sekundární cíl, pokud mám nějaké nedostatky, tak mě na to nejrychleji upozorní Infostart.

Test V. Gileva se již stal jakýmsi „de facto“ standardem. Autor na svých stránkách dal celkem srozumitelná doporučení, ale já prostě dám nějaké výsledky a vyjádřím se k nejpravděpodobnějším chybám. Výsledky testů na vašem zařízení se samozřejmě mohou lišit, toto je pouze vodítko, co by mělo být a o co se můžete snažit. Chci hned poznamenat, že změny je třeba provádět krok za krokem a po každém kroku zkontrolovat, jaký výsledek přinesl.

Na Infostartu jsou podobné články, do příslušných sekcí na ně dám odkazy (pokud mi něco chybí, řekněte mi to prosím do komentářů, doplním). Předpokládejme, že zpomalíte 1C. Jak diagnostikovat problém a jak pochopit, kdo je na vině, správce nebo programátor?

Počáteční údaje:

Testovaný počítač, hlavní pokusný králík: HP DL180G6, 2*Xeon 5650, 32 Gb, Intel 362i , Win 2008 r2. Pro srovnání, srovnatelné výsledky v jednovláknovém testu ukazuje Core i3-2100. Zařízení bylo speciálně převzato ne nejnovější, na moderním zařízení jsou výsledky znatelně lepší.

Pro testování vzdálených serverů 1C a SQL, SQL server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Pro testování 10Gbit sítě byly použity adaptéry Intel 520-DA2.

Verze souboru. (základna leží na serveru ve sdílené složce, klienti jsou připojeni v síti, protokol CIFS/SMB). Algoritmus krok za krokem:

0. Přidat do souborový server Gilevova testovací databáze do stejné složky jako hlavní databáze. Připojíme se z klientského počítače, spustíme test. Výsledek si pamatujeme.

Rozumí se, že i pro staré počítače před 10 lety (Pentium na patici 775 ) doba od kliknutí na štítek 1C:Enterprise do zobrazení okna databáze by měla být kratší než minuta. ( Celeron = pomalá práce).

Pokud je váš počítač horší než zapnuté Pentium zásuvka 775 od 1 GB paměť s náhodným přístupem, pak s vámi sympatizuji a bude pro vás obtížné dosáhnout pohodlné práce na 1C 8.2 ve verzi souboru. Zvažte buď upgrade (dlouho opožděný), nebo přechod na terminál (nebo web, v případě tenkých klientů a spravované formuláře) server.

Pokud na tom počítač není hůř, tak můžeš správce kopnout. Minimálně zkontrolujte fungování sítě, antiviru a ovladače ochrany HASP.

Pokud Gilevův test v této fázi ukázal 30 "papoušků" a více, ale pracovní základna 1C stále funguje pomalu - otázky jsou již pro programátora.

1. Pro vodítko, kolik dokáže klientský počítač "vymáčknout", zkontrolujeme provoz pouze tohoto počítače bez sítě. Nasadili jsme testovací základnu místní počítač(za velmi rychlý disk). Pokud klientský počítač nemá normální SSD, vytvoří se ramdisk. Zatím nejjednodušší a bezplatný je Ramdisk enterprise.

K testování verze 8.2 stačí 256 MB ramdisku a! Nejdůležitější věc. Po restartu počítače s funkčním ramdiskem by měl mít volných 100-200 MB. Bez ramdisku by tedy pro normální provoz volné paměti mělo být 300-400 MB.

Pro testování verze 8.3 stačí 256 MB ramdisk, ale je potřeba více volné RAM.

Při testování je potřeba se podívat na vytížení procesoru. V případě blízkém ideálu (ramdisk) lokální soubor 1c zatěžuje během provozu 1 jádro procesoru. Pokud tedy během testování není jádro vašeho procesoru plně zatíženo, hledejte slabá místa. Trochu emotivní, ale obecně správný, je popsán vliv procesoru na chod 1C. Jen pro informaci, i na moderních Core i3 s vysokou frekvencí jsou čísla 70-80 zcela reálná.

Nejčastější chyby v této fázi.

a) Nesprávně nakonfigurovaný antivirus. Antivirů je mnoho, nastavení u každého je jiné, mohu jen říci, že při správné konfiguraci web ani Kaspersky 1C neruší. Při "výchozím" nastavení - lze odebrat asi 3-5 papoušků (10-15%).

b) Režim výkonu. Z nějakého důvodu tomu málokdo věnuje pozornost a efekt je nejvýraznější. Pokud potřebujete rychlost, musíte to udělat na klientských i serverových počítačích. (Gilev má dobrý popis. Jediná výhrada, u některých základní desky Pokud vypnete Intel SpeedStep, nemůžete zapnout TurboBoost).

Zkrátka při provozu 1C se hodně čeká na odezvu ostatních zařízení (disk, síť atd.). Při čekání na odezvu, pokud je režim výkonu vyrovnaný, procesor sníží frekvenci. Ze zařízení přichází odezva, 1C (procesor) musí pracovat, ale první cykly jdou se sníženou frekvencí, pak frekvence stoupá - a 1C opět čeká na odezvu zařízení. A tak - mnoho setkrát za sekundu.

Režim výkonu můžete (a nejlépe) povolit na dvou místech:

Přes BIOS. Zakázat režimy C1, C1E, Intel C-state (C2, C3, C4). V různých bios se nazývají různě, ale význam je stejný. Hledání po dlouhou dobu, je vyžadován restart, ale pokud jste to udělali jednou, můžete zapomenout. Pokud je vše v BIOSu provedeno správně, rychlost bude přidána. Na některých základních deskách lze nastavení BIOSu nastavit tak, že režim Výkon Windows nebude hrát roli. (Příklady nastavení BIOSu v Gilevu). Tato nastavení se týkají hlavně serverových procesorů nebo "pokročilého" BIOSu, pokud jste jej nenašli ve svém systému a nemáte Xeon - je to v pořádku.

Ovládací panel – Napájení – Vysoký výkon. Mínus - pokud počítač nebyl delší dobu v servisu, bude silněji bzučet ventilátorem, bude se více zahřívat a spotřebovávat více energie. To je cena výkonu.

Jak zkontrolovat, zda je režim povolen. Spusťte Správce úloh - Výkon - Monitor prostředků - CPU. Čekáme, dokud nebude procesor ničím zaneprázdněn.

Toto jsou výchozí nastavení.

BIOS C-stav zahrnuta,

režim vyváženého výkonu

BIOS C-stav zahrnuta, vysoce výkonný režim

U Pentia a Core se můžete zastavit tam,

z Xeonu můžete ještě vymáčknout nějaké "papoušky".

BIOS C-stav vypnuto, vysoce výkonný režim.

Pokud nepoužíváte Turbo boost – tak by to mělo vypadat

server vyladěný na výkon

A teď ta čísla. Připomenu: Intel Xeon 5650, ramdisk. V prvním případě test ukazuje 23,26, ve druhém - 49,5. Rozdíl je téměř dvojnásobný. Čísla se mohou lišit, ale poměr zůstává téměř stejný pro Intel Core.

Vážení administrátoři, můžete 1C nadávat, jak chcete, ale pokud koncoví uživatelé potřebují rychlost, musíte povolit režim vysokého výkonu.

c) Turbo Boost. Nejprve musíte pochopit, zda například váš procesor tuto funkci podporuje. Pokud ano, pak stále můžete zcela legálně získat nějaký výkon. (Nechci se dotknout problémů přetaktování, zejména serverů, dělejte to na vlastní nebezpečí a riziko. Souhlasím však s tím, že zvýšení rychlosti sběrnice ze 133 na 166 poskytuje velmi znatelné zvýšení rychlosti i odvodu tepla)

Jak povolit Turbo zrychlení napsaný např. Ale! Pro 1C existují určité nuance (ne nejzřetelnější). Potíž je v tom, že maximální účinek turbo boostu se projeví při zapnutém C-stavu. A vznikne něco jako tento obrázek:

Upozorňujeme, že násobič je maximální, rychlost jádra je nejkrásnější, výkon je vysoký. Ale co se stane v důsledku 1s?

	Faktor	Rychlost jádra (frekvence), GHz	CPU-Z Single Thread	Gilev Ramdisk test verze souboru	Gilev Ramdisk test klient-server
bez turbo boostu
C-stav vypnutý, turbo boost				53.19	40,32
C-stav zapnutý, turbo boost			1080	53,13	23,04

Ale nakonec se ukazuje, že podle testů výkonu CPU je napřed varianta s násobitelem 23, podle Gilevových testů v souborové verzi je výkon s násobitelem 22 a 23 stejný, ale v klient-server verze, varianta s násobitelem 23 horor horor horor (i když je C-state nastaven na úroveň 7, je stále pomalejší než s vypnutým C-statem). Proto doporučení, ověřte si obě možnosti sami a vyberte si z nich tu nejlepší. Každopádně rozdíl mezi 49,5 a 53 papoušky je dost výrazný, tím spíš, že je to bez větší námahy.

Závěr – turbo boost je třeba započítat. Připomínám, že nestačí povolit v BIOSu položku Turbo boost, je potřeba se podívat i na další nastavení (BIOS: QPI L0s, L1 - zakázat, vyžadovat scrubbing - zakázat, Intel SpeedStep - povolit, Turbo boost - Ovládací panel - Napájení - Vysoký výkon). A ještě bych se (i u verze souboru) zastavil u možnosti, kdy je c-state vypnutý, i když násobiče je tam méně. Získejte něco takového...

Poměrně kontroverzním bodem je frekvence pamětí. Například frekvence paměti se ukazuje jako velmi vlivná. Moje testy takovou závislost neodhalily. Nebudu porovnávat DDR 2/3/4, ukážu výsledky změny frekvence v rámci stejné čáry. Paměť je stejná, ale v BIOSu vnucujeme nižší frekvence.

A výsledky testů. 1C 8.2.19.83, pro verzi souboru místní ramdisk, pro klient-server 1C a SQL na jednom počítači, Sdílená paměť. Turbo boost je deaktivován v obou možnostech. 8.3 ukazuje srovnatelné výsledky.

Rozdíl je v rámci chyby měření. Konkrétně jsem vytáhl snímky obrazovky CPU-Z, abych ukázal, že se změnou frekvence se mění i další parametry, stejná latence CAS a zpoždění RAS na CAS, které vyrovnává změnu frekvence. Rozdíl bude ve chvíli, kdy se paměťové moduly fyzicky změní, z pomalejších na rychlejší, ale ani tam nejsou čísla příliš podstatná.

2. Když jsme přišli na procesor a paměť klientského počítače, přejdeme na další velmi důležité místo - síť. O ladění sítě bylo napsáno mnoho knih, existují články o Infostartu ( a další), zde se tomuto tématu nebudu věnovat. Před zahájením testování 1C se prosím ujistěte, že iperf mezi dvěma počítači ukazuje celé pásmo (pro 1Gbit karty - no, alespoň 850 Mbit, ale lépe 950-980), že jsou dodržovány Gilevovy rady. Pak - nejjednodušším testem práce bude, kupodivu, zkopírování jednoho velkého souboru (5-10 gigabajtů) přes síť. Nepřímým znakem normálního provozu v síti 1 Gbps bude průměrná rychlost kopírování 100 Mb / s, dobrá práce - 120 Mb / s. Chci vás upozornit na skutečnost, že zatížení procesoru může být také slabým místem (včetně). SMB protokol na Linuxu je dost špatně paralelizovaný a za provozu může celkem snadno „sežrat“ jedno jádro procesoru a už ho nespotřebovat.

A dál. S nastavením pro výchozí okna klient nejlépe funguje se serverem Windows (nebo dokonce okna fungují stanice) a protokol SMB / CIFS, linuxový klient (debian, ubuntu se na zbytek nedívalo) funguje lépe s linuxem a NFS (funguje i s SMB, ale papoušci jsou na NFS vyšší). To, že se při lineárním kopírování win-linux serveru na nfs zkopíruje do jednoho streamu rychleji, nic neznamená. Vyladění debianu pro 1C je téma na samostatný článek, ještě se na to nechystám, i když můžu říct, že v souborové verzi jsem dokonce dostal o něco lepší výkon než Win verze na stejném vybavení, ale s postgresem s uživatelé nad 50 let mám stále všechno velmi špatné.

Nejdůležitější věc , kterou znají "spálení" správci, ale začátečníci neberou v úvahu. Existuje mnoho způsobů, jak nastavit cestu k databázi 1c. Můžete udělat \\server\share, můžete \\192.168.0.1\share, můžete net use z: \\192.168.0.1\share (a v některých případech bude tato metoda také fungovat, ale ne vždy) a poté určit disk Z. Zdá se, že všechny tyto cesty směřují na stejné místo, ale pro 1C existuje pouze jeden způsob, který poskytuje poměrně stabilní výkon. Zde je to, co musíte udělat správně:

PROTI příkazový řádek(nebo v zásadách, nebo podle toho, co vám vyhovuje) - použijte čisté písmeno jednotky: \\server\share. Příklad: čisté použití m:\\server\bases. Konkrétně zdůrazňuji NE IP adresu, jmenovitě název server. Pokud server není viditelný podle názvu - přidejte jej do DNS na serveru nebo lokálně na hostitelský soubor. Ale odvolání musí být jmenovité. Podle toho na cestě do databáze přistupte na tento disk (viz obrázek).

A teď v číslech ukážu, proč takové rady. Počáteční údaje: karty Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. OS Win 2008 R2, Win 7, Debian 8. Nejnovější ovladače, aktualizace použity. Před testováním jsem se ujistil, že Iperf dává plnou šířku pásma (kromě 10 Gbit karet se ukázalo, že vytlačí jen 7,2 Gbit, později uvidím proč, testovací server ještě není správně nakonfigurován). Disky jsou různé, ale všude je SSD (speciálně vložený jediný disk pro testování, nic jiného se nenačítá) nebo raid z SSD. Rychlost 100 Mbit získáme omezením v nastavení adaptér Intel 362. Nebyl nalezen žádný rozdíl mezi 1 Gbit Intel 350 metal a 1 Gbit Intel X520-DA2 optikou (získanou omezením rychlosti adaptéru). Maximální výkon, turbo boost je vypnutý (jen pro srovnatelnost výsledků, turbo boost přidává o něco méně než 10% pro dobré výsledky, pro špatné výsledky to nemusí ovlivnit vůbec). Verze 1C 8.2.19.86, 8.3.6.2076. Neuvádím všechna čísla, ale jen ta nejzajímavější, aby bylo s čím porovnávat.

	Win 2008 - Win 2008 volání přes IP adresu	Win 2008 - Win 2008 Adresa podle jména	Win 2008 - Win 2008 Volání přes IP adresu	Win 2008 - Win 2008 Adresa podle jména	Win 2008 - Win 7 Adresa podle jména	Windows 2008 – Debian Adresa podle jména	Win 2008 - Win 2008 Volání přes IP adresu	Win 2008 - Win 2008 Adresa podle jména
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1С 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Závěry (z tabulky az osobní zkušenosti. Platí pouze pro verzi souboru):

Po síti můžete získat docela normální čísla pro práci, pokud je tato síť normálně nakonfigurována a cesta je správně napsána v 1C. Dokonce i první Core i3s mohou dát 40+ papoušků, což je docela dobré, a nejsou to jen papoušci, v reálné práci je rozdíl také znatelný. Ale! omezením při práci s více (více než 10) uživateli již nebude síť, zde stále stačí 1 Gbit, ale blokování při víceuživatelské práci (Gilev).

Platforma 1C 8.3 je mnohonásobně náročnější na kompetentní nastavení sítě. Základní nastavení- viz Gilev, ale mějte na paměti, že vše může ovlivnit. Zrychlení jsem viděl v tom, že odinstalovali (a nejen vypnuli) antivirus, v odstranění protokolů jako FCoE, ve změně ovladačů na starší, ale microsoftem certifikovanou verzi (zejména u levných karet jako asus a dlinks), v odstranění druhá síťová karta ze serveru. Mnoho možností, konfigurujte síť promyšleně. Může nastat situace, kdy platforma 8.2 poskytuje přijatelná čísla a 8.3 - dvakrát nebo dokonce vícekrát méně. Zkuste si pohrát s verzemi platformy 8.3, někdy získáte velmi velký efekt.

1C 8.3.6.2076 (možná později, přesnou verzi jsem ještě nehledal) přes síť je stále snazší nastavit než 8.3.7.2008. Od 8.3.7.2008 bylo možné dosáhnout normálního síťového provozu (u srovnatelných papoušků) jen párkrát, pro obecnější případ jsem to nemohl zopakovat. Moc jsem tomu nerozuměl, ale soudě podle footcloth z Process Exploreru tam záznam nejde tak, jako v 8.3.6.

Navzdory skutečnosti, že při práci na 100Mbps síti je její rozvrh zatížení malý (můžeme říci, že síť je volná), rychlost práce je stále mnohem nižší než na 1 Gbps. Důvodem je latence sítě.

Ceteris paribus (dobře fungující síť) pro 1C 8.2, připojení Intel-Realtek je o 10 % pomalejší než Intel-Intel. Ale realtek-realtek obecně dokáže z ničeho nic prudce klesnout. Proto pokud jsou peníze, je lepší mít síťové karty Intel všude, pokud nejsou peníze, dát Intel pouze na server (vaše KO). Jo a návodů na ladění síťových karet intel je mnohonásobně více.

Výchozí nastavení antiviru (například verze drweb 10) odebere asi 8-10% papoušků. Pokud to správně nakonfigurujete (povolíte procesu 1cv8 dělat vše, ačkoli to není bezpečné) - rychlost je stejná jako bez antiviru.

NEČTĚTE Linuxové guru. Server se sambou je skvělý a zdarma, ale pokud na server dáte Win XP nebo Win7 (nebo ještě lépe - serverový OS), pak ve verzi souboru 1c bude fungovat rychleji. Ano, jak samba, tak zásobník protokolů a nastavení sítě a mnohem více v debian / ubuntu jsou dobře vyladěné, ale toto je doporučeno pro specialisty. Nemá smysl instalovat Linux s výchozím nastavením a pak říkat, že je pomalý.

Je dobré otestovat disky připojené přes net use s fio . Alespoň bude jasné, zda se jedná o problémy s platformou 1C, nebo se sítí / diskem.

U varianty pro jednoho uživatele mě nenapadají testy (nebo situace), kdy by byl viditelný rozdíl mezi 1Gb a 10Gb. Jediným místem, kde 10Gbps pro verzi souboru dávalo lepší výsledky, bylo připojení disků přes iSCSI, ale to je téma na samostatný článek. Přesto si myslím, že na souborovou verzi stačí 1Gbit karty.

Proč se 100 Mbit sítí funguje 8.3 znatelně rychleji než 8.2 - nechápu, ale skutečnost se stala. Všechna ostatní zařízení, všechna ostatní nastavení jsou naprosto stejná, akorát v jednom případě se testuje 8.2 a ve druhém - 8.3.

Nenaladěno NFS win - win nebo win-lin dává 6 papoušků, nezahrnul do tabulky. Po naladění jsem dostal 25, ale je nestabilní (náběh v měření je více než 2 jednotky). Momentálně nemohu doporučit pomocí oken a protokol NFS.

Po všech nastaveních a kontrolách spouštíme test znovu z klientského počítače, radujeme se z vylepšeného výsledku (pokud to vyšlo). Pokud se výsledek zlepšil, papoušků je více než 30 (a zejména více než 40), současně pracuje méně než 10 uživatelů a pracovní databáze se stále zpomaluje - téměř určitě problém programátora (nebo jste již dosáhl vrcholu možností verze souboru).

terminálový server. (základna leží na serveru, klienti jsou připojeni v síti, protokol RDP). Algoritmus krok za krokem:

0. Přidejte testovací databázi Gilev na server do stejné složky jako hlavní databáze. Připojíme se ze stejného serveru a spustíme test. Výsledek si pamatujeme.

1. Stejným způsobem jako ve verzi souboru nastavíme dílo. V případě terminálového serveru obecně hraje hlavní roli procesor (rozumějte, že neexistují žádné zjevné slabiny, jako je nedostatek paměti nebo velké množství zbytečného softwaru).

2. Nastavení síťových karet v případě terminálového serveru nemá na provoz 1s prakticky žádný vliv. Chcete-li poskytnout "zvláštní" komfort, pokud váš server rozdává více než 50 papoušků, můžete si pohrát s novými verzemi protokolu RDP, jen pro pohodlí uživatelů, rychlejší odezvu a rolování.

3. Při aktivní práci velký počet uživatelů (a zde již můžete zkusit připojit 30 lidí k jedné základně, pokud to zkusíte) je velmi žádoucí osadit SSD disk. Z nějakého důvodu se předpokládá, že disk nijak zvlášť neovlivňuje činnost 1C, ale všechny testy se provádějí s mezipamětí řadiče povolenou pro zápis, což je špatně. Testovací základna je malá, vejde se do cache, proto ta vysoká čísla. Na skutečných (velkých) databázích bude vše úplně jinak, takže cache je pro testy zakázána.

Například jsem ověřil práci Gilev testu s různými možnostmi disku. Dal jsem disky z toho, co bylo po ruce, jen abych ukázal tendenci. Rozdíl mezi 8.3.6.2076 a 8.3.7.2008 je malý (ve verzi Ramdisk Turbo boost 8.3.6 dává 56.18 a 8.3.7.2008 dává 55.56, v ostatních testech je rozdíl ještě menší). Spotřeba energie - maximální výkon, turbo boost deaktivován (pokud není uvedeno jinak).

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Jeden SSD	ramdisk		Mezipaměť povolena RAID řadič
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1С 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Přiložená cache řadiče RAID eliminuje všechny rozdíly mezi disky, čísla jsou stejná pro sat i sas. Testování s ním pro malé množství dat je zbytečné a není indikátorem.

U platformy 8.2 je rozdíl ve výkonu mezi možnostmi SATA a SSD více než dvojnásobný. Nejedná se o překlep. Pokud se při testu na SATA discích podíváte na monitor výkonu. pak je jasně vidět "Čas aktivního disku (v %)" 80-95. Ano, pokud povolíte mezipaměť pro zápis samotných disků, rychlost se zvýší na 35, pokud povolíte mezipaměť řadiče raid - až 49 (bez ohledu na to, které disky jsou v tuto chvíli testovány). Ale to jsou syntetickí papoušci cache, v reálné práci s velkými databázemi nikdy nebude 100% zápis cache hit ratio.

Rychlost i levných SSD (testoval jsem na Agility 3) stačí na to, aby verze souboru fungovala. Zápisový zdroj je věc druhá, zde je potřeba hledat v každém konkrétním případě, je jasné, že Intel 3700 to bude mít o řád vyšší, ale tam tomu odpovídá cena. A ano, chápu, že při testování SSD disku ve větší míře testuji i cache tohoto disku, reálné výsledky budou menší.

Nejsprávnější (z mého pohledu) řešení by bylo vyčlenit 2 SSD disky na mirror raid pro souborovou základnu (nebo více souborových základen) a nic jiného tam nedávat. Ano, se zrcátkem se SSD opotřebovávají stejně a to je mínus, ale alespoň jsou nějak pojištěny proti chybám v elektronice řadiče.

Hlavní výhody SSD disků pro verzi souboru se projeví, když existuje mnoho databází a každá s několika uživateli. Pokud existují 1-2 základny a uživatelé v oblasti 10, budou stačit disky SAS. (ale v každém případě - podívejte se na načítání těchto disků alespoň přes perfmon).

Hlavní výhody terminálového serveru jsou, že může mít velmi slabé klienty a nastavení sítě ovlivní terminálový server mnohem méně (opět vaše KO).

Závěry: pokud terminálový server spusťte test Gilev (ze stejného disku, kde jsou pracovní základny) a v těch okamžicích, kdy se pracovní základna zpomaluje, a test Gilev ukazuje dobrý výsledek (nad 30) - pak je za pomalé s největší pravděpodobností programátor provoz hlavní pracovní základny.

Pokud Gilev test ukazuje malá čísla a máte jak procesor s vysokou frekvencí, tak rychlé disky, tak zde musí správce vzít alespoň perfmon a všechny výsledky někam zaznamenat a sledovat, pozorovat, vyvozovat závěry. Žádná definitivní rada nebude.

Možnost klient-server.

Testy byly provedeny pouze 8.2, tk. Na 8.3 vše docela vážně závisí na verzi.

Pro testování jsem si vybral různé varianty servery a síť mezi nimi ukázat hlavní trendy.

	SQL: Xeon E5-2630	SQL: Xeon E5-2630 Fibre channel-SSD	SQL: Xeon E5-2630 Fibre channel - SAS	SQL: Xeon E5-2630 Místní SSD	SQL: Xeon E5-2630 Fibre channel-SSD	SQL: Xeon E5-2630 Místní SSD	1C: Xeon 5650 =	1C: Xeon 5650 = sdílená paměť	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1С 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

Zdá se, že jsem zvážil všechny zajímavé možnosti, pokud vás zajímá něco jiného - napište do komentářů, pokusím se to udělat.

SAS na úložišti je pomalejší než místní SSD, i když úložiště má velké velikosti mezipaměti. SSD a místní a úložné systémy pro test Gilev pracují srovnatelnými rychlostmi. Neznám žádný standardní vícevláknový test (nejen záznamy, ale veškeré vybavení) kromě zátěže 1C z MCC.

Změna serveru 1C z 5520 na 5650 přinesla téměř zdvojnásobení výkonu. Ano, konfigurace serveru se úplně neshodují, ale ukazuje to trend (nic překvapivého).

Zvýšení frekvence na serveru SQL má jistě efekt, ale ne stejný jako na serveru 1C, MS SQL server je dokonale schopen (pokud se ptáte) používat vícejádrovou a volnou paměť.

Změna sítě mezi 1C a SQL z 1 Gbps na 10 Gbps dává asi 10 % papoušků. Očekávalo se víc.

Povolení sdílené paměti stále poskytuje efekt, i když ne 15%, jak je popsáno. Ujistěte se, že to uděláte, je to rychlé a snadné. Pokud někdo dal SQL serveru během instalace pojmenovanou instanci, pak aby 1C fungoval, název serveru musí být specifikován nikoli FQDN (tcp / ip bude fungovat), ne prostřednictvím localhost nebo pouze ServerName, ale například prostřednictvím ServerName\InstanceName zz-test\zztest. (V opačném případě dojde k chybě DBMS: Microsoft SQL Server Native Client 10.0: Provider sdílená paměť: Knihovna sdílené paměti použitá k navázání připojení k serveru SQL Server 2000 nebyla nalezena. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE=08001, stav=1, Závažnost=10, nativní=126, řádek=0).

Pro uživatele do 100 let je jediným bodem rozdělení na dva samostatné servery licence pro Win 2008 Std (a starší verze), která podporuje pouze 32 GB RAM. Ve všech ostatních případech by měly být 1C a SQL rozhodně nainstalovány na stejném serveru a měly by mít více (alespoň 64 GB) paměti. Dávat MS SQL méně než 24-28 GB RAM je neopodstatněná chamtivost (pokud si myslíte, že na to máte dostatek paměti a vše funguje dobře - možná by vám stačila verze souboru 1C?)

O kolik hůře funguje hromada 1C a SQL ve virtuálním stroji, je téma na samostatný článek (nápověda - znatelně horší). Ani v Hyper-V nejsou věci tak jasné...

Režim vyváženého výkonu je špatný. Výsledky jsou v dobré shodě s verzí souboru.

Mnoho zdrojů uvádí, že režim ladění (ragent.exe -debug) výrazně snižuje výkon. No, snižuje to ano, ale 2-3% bych nenazval významným efektem.

Foto Alena Tulyakova, IA Clerk.Ru

Článek uvádí hlavní chyby, kterých se začínající administrátoři 1C dopouštějí, a ukazuje, jak je vyřešit na příkladu Gilevova testu.

Hlavním účelem psaní článku není opakovat zjevné nuance těm správcům (a programátorům), kteří ještě nezískali zkušenosti s 1C.

Sekundární cíl, pokud mám nějaké nedostatky, tak mě na to nejrychleji upozorní Infostart.

Počáteční údaje:

Pro testování vzdálených serverů 1C a SQL, SQL server: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Pro testování 10Gbit sítě byly použity adaptéry Intel 520-DA2.

Verze souboru. (základna leží na serveru ve sdílené složce, klienti jsou připojeni v síti, protokol CIFS/SMB). Algoritmus krok za krokem:

0. Přidejte testovací databázi Gilev na souborový server do stejné složky jako hlavní databáze. Připojíme se z klientského počítače, spustíme test. Výsledek si pamatujeme.

Předpokládá se, že i u starých počítačů starých 10 let (Pentium na socketu 775) by doba od kliknutí na zástupce 1C:Enterprise do zobrazení databázového okna měla být kratší než minuta. (Celeron = pomalá práce).

Pokud je váš počítač horší než 775 socketové pentium s 1 GB RAM, pak s vámi sympatizuji a bude pro vás obtížné dosáhnout pohodlné práce na 1C 8.2 ve verzi souboru. Zvažte buď upgrade (dlouho opožděný) nebo přechod na terminálový (nebo webový, v případě tenkých klientů a spravovaných formulářů) server.

Pokud na tom počítač není hůř, tak můžeš správce kopnout. Minimálně zkontrolujte fungování sítě, antiviru a ovladače ochrany HASP.

Pokud Gilevův test v této fázi ukázal 30 "papoušků" a více, ale pracovní základna 1C stále funguje pomalu - otázky jsou již pro programátora.

1. Pro vodítko, kolik dokáže klientský počítač "vymáčknout", zkontrolujeme provoz pouze tohoto počítače bez sítě. Testovací základnu jsme umístili na lokální počítač (na velmi rychlý disk). Pokud klientský počítač nemá normální SSD, vytvoří se ramdisk. Zatím nejjednodušší a bezplatný je Ramdisk enterprise.

Pro testování verze 8.3 stačí 256 MB ramdisk, ale je potřeba více volné RAM.

Nejčastější chyby v této fázi.

Špatně nakonfigurovaný antivirus. Antivirů je mnoho, nastavení u každého je jiné, mohu jen říci, že při správné konfiguraci web ani Kaspersky 1C neruší. Při "výchozím" nastavení - lze odebrat asi 3-5 papoušků (10-15%).
výkonnostní režim. Z nějakého důvodu tomu málokdo věnuje pozornost a efekt je nejvýraznější. Pokud potřebujete rychlost, musíte to udělat na klientských i serverových počítačích. (Gilev má dobrý popis. Jedinou výhradou je, že na některých základních deskách, pokud je vypnutý Intel SpeedStep, nelze zapnout TurboBoost).

Režim výkonu můžete (a nejlépe) povolit na dvou místech:

přes BIOS. Zakázat režimy C1, C1E, Intel C-state (C2, C3, C4). V různých bios se nazývají různě, ale význam je stejný. Hledání po dlouhou dobu, je vyžadován restart, ale pokud jste to udělali jednou, můžete zapomenout. Pokud je vše v BIOSu provedeno správně, rychlost bude přidána. Na některých základních deskách lze nastavení BIOSu nastavit tak, že režim výkonu Windows nebude hrát roli. (Příklady nastavení systému BIOS od Gileva). Tato nastavení se týkají hlavně serverových procesorů nebo "pokročilého" BIOSu, pokud jste jej nenašli ve svém systému a nemáte Xeon - je to v pořádku.

Ovládací panel – Napájení – Vysoký výkon. Mínus - pokud počítač nebyl delší dobu v servisu, bude silněji bzučet ventilátorem, bude se více zahřívat a spotřebovávat více energie. To je cena výkonu.

Jak zkontrolovat, zda je režim povolen. Spusťte Správce úloh - Výkon - Monitor prostředků - CPU. Čekáme, dokud nebude procesor ničím zaneprázdněn.

Toto jsou výchozí nastavení.

BIOS povolen ve stavu C,

režim vyváženého výkonu

BIOS povolený ve stavu C, režim vysokého výkonu

U Pentia a Core se můžete zastavit tam,

z Xeonu můžete ještě vymáčknout nějaké "papoušky".

V BIOSu jsou C-stavy vypnuté, režim vysokého výkonu.

Pokud nepoužíváte Turbo boost – tak by to mělo vypadat

server vyladěný na výkon

Vážení administrátoři, můžete 1C nadávat, jak chcete, ale pokud koncoví uživatelé potřebují rychlost, musíte povolit režim vysokého výkonu.

Jak zapnout turbo boost je napsáno například. Ale! U 1C existují určité nuance (ne nejzřetelnější). Potíž je v tom, že maximální účinek turbo boostu se projeví při zapnutém C-stavu. A vznikne něco jako tento obrázek:

Upozorňujeme, že násobič je maximální, rychlost jádra je nejkrásnější, výkon je vysoký. Ale co se stane v důsledku 1s?

2. Když jsme přišli na procesor a paměť klientského počítače, přejdeme na další velmi důležité místo - síť. O ladění sítě bylo napsáno mnoho knih, existují články o Infostartu ( a další), zde se tomuto tématu nebudu věnovat. Před zahájením testování 1C se prosím ujistěte, že iperf mezi dvěma počítači ukazuje celé pásmo (pro 1Gbit karty - no, alespoň 850 Mbit, ale lépe 950-980), že jsou dodržovány Gilevovy rady. Pak - nejjednodušším testem práce bude, kupodivu, zkopírování jednoho velkého souboru (5-10 gigabajtů) přes síť. Nepřímým znakem normálního provozu v síti 1 Gbps bude průměrná rychlost kopírování 100 Mb / s, dobrá práce - 120 Mb / s. Chci vás upozornit na skutečnost, že zatížení procesoru může být také slabým místem (včetně). Protokol SMB na Linuxu je poměrně špatně paralelizovaný a za provozu může celkem snadno „sežrat“ jedno jádro procesoru a už ho nespotřebovat.

A dál. Ve výchozím nastavení funguje windows klient nejlépe s windows serverem (nebo i windows pracovní stanicí) a protokolem SMB / CIFS, linuxový klient (debian, ubuntu se na ostatní nedívalo) nejlépe s linuxem a NFS (funguje i s SMB, ale na papoušcích NFS výše). To, že se při lineárním kopírování win-linux serveru na nfs zkopíruje do jednoho streamu rychleji, nic neznamená. Vyladění debianu pro 1C je téma na samostatný článek, ještě se na to nechystám, i když můžu říct, že v souborové verzi jsem dokonce dostal o něco lepší výkon než Win verze na stejném vybavení, ale s postgresem s uživatelé nad 50 let mám stále všechno velmi špatné.

Nejdůležitější je to, o čem vědí „spálení“ správci, ale začátečníci neberou v úvahu. Existuje mnoho způsobů, jak nastavit cestu k databázi 1c. Můžete vytvořit servershare, můžete 192.168.0.1share, můžete použít síť z: 192.168.0.1share (a v některých případech bude tato metoda také fungovat, ale ne vždy) a poté zadat jednotku Z. Zdá se, že všechny tyto cesty ukazují na stejnou věc na stejné místo, ale pro 1C existuje jen jedna cesta, která je docela stabilní a dává normální výkon. Zde je to, co musíte udělat správně:

Na příkazovém řádku (nebo v zásadách, nebo co vám vyhovuje) - použijte DriveLetter: servershare. Příklad: net use m:serverbases. Konkrétně zdůrazňuji, NE IP adresu, ale název serveru. Pokud server není viditelný podle názvu, přidejte jej do DNS na serveru nebo lokálně do souboru hosts. Ale odvolání musí být jmenovité. Podle toho na cestě do databáze přistupte na tento disk (viz obrázek).

A teď v číslech ukážu, proč takové rady. Počáteční údaje: Intel X520-DA2, Intel 362, Intel 350, karty Realtek 8169. OS Win 2008 R2, Win 7, Debian 8. Nejnovější ovladače, aktualizace použity. Před testováním jsem se ujistil, že Iperf dává plnou šířku pásma (kromě 10 Gbit karet se ukázalo, že vytlačí jen 7,2 Gbit, později uvidím proč, testovací server ještě není správně nakonfigurován). Disky jsou různé, ale všude je SSD (speciálně vložený jediný disk pro testování, nic jiného se nenačítá) nebo raid z SSD. Rychlost 100 Mbit byla získána omezením nastavení adaptéru Intel 362. Mezi 1 Gbit měděnou Intel 350 a 1 Gbit optikou Intel X520-DA2 (získanou omezením rychlosti adaptéru) nebyl žádný rozdíl. Maximální výkon, turbo boost je vypnutý (jen pro srovnatelnost výsledků, turbo boost přidává o něco méně než 10% pro dobré výsledky, pro špatné výsledky to nemusí ovlivnit vůbec). Verze 1C 8.2.19.86, 8.3.6.2076. Neuvádím všechna čísla, ale jen ta nejzajímavější, aby bylo s čím porovnávat.

	100Mbit CIFS Win 2008 - Win 2008 volání přes IP adresu	100Mbit CIFS Win 2008 - Win 2008 adresa podle jména	1 Gbit CIFS Win 2008 - Win 2008 volání přes IP adresu	1 Gbit CIFS Win 2008 - Win 2008 adresa podle jména	1 Gbit CIFS Win 2008 - Win 7 adresa podle jména	1 Gbit CIFS Windows 2008 – Debian adresa podle jména	10 Gbit CIFS Win 2008 - Win 2008 volání přes IP adresu	10 Gbit CIFS Win 2008 - Win 2008 adresa podle jména
	11,20	26,18	15,20	43,86	40,65	37,04	16,23	44,64
1С 8.2	11,29	26,18	15,29	43,10	40,65	36,76	15,11	44,10
8.2.19.83	12,15	25,77	15,15	43,10			14,97	42,74
	6,13	34,25	14,98	43,10	39,37	37,59	15,53	42,74
1C 8.3	6,61	33,33	15,58	43,86	40,00	37,88	16,23	42,74
8.3.6.2076		33,78	15,53	43,48	39,37	37,59		42,74

Závěry (z tabulky az osobní zkušenosti. Platí pouze pro verzi souboru):

Po síti můžete získat docela normální čísla pro práci, pokud je tato síť normálně nakonfigurována a cesta je správně napsána v 1C. Dokonce i první Core i3s mohou dát 40+ papoušků, což je docela dobré, a nejsou to jen papoušci, v reálné práci je rozdíl také znatelný. Ale! omezením při práci s více (více než 10) uživateli již nebude síť, zde stále stačí 1 Gbit, ale blokování při víceuživatelské práci (Gilev).
platforma 1C 8.3 je mnohonásobně náročnější na kompetentní nastavení sítě. Základní nastavení – viz Gilev, ale mějte na paměti, že vše může ovlivnit. Zrychlení jsem viděl v tom, že odinstalovali (a nejen vypnuli) antivirus, v odstranění protokolů jako FCoE, ve změně ovladačů na starší, ale microsoftem certifikovanou verzi (zejména u levných karet jako asus a dlinks), v odstranění druhá síťová karta ze serveru. Mnoho možností, konfigurujte síť promyšleně. Může nastat situace, kdy platforma 8.2 poskytuje přijatelná čísla a 8.3 - dvakrát nebo dokonce vícekrát méně. Zkuste si pohrát s verzemi platformy 8.3, někdy získáte velmi velký efekt.
1C 8.3.6.2076 (možná později, přesnou verzi jsem ještě nehledal) přes síť je stále snazší nastavit než 8.3.7.2008. Od 8.3.7.2008 bylo možné dosáhnout normálního síťového provozu (u srovnatelných papoušků) jen párkrát, pro obecnější případ jsem to nemohl zopakovat. Moc jsem tomu nerozuměl, ale soudě podle footcloth z Process Exploreru tam záznam nejde tak, jako v 8.3.6.
Navzdory skutečnosti, že při práci na 100Mbps síti je její rozvrh zatížení malý (můžeme říci, že síť je volná), rychlost práce je stále mnohem nižší než na 1 Gbps. Důvodem je latence sítě.
Ceteris paribus (dobře fungující síť) pro 1C 8.2, připojení Intel-Realtek je o 10 % pomalejší než Intel-Intel. Ale realtek-realtek obecně dokáže z ničeho nic prudce klesnout. Proto pokud jsou peníze, je lepší mít síťové karty Intel všude, pokud nejsou peníze, dát Intel pouze na server (vaše KO). Jo a návodů na ladění síťových karet intel je mnohonásobně více.
Výchozí nastavení antiviru (například verze drweb 10) odebere asi 8-10% papoušků. Pokud to správně nakonfigurujete (povolíte procesu 1cv8 dělat vše, ačkoli to není bezpečné) - rychlost je stejná jako bez antiviru.
NEČTĚTE Linuxové guru. Server se sambou je skvělý a zdarma, ale pokud na server dáte Win XP nebo Win7 (nebo ještě lépe - serverový OS), pak ve verzi souboru 1c bude fungovat rychleji. Ano, jak samba, tak zásobník protokolů a nastavení sítě a mnohem více v debian / ubuntu jsou dobře vyladěné, ale toto je doporučeno pro specialisty. Nemá smysl instalovat Linux s výchozím nastavením a pak říkat, že je pomalý.
Je dobré otestovat disky připojené přes net use s fio . Alespoň bude jasné, zda se jedná o problémy s platformou 1C, nebo se sítí / diskem.
U varianty pro jednoho uživatele mě nenapadají testy (nebo situace), kdy by byl viditelný rozdíl mezi 1Gb a 10Gb. Jediným místem, kde 10Gbps pro verzi souboru dávalo lepší výsledky, bylo připojení disků přes iSCSI, ale to je téma na samostatný článek. Přesto si myslím, že na souborovou verzi stačí 1Gbit karty.
Proč se 100 Mbit sítí funguje 8.3 znatelně rychleji než 8.2 - nechápu, ale skutečnost se stala. Všechna ostatní zařízení, všechna ostatní nastavení jsou naprosto stejná, akorát v jednom případě se testuje 8.2 a ve druhém - 8.3.
Nenaladěno NFS win - win nebo win-lin dává 6 papoušků, nezahrnul do tabulky. Po naladění jsem dostal 25, ale je nestabilní (náběh v měření je více než 2 jednotky). Zatím nemohu dát doporučení k používání oken a protokolu NFS.

terminálový server. (základna leží na serveru, klienti jsou připojeni v síti, protokol RDP). Algoritmus krok za krokem:

Testovací databázi Gilev přidáme na server do stejné složky jako hlavní databáze. Připojíme se ze stejného serveru a spustíme test. Výsledek si pamatujeme.
Stejným způsobem jako ve verzi souboru nastavíme procesor. V případě terminálového serveru obecně hraje hlavní roli procesor (rozumějte, že neexistují žádné zjevné slabiny, jako je nedostatek paměti nebo velké množství zbytečného softwaru).
Nastavení síťových karet v případě terminálového serveru nemá na provoz 1s prakticky žádný vliv. Chcete-li poskytnout "zvláštní" komfort, pokud váš server rozdává více než 50 papoušků, můžete si pohrát s novými verzemi protokolu RDP, jen pro pohodlí uživatelů, rychlejší odezvu a rolování.
Při aktivní práci velkého počtu uživatelů (a zde již můžete zkusit připojit 30 lidí k jedné základně, pokud se o to pokusíte), je velmi žádoucí nainstalovat SSD disk. Z nějakého důvodu se předpokládá, že disk nijak zvlášť neovlivňuje činnost 1C, ale všechny testy se provádějí s mezipamětí řadiče povolenou pro zápis, což je špatně. Testovací základna je malá, vejde se do cache, proto ta vysoká čísla. Na skutečných (velkých) databázích bude vše úplně jinak, takže cache je pro testy zakázána.

	Raid 10 4x SATA 7200 ATA ST31500341AS	Raid 10 4x SAS 10k	Raid 10 4x SAS 15k	Jeden SSD	ramdisk	ramdisk	Mezipaměť povolena RAID řadič
	21,74	28,09	32,47	49,02	50,51	53,76	49,02
1С 8.2	21,65	28,57	32,05	48,54	49,02	53,19
8.2.19.83	21,65	28,41	31,45	48,54	49,50	53,19
	33,33	42,74	45,05	51,55	52,08	55,56	51,55
1C 8.3	33,46	42,02	45,05	51,02	52,08	54,95
8.3.7.2008	35,46	43,01	44,64	51,55	52,08	56,18

Přiložená cache řadiče RAID eliminuje všechny rozdíly mezi disky, čísla jsou stejná pro sat i sas. Testování s ním pro malé množství dat je zbytečné a není indikátorem.
U platformy 8.2 je rozdíl ve výkonu mezi možnostmi SATA a SSD více než dvojnásobný. Nejedná se o překlep. Pokud se při testu na SATA discích podíváte na monitor výkonu. pak je jasně vidět "Čas aktivního disku (v %)" 80-95. Ano, pokud povolíte mezipaměť pro zápis samotných disků, rychlost se zvýší na 35, pokud povolíte mezipaměť řadiče raid - až 49 (bez ohledu na to, které disky jsou v tuto chvíli testovány). Ale to jsou syntetickí papoušci cache, v reálné práci s velkými databázemi nikdy nebude 100% zápis cache hit ratio.
Rychlost i levných SSD (testoval jsem na Agility 3) stačí na to, aby verze souboru fungovala. Zápisový zdroj je věc druhá, zde je potřeba hledat v každém konkrétním případě, je jasné, že Intel 3700 to bude mít o řád vyšší, ale tam tomu odpovídá cena. A ano, chápu, že při testování SSD disku ve větší míře testuji i cache tohoto disku, reálné výsledky budou menší.
Nejsprávnější (z mého pohledu) řešení by bylo vyčlenit 2 SSD disky na mirror raid pro souborovou základnu (nebo více souborových základen) a nic jiného tam nedávat. Ano, se zrcátkem se SSD opotřebovávají stejně a to je mínus, ale alespoň jsou nějak pojištěny proti chybám v elektronice řadiče.
Hlavní výhody SSD disků pro verzi souboru se projeví, když existuje mnoho databází a každá s několika uživateli. Pokud existují 1-2 základny a uživatelé v oblasti 10, budou stačit disky SAS. (ale v každém případě - podívejte se na načítání těchto disků alespoň přes perfmon).
Hlavní výhody terminálového serveru jsou, že může mít velmi slabé klienty a nastavení sítě ovlivní terminálový server mnohem méně (opět vaše KO).

Závěry: Pokud spustíte test Gilev na terminálovém serveru (ze stejného disku, kde jsou umístěny pracovní databáze) a v okamžicích, kdy se pracovní databáze zpomalí, a test Gilev ukazuje dobrý výsledek (nad 30), pak Na vině je pomalý chod hlavní pracovní databáze, nejspíše programátor.

Možnost klient-server.

Testy byly provedeny pouze 8.2, tk. Na 8.3 vše docela vážně závisí na verzi.

Pro testování jsem zvolil různé možnosti serveru a sítě mezi nimi, abych ukázal hlavní trendy.

	1C: Xeon 5520 SQL: Xeon E5-2630	1C: Xeon 5520 SQL: Xeon E5-2630 Fibre channel-SSD	1C: Xeon 5520 SQL: Xeon E5-2630 Fibre channel - SAS	1C: Xeon 5650 SQL: Xeon E5-2630	1C: Xeon 5650 SQL: Xeon E5-2630 Fibre channel-SSD	1C: Xeon 5650 SQL: Xeon E5-2630	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =	1C: Xeon 5650 =
	16,78	18,23	16,84	28,57	27,78	32,05	34,72	36,50	23,26	40,65	39.37
1С 8.2	17,12	17,06	14,53	29,41	28,41	31,45	34,97	36,23	23,81	40,32	39.06
	16,72	16,89	13,44	29,76	28,57	32,05	34,97	36,23	23,26	40,32	39.06

Zdá se, že jsem zvážil všechny zajímavé možnosti, pokud vás zajímá něco jiného - napište do komentářů, pokusím se to udělat.

SAS na úložišti je pomalejší než místní SSD, i když úložiště má velké velikosti mezipaměti. SSD a místní a úložné systémy pro test Gilev pracují srovnatelnými rychlostmi. Neznám žádný standardní vícevláknový test (nejen záznamy, ale veškeré vybavení) kromě zátěže 1C z MCC.
Změna serveru 1C z 5520 na 5650 přinesla téměř zdvojnásobení výkonu. Ano, konfigurace serveru se úplně neshodují, ale ukazuje to trend (nic překvapivého).
Zvýšení frekvence na serveru SQL má jistě efekt, ale ne stejný jako na serveru 1C, MS SQL server je dokonale schopen (pokud se ptáte) používat vícejádrovou a volnou paměť.
Změna sítě mezi 1C a SQL z 1 Gbps na 10 Gbps dává asi 10 % papoušků. Očekávalo se víc.
Povolení sdílené paměti stále poskytuje efekt, i když ne 15%, jak je popsáno v článku. Ujistěte se, že to uděláte, je to rychlé a snadné. Pokud někdo během instalace dal SQL serveru pojmenovanou instanci, pak aby 1C fungoval, název serveru musí být zadán nikoli FQDN (tcp / ip bude fungovat), ne prostřednictvím localhost nebo pouze ServerName, ale prostřednictvím ServerNameInstanceName, například zz -testzztest. (V opačném případě dojde k chybě DBMS: Microsoft SQL Server Native Client 10.0: Poskytovatel sdílené paměti: Knihovna sdílené paměti použitá pro připojení k serveru SQL Server 2000 nebyla nalezena. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr: SQLSTATE =08001, stav=1, závažnost=10, nativní=126, řádek=0).
pro uživatele do 100 je jediným bodem rozdělení na dva samostatné servery licence pro Win 2008 Std (a starší verze), která podporuje pouze 32 GB RAM. Ve všech ostatních případech by měly být 1C a SQL rozhodně nainstalovány na stejném serveru a měly by mít více (alespoň 64 GB) paměti. Dávat MS SQL méně než 24-28 GB RAM je neopodstatněná chamtivost (pokud si myslíte, že na to máte dostatek paměti a vše funguje dobře - možná by vám stačila verze souboru 1C?)
O kolik hůře funguje hromada 1C a SQL ve virtuálním stroji, je téma na samostatný článek (nápověda - znatelně horší). Ani v Hyper-V nejsou věci tak jasné...
Režim vyváženého výkonu je špatný. Výsledky jsou v dobré shodě s verzí souboru.
Mnoho zdrojů uvádí, že režim ladění (ragent.exe -debug) výrazně snižuje výkon. No, snižuje to ano, ale 2-3% bych nenazval významným efektem.

Nejméně bude rad pro konkrétní případ, protože. brzdy v režimu klient-server jsou nejobtížnějším případem a vše je konfigurováno velmi individuálně. Nejjednodušší způsob, jak říci, je, že pro normální provoz je třeba vzít samostatný server POUZE pro 1C a MS SQL, dát tam procesory s maximální frekvence(nad 3 GHz), SSD disky pro základní a více paměti (128+) nepoužívejte virtualizaci. Pomohlo - výborně, máte štěstí (a takových šťastlivců bude spousta, více než polovina problémů se řeší adekvátním upgradem). Pokud ne, všechny další možnosti již vyžadují samostatné zvážení a nastavení.

Výsledky zátěžového testu TPC-1 performance 1C podle Gileva pro konfiguraci s databází souborů:

Výkon serveru se neměří zatížením a frontami na CPU, ale schopností provést určitý počet operací za jednotku času.
Soutěž o zdroje, jako je CPU, snižuje rychlost operací, když je doba odezvy určena:

provozní doba
čekací doba zařízení
logické čekací doby jako zámky

V tomto případě je klíčovou charakteristikou rychlost operace.

Poznámka. Pro procesor je nejdůležitější charakteristikou frekvence procesoru, nikoli pracovní zátěž. Níže je snímek obrazovky s výsledky testování (pro zvětšení obrázku klikněte na něj).

Rychlost systému a plánování potřebných výpočetních zdrojů pro jeho implementaci je povinnou operací pro jakoukoliv implementaci nebo úpravu stávajícího IT systému.

Většina stávajících metod hodnocení výkonu je založena na jednom nebo druhém typu testování.

Existují dva hlavní typy testování: komponentní a integrální.

Pomocí testování komponent se testují jednotlivé komponenty řešení, od výkonu procesorů nebo subsystémů pro ukládání informací až po testování výkonu serveru jako celku, ale bez zátěže v podobě konkrétní podnikové aplikace.

Integrální přístup je charakterizován posouzením výkonu řešení jako celku, a to jak jeho softwarových, tak hardwarových částí. V tomto případě lze použít jak obchodní aplikaci, která bude použita ve finálním řešení, tak některé modelové aplikace, které emulují některé standardní obchodní procesy a zátěže.

V našem testu je právě takový přístup použit.

Výsledkem je index výkonu (rychlost). Toto je výsledek platformy jako celku na našem hardwaru. V případě klient-server verze je to výsledek složitého řetězce předávání požadavků přes různé sekce. Získáte celkový skutečný výsledek, který je určen úzkým místem v systému. Nastavení DBMS a nastavení OS a hardwaru ovlivňují celkový výsledek výkonu systému.

Test hodnotí množství práce za jednotku času v jednom vlákně a je vhodný pro hodnocení rychlosti jednovláknových zátěží, včetně rychlosti vykreslování rozhraní, vlivu nákladů na údržbu virtuálního prostředí a případně přeúčtování dokladů, uzavření měsíce, mzdová agenda atd.

Produkty pro účetnictví a manažerské účetnictví společnosti 1C jsou nejběžnější na území Ruské federace. Tisíce společností provozují své podnikání na základě standardních a specializovaných konfigurací 1C. Při tak masivním používání se pravidelně objevuje řada otázek ohledně optimalizace rozpočtu na software a rozumného využití zdrojů. Spory kolem serverových částí tohoto komplexu neutichají, zejména na jakém operačním systému založit server 1C a kterému DBMS svěřit zpracování databází 1C. Během našich testů se pokusíme na tyto otázky odpovědět.

Účastníci testu

Operační systém MS Server a MS SQL DBMS

Společnost 1C tento balíček otevřeně staví jako hlavní pracovní model, respektive produkty 1C jsou vytvořeny především pro něj.
Přítomnost protokolu přímé vysokorychlostní výměny informací SharedMemory
Je tam úředník technická podpora a servisní smlouvy
Existuje znalostní báze a spousta informací o instalaci a doladění 1C + MS SQL

Operační systém Unix a PostgreSQL DBMS

Systém je zcela zdarma (kromě licence pro server 1C:Enterprise)
Je možné flexibilně konfigurovat mnoho parametrů, které zlepšují výkon DBMS
Deklarovaná podpora pro PostgreSQL DBMS produkty 1C
Možnost replikace databáze

Důležitými kritérii při výběru informačního systému pro 1C jsou samozřejmě náklady na projekt, odolnost proti chybám a technická podpora. Existuje však faktor, který ve většině případů dramaticky ovlivňuje rozhodování – tím je rychlost.

Vzhledem k tomu, že technická literatura k těmto dvěma systémům na internetu je prostě skvělá, dalo by se dlouho polemizovat o dlouhých srovnávacích tabulkách, které v závislosti na cílech zdůrazňují výhody toho či onoho produktu. Ten či onen parametr můžete diskutovat mezi stovkami dalších stejného druhu – jak je ve svém druhu jedinečný a jak ovlivňuje dosažení výsledku. Teorie bez praxe je ale mrtvá – v tomto článku navrhujeme vynechat teorii a přejít přímo k faktům, abychom si otestovali výkon obou informačních systémů v praxi s určitou úrovní doporučeného nastavení a v různé možnosti architektura serveru (viz tabulka 2).

Testovací metody

V našich testech se budeme opírat o dvě metody syntetického generování zátěže a imitace uživatelské práce v 1C. Jedná se o test Gilev (TPC-1C) a speciální testovací 1C „Test Center“ ze sady nástrojů 1C: KIP se speciálními uživatelskými scénáři.

Gilevův test (TPC-1C)

Gilevův test patří do sekce univerzálních cross-platform zátěžových zkoušek. Lze jej použít pro souborovou architekturu i architekturu klient-server 1C:Enterprise. Test měří množství práce za jednotku času v jednom vláknu a je vhodný pro posouzení rychlosti jednovláknových úloh, včetně rychlosti vykreslování rozhraní, dopadu nákladů na zdroje, přeúčtování dokumentů, procedur na konci měsíce, mzdové agendy , atd. Univerzálnost vám umožňuje provést souhrnné hodnocení výkonu, aniž byste byli vázáni na konfiguraci jediné platformy. Výsledkem testu je celkové hodnocení měřeného systému 1C, vyjádřené v libovolných jednotkách.

Specializovaný test ze sady nástrojů Test Center 1C: KIP

Testovací centrum- nástroj pro víceuživatelské zátěžové testování systémů založených na 1C: Enterprise 8 (viz obrázek 1). S jeho pomocí můžete simulovat práci společnosti bez účasti reálných uživatelů, což umožňuje vyhodnotit použitelnost, výkonnost a škálovatelnost informačního systému v reálných podmínkách. Systém je konfigurace, která poskytuje mechanismus pro řízení procesu testování. Pro testování infobáze je nutné integrovat konfiguraci Testcentra do konfigurace testované databáze porovnáním a slučováním konfigurací. V důsledku sloučení budou k metadatům testované databáze přidány objekty a společné moduly nezbytné pro provoz Testovacího centra.

Obrázek 1 - Schéma práce "Test Center" 1C: přístrojové vybavení

Pomocí sady nástrojů 1C: instrumentation toolkit, založené na dostupných datech ve skutečných výrobních základnách 1C, tedy programátor vytvoří plnohodnotný scénář automatického testování založený na seznamu dokumentů a referenčních knih, které jsou klíčové pro tohoto typu konfigurace (žádost o útratu, objednávka dodavateli, prodej zboží a služeb atd.). Když scénář spustíte, Testovací centrum automaticky přehraje aktivitu pro více uživatelů popsanou ve scénáři. Testovací centrum k tomu vytvoří požadovaný počet virtuálních uživatelů (v souladu se seznamem rolí) a zahájí provádění akcí.

Možnosti testu

Při nastavování testovacích skriptů tak, aby spolehlivě simulovaly současnou práci velkého počtu uživatelů, jsou pro každý typ dokumentu nastaveny určité testovací parametry (viz tabulka 1):

Dokument - označuje konkrétní dokument v pracovní databázi, na základě kterého bude provedeno zátěžové testování
Priorita spouštění – tvoří pořadí, ve kterém jsou testy spouštěny pro každý typ dokumentu
Počet dokumentů – určuje objem vygenerovaných testovacích dokumentů
Pauza, sekundy – zpoždění při spuštění série testů v rámci stejného typu dokumentu
Počet řádků v dokumentu je informační ukazatel, který hlásí „masivnost“ testovacího dokumentu, která ovlivňuje dobu zpracování a zatížení zdrojů.

Testy se provádějí ve 3 iteracích, výsledky jsou zaznamenány do tabulky. Získané výsledky testů, měřené v sekundách, tedy nejrealističtěji a nejobjektivněji odrážejí úroveň výkonnosti základen 1C v podmínkách co nejbližších reálným (viz tabulky 3.1 a 3.2).

Tabulka 1. Parametry testovacího skriptu

Faktura kupujícího

	Dokument	Priorita spuštění	Počet dokumentů	Pauza, sekundy	Počet řádků v dokumentu
Role 1	Faktura kupujícího	1	25	51	62
	Příjem zboží	2	25		80
	Prodej zboží	3	25		103
	Peněžní příkazy	4	25		1
	Kupující vrací	5	25		82
Role 2	5	10	65	79
	Příjem zboží	1		22	80
	Prodej zboží	2		25	103
	Peněžní příkazy	3		25	1
	Kupující vrací	4		25	75
Role 3	Faktura kupujícího	4	15	45	76
	Příjem zboží	5	26		80
	Prodej zboží	1	52		103
	Peněžní příkazy	2	26		1
	Kupující vrací	3	32		90
Role 4	Faktura kupujícího	3	45	38	70
	Příjem zboží	4	30		80
	Prodej zboží	5	30		103
	Peněžní příkazy	1	20		1
	Kupující vrací	2	20		86
Role 5	Faktura kupujícího	2	30	73	76
	Příjem zboží	3	30		80
	Prodej zboží	4	30		103
	Peněžní příkazy	5	18		1
	Kupující vrací	1	18		91
Role 6	Faktura kupujícího	1	40	35	86
	Příjem zboží	2	40		80
	Prodej zboží	3	40		103
	Peněžní příkazy	4	40		1
	Kupující vrací	5	40		88
Role 7	Faktura kupujícího	5	25	68	80
	Příjem zboží	1	25		80
	Prodej zboží	2	25		103
	Peněžní příkazy	3	25		1
	Kupující vrací	4	25		90
Role 8	Faktura kupujícího	3	25	62	87
	Příjem zboží	4	25		80
	Prodej zboží	5	25		103
	Peněžní příkazy	1	25		1
	Kupující vrací	2	25		92
Role 9	Faktura kupujícího	2	20	82	82
	Příjem zboží	4	20		80
	Prodej zboží	5	20		103
	Peněžní příkazy	1	20		1
	Kupující vrací	3	20		98
Role 10	Faktura kupujícího	4	50	2	92
	Příjem zboží	1	50		80
	Prodej zboží	2	50		103
	Peněžní příkazy	5	50		1
	Kupující vrací	3	50		98

Tabulka 2 Specifikace zkušební stolice

№p\p	Role systému	CPU\vCPU	RAM, GB	Diskový systém I/O
1	Terminálový server – virtuální stroj pro správu testů	4 jádra 2,9 GHz	16 GB	Intel Sata SSD Raid1
2	Scénář 1. Server 1C + hardware DBMS	Intel Xeon E5-2690 16 jader	96 GB	Intel Sata SSD Raid1
3	Scénář 2 Server 1C + virtuální DBMS	16 jader 2,9 GHz	64 GB	Intel Sata SSD Raid1
4	Scénář 3 Virtuální server 1C	16 jader 2,9 GHz	32 GB	Intel Sata SSD Raid1
5	Scénář 4. Virtuální server DBMS	16 jader 2,9 GHz	32 GB	Intel Sata SSD Raid1
6	Software	Microsoft Windows Server 2016 DataCenter Microsoft Windows Server 2016 Standard Microsoft SQL Server 2016 SP1 (13.0.4001.0) Hyper-V Hypervisor Server 1C:Enterprise 8.3.10.2667 CentOS 7.4.1708 (x64) PostgreSQL 9.6.5+Patch PostgreSQL 9.6.5-4.1C
7	Konfigurace 1C	Jednovláknový syntetický test platformy 1C:Enterprise + vícevláknový test zápisu na disk (2.1.0.7) Vyacheslav Gilev Velikost 0,072 GB Konfigurace: Enterprise Accounting CORP, vydání 3.0 (3.0.52.39) Aplikace: tenký klient Možnost rozhraní: Taxi Velikost 9,2 GB Platforma: 1C:Enterprise 8.3 (8.3.10.2667) Konfigurace: Správa obchodu Revize 11 (11.3.4.21) Režim: Server (komprese: rozšířená) Aplikace: tenký klient lokalizace: Informační základna: ruština (Rusko), relace: ruština (Rusko) Možnost rozhraní: Taxi Velikost 11,8 GB

Tabulka 3.1 Výsledky testu s Gilevovým testem (TPC-1C). Nejvyšší hodnota je považována za optimální.

Tabulka 3.2 Výsledky testu pomocí speciálního testu 1C: KIP. Nejmenší hodnota je považována za optimální.

Operační systém Microsoft Server					Operační systém třídy Unix
Seznam testů (průměrná hodnota založená na výsledcích série 3 testů)	Hardwarový server 1C + DBMS, protokol SharedMemory	Virtuální server 1C + DBMS, protokol SharedMemory			Hardwarový server 1C a hardwarový server DBMS, protokol TCP-IP	Virtuální server 1C a virtuální server DBMS, protokol TCP-IP
Provádění testů 1C: KIP na existující databázi, konfigurace Accounting Enterprise
Obratová rozvaha	1,741 sec	2,473 sec	2,873 sec	2,522 sec	13,866 sec	9,751 sec
Provádění vracení zboží od kupujících	0,695 sec	0,775 sec	0,756 sec	0,781 sec	0,499 sec	0,719 sec
Zpracování platebních příkazů	0,048 sec	0,058 sec	0,063 sec	0,064 sec	0,037 sec	0,065 sec
Vedení PTIS	0,454 sec	0,548 sec	0,535 sec	0,556 sec	0,362 sec	0,568 sec
Provádění prodeje zboží a služeb	0,667 sec	0,759 sec	0,747 sec	0,879 sec	0,544 sec	0,802 sec
Zaúčtování faktury k platbě	0,028 sec	0,037 sec	0,037 sec	0,038 sec	0,026 sec	0,038 sec
Kalkulace odhadů nákladů	3,071 sec	3,657 sec	4,094 s	3,768 sec	15,175 sec	10,68 s
Provedení 1C: KIP testů na stávající základně, konfigurace Trade Management
Provedení a vrácení od klienta	2,192 sec	2,113 sec	2,070 sec	2,418 sec	1,417 sec	1,494 s
Provedení a vrácení zboží dodavateli	1,446 sec	1 410 sec	1,359 sec	1,467 sec	0,790 sec	0,849 sec
Zaúčtování prodejní objednávky	0,355 sec	0,344 sec	0,335 sec	0,361 sec	0,297 sec	0,299 sec
Provádění přepočtu zboží	0,140 sec	0,134 sec	0,131 sec	0,144 sec	0,100 sec	0,097 sec
Provádění příjmu specifikací	1 499 sec	1,438 sec	1,412 sec	1,524 sec	1,097 s	1,189 sec
Provádění realizace TS	1 390 sec	1,355 sec	1,308 sec	1,426 sec	1,093 s	1,114 s
Provádění RKO	0,759 sec	0,729 sec	0,713 sec	0,759 sec	0,748 sec	0,735 sec

Ve speciálním testu 1C jsou operace „čtení dat a komplexních výpočtů“, jako je „Bilance obratu“ a „Výpočet odhadů nákladů“ na MS SQL DBMS od Microsoftu několikanásobně rychlejší.
V operacích „zápis dat a odesílání dokumentů“ ve většině testů vykazuje nejlepší výsledek PostgreSQL DBMS, optimalizovaný pro 1C.
Gilevův syntetický test také ukazuje výhodu PostgreSQL. Tato skutečnost souvisí s tím, že syntetický test je založen na měření rychlosti vytváření a zaúčtování určitých typů dokladů, za což se rovněž považují operace „záznamu dat a zaúčtování dokladů“.

Skončeme porovnáním napříč platformami, přejděme ke srovnání v rámci jednotlivých systémů:

Jak se dalo očekávat, testy 1C na hardwarové platformě vykazují lepší výsledky než na virtuální. Rozdíl ve výsledcích speciálního testu 1C je v obou případech malý, což svědčí o postupné optimalizaci ze strany výrobců virtuálních hypervizorů.
Očekává se také, že použití technologie sdílené paměti (SharedMemory) urychlí proces výměny dat mezi serverem 1C a DBMS. Výsledky testu jsou tedy o něco lepší než výsledky schématu se síťovou interakcí těchto dvou služeb prostřednictvím protokolu TCP-IP.

Lze usuzovat, že při správné nastavení 1C a DBMS, můžete dosáhnout významných výsledků i na bezplatném software. Při návrhu nové struktury IT pro 1C je proto nutné vzít v úvahu úroveň zatížení systému, typ převažujících operací v databázi, dostupný rozpočet, přítomnost specialisty na nestandardní DBMS, nutnost integrace s externími službami atd. Na základě těchto údajů je již možné vybrat požadované řešení.

Přečtěte si o testování.