Výsledky Gilevova testu 8.3. Standardní zátěžový test. Co znamenají výsledky testů?

Povinná operace pro jakoukoli implementaci nebo změnu existujícího informační systém je posoudit požadovanou rychlost systému a naplánovat potřebné výpočetní zdroje pro jeho implementaci. V současné době neexistuje přesné řešení tohoto problému obecný pohled a pokud i přes svou složitost a cenu takový algoritmus navrhne jakýkoli výrobce, pak i malé změny v hardwaru, verzi softwaru, konfiguraci systému nebo počtu nebo standardním chování uživatelů povedou k výskytu závažných chyb.

Existuje však dostatečné množství způsobů, jak vyhodnotit software a konfiguraci potřebnou k dosažení požadovaného výkonu. Hardware. Všechny tyto metody mohou být použity ve výběrovém procesu, ale spotřebitel musí pochopit jejich aplikace a omezení.

Většina existujících metod hodnocení výkonu spoléhá na nějaký typ testování.

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

Testování komponent zahrnuje testování jednotlivých komponent řešení, od výkonu procesorů nebo úložných subsystémů až po testování výkonu serveru jako celku, ale bez užitečného zatížení v podobě konkrétní podnikové aplikace.

Integrovaný 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 business aplikaci, která bude použita ve finálním řešení, tak i některé modelové aplikace, které emulují některé standardní business procesy a zátěže.

Zelená barva grafu spolu s některými podmíněně vybranými ukazateli vpravo nám umožňuje provést meziplatformní zobecněné hodnocení „dobrého“ výkonu.

Jak mít radost z výsledků testů

Výsledkem je určitý index výkonu (rychlosti). Nezáleží na tom, zda je výsledek dobrý nebo špatný – je to výsledek PLATFORMY běžící na vašem hardwaru. V případě klient - server verze je to výsledek složitého řetězce požadavků procházejících různými sekcemi. Získáte celkový skutečný výsledek, který je určen úzkým místem v systému. Vždy je nějaké úzké hrdlo.

Jinými slovy, jak nastavení DBMS, nastavení OS a hardware mají vliv na celkový výsledek týmu.

Který server je lepší

Tento test, prováděný na konkrétním serveru, dává výsledek na základě celkového nastavení hardwaru, operačního systému, databáze atd. Přesto vysoký výsledek na konkrétní serverové vybavení znamená, že za normálních podmínek bude stejný výsledek na stejném hardwaru serveru. Tento test je bezplatný nástroj, který vám pomůže porovnat instalaci 1C:Enterprise pod Windows a Linux, tří různých DBMS podporovaných platformou 1C:Enterprise 8.

Test bezpečnosti

Test je naprosto bezpečný. Nevede k „havárii“ serveru (neexistuje žádný „stresový“ algoritmus) a nevyžaduje předběžná opatření ani na „bojovém“ serveru. Důvěrné údaje se také nezapisují do výsledků testu. Shromažďují se informace o parametrech CPU, RAM, HDD. Sériová čísla zařízení se nesbírají. To vše si můžete snadno ověřit – testovací kód je 100% otevřený. Bez vašeho vědomí není možné odeslat jakékoli informace.

Klasifikace TPC-A-místní propustnost / TPC-1C-GILV-A

Test patří do sekce univerzálních integrálních multiplatformních testů. Navíc je použitelný pro možnosti souborů a klient-server pro použití 1C:Enterprise. Test funguje pro všechny DBMS podporované 1C.

Univerzálnost vám umožňuje provést obecné hodnocení výkonu, aniž byste byli vázáni na konkrétní typická konfigurace platformy.

Na druhou stranu to znamená, že pro přesné výpočty zakázkového projektu vám test umožňuje provést předběžné posouzení před specializovanými zátěžovými zkouškami.

Stáhnout test

Tento test není komerční a lze jej stáhnout zdarma pro verzi 8.2 a zdarma pro verzi 8.3.

Technické údaje

Co se děje v testu v rámci „jednoho“ provozního cyklu?

Vlastnosti použití testu na databázi PostgreSQL

Nastavte hodnotu parametru standard_conforming_strings na konfigurační soubor postgresql.conf nastaven na 'off'

Jak měřit zatížení železa

Nutno podotknout, že samotný test již částečně provádí měření. Pro podrobnější obrázek doporučuji použít nástroj Process Explorer od Marka Rusinoviche.

Obrázek ukazuje příklad měření pro verzi souboru.

Účetní a manažerské účetní produkty od 1C jsou nejběžnější v Ruské federaci. 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 týkajících se optimalizace rozpočtu softwaru a rozumného využívání zdrojů. Probíhají spory kolem serverových částí tohoto komplexu, 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 tuto kombinaci otevřeně staví jako hlavní pracovní model, proto jsou produkty 1C vytvořeny především pro ni
  • Dostupnost protokolu pro přímou vysokorychlostní výměnu 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
  • Produkty 1C oznámily podporu pro PostgreSQL DBMS
  • Existuje 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ý rozhodování ve většině případů radikálně ovlivňuje – rychlost.

Protože na internetu je prostě velké množství technické literatury o těchto dvou systémech, 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 konkrétního produktu. O tom či onom parametru můžete debatovat mezi stovkami dalších stejného druhu – jak je ve svém druhu unikátní 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 v praxi otestovali výkon obou informačních systémů s určitou úrovní doporučeného nastavení a v různých možnostech serverové architektury (viz tabulka 2).

Testovací metody

V našich testech se budeme opírat o dvě metody syntetického generování zátěže a simulaci uživatelské práce v 1C. Toto je test Gilev (TPC-1C) a speciální test 1C „Test Center“ z 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 souborové i klientské serverové architektury 1C:Enterprise. Test měří množství práce za jednotku času v jednom vlákně a je vhodný pro posouzení rychlosti jednovláknových úloh, včetně rychlosti vykreslování rozhraní, dopadu nákladů na zdroje, opětovného zaúčtování dokumentů, postupů uzavírání na konci měsíce. , výpočet mezd atd. Všestrannost vám umožňuje provést souhrnné hodnocení výkonu, aniž byste byli vázáni na jednu konfiguraci platformy. Výsledkem testu je celkové hodnocení měřeného systému 1C, vyjádřené v konvenčních jednotkách.

Specializovaný test z nástrojů Test Center 1C: Instrumentace

Testovací centrum– nástroj pro provádění víceuživatelských zátěžových testů systémů založených na 1C:Enterprise 8 (viz obrázek 1). S jeho pomocí můžete simulovat práci firmy bez účasti reálných uživatelů, což umožňuje vyhodnotit použitelnost, výkon 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í informační základna je nutné začlenit konfiguraci Test Center do konfigurace testované základny porovnáváním a kombinováním konfigurací. V důsledku sloučení přibudou do metadat testované databáze objekty a společné moduly nezbytné pro provoz Testovacího centra.

Obrázek 1 - Schéma práce „Test Center“ 1C: Instrumentace

Pomocí nástrojů 1C: KIP, na základě dostupných dat ve skutečných produkčních základnách 1C, tedy programátor vytvoří plnohodnotný automatický testovací skript 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ž skript spustíte, Testovací centrum automaticky přehraje aktivitu více uživatelů popsanou ve skriptu. 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í.

Testovací parametry

Při nastavování testovacích scénářů pro spolehlivou simulaci simultánní práce 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 jehož základě bude provedeno zátěžové testování
  • Priorita spouštění – určuje 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 jednoho typu dokumentu
  • Počet řádků v dokumentu je informační ukazatel udávající „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ýkonu 1C databází v podmínkách, které se co nejvíce blíží reálným (viz tabulky 3.1 a 3.2).

Tabulka 1. Parametry testovacího scénáře

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 25 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

Ne. Role systému CPU\vCPU RAM, GB Diskový systém vstup výstup
1 Terminálový servervirtuální stroj pro správu testů 4 jádra
2,9 GHz
16 GB Intel SATA SSD Nájezd 1
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 datové centrum
  • Microsoft Windows Server 2016 Standard
  • Microsoft SQL Server 2016 SP1 (13.0.4001.0)
  • Hyper-V hypervizor
  • Server 1C:Enterprise 8.3.10.2667
  • CentOS 7.4.1708 (x64)
  • PostgreSQL 9.6.5+Patch PostgreSQL 9.6.5-4.1C
7 1C konfigurace
  • Jednovláknový syntetický test platformy 1C:Enterprise + test vícevláknového zápisu na disk (2.1.0.7) Vyacheslav Valerievich Gilev
  • Velikost 0,072 GB
  • Konfigurace: Podnikové účetnictví KORP, 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 použitím Gilevova testu (TPC-1C). Považováno za optimální nejvyšší hodnotu

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 sérii 3 testů) Hardwarový server 1C+DBMS, protokol SharedMemory Virtuální server 1C+DBMS, protokol SharedMemory 1C hardwarový server a hardwarový server DBMS, TCP-IP protokol Virtuální server 1C a virtuální server DBMS, protokol TCP-IP
Provádění testů 1C:KIP na existující databázi, konfigurace Enterprise Accounting
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 zákazníků 0,695 sec 0,775 sec 0,756 sec 0,781 sec 0,499 sec 0,719 sec
Provádění platebních příkazů 0,048 sec 0,058 sec 0,063 sec 0,064 sec 0,037 sec 0,065 sec
Vedení technických školení 0,454 sec 0,548 sec 0,535 sec 0,556 sec 0,362 sec 0,568 sec
Prodej 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
Provádění testů 1C:KIP na existující databázi, 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 sec
Provedení a vrácení zboží dodavateli 1,446 sec 1,410 sec 1,359 sec 1,467 sec 0,790 sec 0,849 sec
Odeslání zákaznické 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řístupu k technickým specifikacím 1,499 sec 1,438 sec 1,412 sec 1,524 sec 1,097 s 1,189 sec
Implementace specifikací 1 390 sec 1,355 sec 1,308 sec 1,426 sec 1,093 sec 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
  1. Ve speciálním testu 1C se na MS SQL DBMS od Microsoftu několikrát rychleji provádějí operace „čtení dat a komplexní výpočty“, jako je „Bilance obratu“ a „Výpočet odhadů nákladů“.
  2. Pro operace „záznamu dat a odesílání dokumentů“ ve většině testů vykazuje nejlepší výsledek PostgreSQL DBMS, optimalizovaný pro 1C.
  3. Gilevův syntetický test také ukazuje výhodu PostgreSQL. Tato skutečnost je způsobena 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 považuje i operace „záznam dat a zaúčtování dokladů“.

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

  1. 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ů.
  2. 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ž schéma se síťovou interakcí těchto dvou služeb prostřednictvím protokolu TCP-IP.

Můžeme dojít k závěru, že se správnou konfigurací 1C a DBMS můžete dosáhnout významných výsledků i na svobodě 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 pokračování testování.

Pro role serveru 1C, MS SQL 2008 DBMS server pro 50 uživatelů.

Podle odborníka na servery shromažďujeme hardware:

Výběr platformy: IBM x3650 M3
Vyberte procesor: Intel Xeon E5506 - 1 ks.
Výběr paměti RAM: 4 disky po 4 GB
Výběr pevného disku: 3 SAS 146 GB RAID5

Použitý software:

OS MS Windows 2008 x64
DBMS MS SQL 2008 x64
Server 1C 8.2 x64

Testovací prostředí: k provedení zátěžového testování byla použita konfigurace 1C 8.2: „Standardní zátěžový test“.

Průběh testu:

Na lokální server Relace klienta 1C byla spuštěna v režimu agenta a v testovacím režimu.
V testovací konfiguraci byl počáteční počet emulovaných standardních uživatelů 1C, kteří vytvářejí a odstraňují dokumenty a sestavy, uveden na 20. Krok ke zvýšení počtu uživatelů po testech byl nastaven na 20 uživatelů.

Zpočátku (bez připojení uživatelů) zabírá DBMS 569 MB RAM (byly vytvořeny 2 databáze: konfigurace 1C 8.2: UPP a testovací konfigurace), paměť obsazená systémem je 2,56 GB.
Během testování (až 110 uživatelů) je paměti pro DBMS přiděleno až 12 GB, jedna testovací relace 1C zabírá 55 MB (55 MB x 200 = 11 GB). Pro srovnání, jedna reálná uživatelská relace (klientská aplikace 1C) zabere cca 300 - 500 MB. Velikost paměti přidělené pro klientskou aplikaci 1C je indikována pro uživatele pracujícího ve standardní konfiguraci 1C: Trade nebo 1C: UPP. Služba 1C server (rphost) prakticky nepoužívá OP, protože pouze překládá požadavky z klientské části do DBMS (podle standardu se pro bezpečnostní server 1C používají porty TCP 1541 a TCP 475).

Využití prostředků CPU bylo sdíleno mezi službou serveru 1C (rphost) a službou DBMS (sqlservr). Při zatížení 40 uživatelů rphost zabral 37 % výkonu CPU, sqlservr 30 %. Při zatížení 60 uživatelů zabíral rphost 47 % výkonu CPU, sqlservr 29 %.

Při odstraňování vytvořených dokumentů přistupovala služba sqlsrvr k diskovému subsystému pro záznam rychlostí až 6,5 MB/s (asi 52 MB/s).

Zatížení sítě mezi serverem 1C a DBMS (na místním rozhraní zpětného pohledu) bylo 10 Mb/s.
Vydán výsledek testu testovací konfigurace 1C:

Parametry: Spustit test 000000006 z 24.05.2012 12:44:16
Standardní zátěžový test, verze 2.0.4.11
Začátek testování 23.05.2012 12:36:39. Délka představení: 57,1 minut.
Zkušební podmínky
"Server 1C: Enterprise: test
Název informační databáze: testcenter_82
Virtuální uživatelé: TEST,"

Závěry:

Je nutné uvolnit konfiguraci serveru, protože současná je pro 50 uživatelů 100% redundantní.
Pro spuštění emulovaných uživatelů a kontrolu zatížení sítě je nutné provést testování pomocí druhého serveru, předpokládaná zátěž je 10 Mb/sec.
Architektura 1C se skládá ze 4 bloků: 1C server, DBMS, 1C bezpečnostní server a 1C klient. V tomto testu byly všechny tyto funkce spuštěny na jednom serveru.

Pokud je na serveru 1C velké zatížení, existují následující doporučení:

Oddělte role serveru 1C, serveru DBMS, serveru ochrany 1C a klientských aplikací 1C (pro větší výkon je lepší spouštět klientské aplikace 1C na terminálovém serveru).
Na serveru DBMS musíte pro systémy ukládání dat použít následující strukturu: OS by měl být umístěn na RAID 1, datové soubory DBMS (.mdf, .ndf) na samostatném RAID 0, soubory protokolu (.ldf) na samostatném RAID 0, dočasné soubory a odkládací soubor na samostatném disku.

Počítače (konvenční název) účastnící se testů - popis (disky jsou uvedeny pouze pro databázi):

(vyjasnění mezi servery 1 Gbit síť)

1) IT33- desktop na Core i5 4 jádra 2,8 GHz, DDR3 3 GB, jeden HDD 7200 r/s.

2) NEMOVITÝ- NEJVÝKONNĚJŠÍ, jak jsem si myslel)) 8 jader Xeon na 3 GHz, DDR2 48 GB, RAID10 na SSD

3) REAL2- 8 xeonových jader na 2 GHz, DDR2 22 GB,RAID10 zapnutý pevné disky SAS 10 000 ot./s

Testy byly provedeny v konfiguraci 1c od Gilev:

"SQL Server" ---> "1C Server" ---> "Hodnocení" + "Název klientského počítače (pokud není zadán, pak je stejný v seznamu)"

>1)REAL2--->REAL2--->25.64(TCP--SQL)
>2)REAL2--->REAL2--->26.32(SQL--sdílená paměť)

>3)REAL2--->REAL2--->25,64 (SQL--sdílená paměť) + IT33 (klient) - od klienta k síti serverů=10 Mbit

>4 )REAL2--->REAL2--->24.27(SQL--Shared Memory) + REAL(klient) - hmm.. divná 1Gbit síť...proč je méně papoušků..
>5)REAL2--->REAL2--->37,59(Soubor)

** **** **************************
>1) REAL--->REAL--->8.73(TCP--SQL)

>2) REAL---> Skutečné2--->11.99 (TCP--SQL) --- to už mi začíná přinášet nějaké myšlenky))

>3) REAL--->REAL--->17,48 (Soubor)

** **** ******************************

>1)IT33--->IT33--->26,88(TCP--SQL)
>2)IT33--->IT33--->34.72(SQL--sdílená paměť)
>3)IT33--->IT33--->59,52(soubor)

Výsledek:

Podíval jsem se na výsledky testů... zkroucené sem a tam)) a pak mi to došlo (provedl jsem měření rychlosti RAM),

jak je to s rychlostí 1s 8.x (podotýkám, že výsledky testu vycházejí z režimu SINGLE-USER, ale i pro verzi klient-server s víceuživatelskou prací - myslím, že budou mít také značný podíl na vlivu) -

Rychlost 1C je tedy ovlivněna: frekvencí sběrnice CPU + frekvencí paměti RAM

----> co ovlivňuje Rychlosti zápisu a čtení v paměti RAM. Což je základ pro výkon 1s 8.x.

Počítače, které si rozdělily ceny z hlediska provozní rychlosti 1s))

1) IT33--->IT33--->59,52(Soubor)

RAM DDR 3 (čtení 11089 MB/s, zápis 7047 MB/s) ------ jak jsem očekával, rozdíl bude významný u serverů

2) SKUTEČNÉ 2--->REAL2--->37,59 (Soubor)
- RAM DDR2 (čtení=3474, zápis=2068)

3) SKUTEČNÉ--->REAL--->17,48 (Soubor)
- RAM DDR2 (čtení=1737 MB/s, zápis=1042 MB/s) - jak se ukázalo, rychlost je nižší než na Real2 - přesně 2x,

Vzhledem k povoleným virtuálním jádrům (Hyper-trading) jej s největší pravděpodobností zakážeme.

ZÁVĚRY:

Nejvyšší provozní rychlosti 1s 8.x je dosaženo:

I) pro možnost Soubor (osobně nemám zájem)

A) spuštění Klienta (jakéhokoli) na počítači vysokou rychlostí s RAM. (například terminálový server

tam DB).

II) pro volbu Klient-Server

1) Tlustí klienti 1C na " Terminálový server"- s +

2) Tenké klienty 1C- není žádný zvláštní rozdíl kde... ale je vhodné to nakonfigurovat přes "HTTP://".
3a) "SQL Server" + "1C Enterprise Server"(v režimu sdílené paměti) - na jednom voze s Nejvyšší rychlost zápisu/čtení RAM + Jádra CPU s nejvyšší frekvencí GHz disky

Vysvětlení:

- Podpěra, podporaSdílená paměť- objevilo se na motoru od 8.2.17 (POZOR v konfiguraci - režim kompatibility s předchozí verze motor), na předchozích motorech budou použity Naimed Pipes - také vykazují dobré výsledky))

- RAID zapnutý SSD disky - je vhodné použít RAID10 - pro odolnost proti chybám, přičemž je třeba vzít v úvahu MĚŘÍTKO zápisu:

příklad RAID10 (4 ks penalizace za zápis = 2), rychlost zápisu = 4/2 = 2 disky, žádná penalizace za čtení.

Můžete také dále zvýšit spolehlivost a stabilitu rychlosti SSD – nevyužít celou kapacitu disku.

příklad (zvýšení spolehlivosti Desktop SSD na úroveň Server SSD):

Pokud například SSD Intel 520 series 120 GB a přidělíte 81 GB a zbytek místa necháte nepřidělený -

pak bude asi 32 % prostoru SSD alokováno pro nadměrné poskytování kromě již existujících skrytých 8 %. Celkem získáme asi 40 %

Rozdíl mezi serverovými SSD řady Intel 710 a desktopovými SSD řady Intel 320 je právě rozdíl v nadměrném poskytování: více než 40 % u Intel 710 a 8 % u Intel 320.

Pokud je hodně klientů 1C od 100 výše:

1) Na současných síťových technologiích Ethernet - NENÍ vhodné odstranit "SQL" "Server 1C".

například z důvodu latence (zpoždění) v gigabitové síti Ethernet - reálná rychlost výměny s SQL = 30 MB/s - což nestačí ani na intenzivní práci s Databází 1 uživatele.

2) Protože ve skutečnosti „Server 1C“ = „Object DBMS“ (multidimenzionální objekty) a „SQL“ = "Relační DBMS"(úložiště dat s plochou tabulkou)

=> v SQL databázi je uložena PLOCHÁ projekce 1C objektů a 1C Server shromažďuje objekt z této projekce, poté s tímto objektem pracuje a nakonec, po dokončení práce, jej znovu rozloží do plochého pohledu a uloží jej v SQL.

V důsledku toho se mezi „SQL“ a „1C Server“ musíte vzdát rozdělení na dva fyzické servery. Můžete však použít plnou implementaci uzlů NUMA. ( To musí podporovat OS a samotné procesory).


3b) Pojďme to rozšířit SQL server a Server 1c samostatně: Na aktuální Ethernetové technologie- například Gigabit - NEPraktické
-SQL na server s Nejvyšší rychlost zápisu/čtení RAM + Jádra CPU s nejvyšší frekvencí GHz
-Nějaký FYZICKÉ servery v Clusteru 1c C Nejvyšší rychlost zápisu/čtení RAM + Jádra CPU s nejvyšší frekvencí GHz+ je vhodné použít RAID na SSD- disky

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

Výkon serveru se nehodnotí podle zátěže a front CPU, ale podle schopnosti provést určitý počet operací za jednotku času.
Soupeření o zdroje, jako je procesor, snižuje rychlost operací, když je doba odezvy určena:

  • provozní doba
  • čekací doba zařízení
  • čas logických čekání jako zámky

Klíčovou vlastností je rychlost operace.

Poznámka. Pro procesor je nejdůležitější charakteristika frekvence procesoru a ne zátěž. Níže je snímek obrazovky s výsledky testu (pro zvětšení klikněte na obrázek).

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

Většina existujících metod hodnocení výkonu spoléhá na nějaký typ testování.

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

Testování komponent zahrnuje testování jednotlivých komponent řešení, od výkonu procesorů nebo úložných subsystémů až po testování výkonu serveru jako celku, ale bez užitečného zatížení v podobě konkrétní podnikové aplikace.

Integrovaný 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 business aplikaci, která bude použita ve finálním řešení, tak i některé modelové aplikace, které emulují některé standardní business procesy a zátěže.

Náš test používá přesně tento přístup.

Získali jsme jako výsledek určitý výkonnostní (rychlostní) index. To je výsledek toho, že platforma jako celek běží na našem hardwaru. V případě klient - server verze je to výsledek složitého řetězce požadavků procházejících různými sekcemi. Získáte celkový skutečný výsledek, který je určen úzkým místem v systému. Nastavení DBMS, nastavení OS a nastavení hardwaru ovlivňují celkový výkon systému.

Test vyhodnocuje množství práce za jednotku času v jednom vlákně a je vhodný pro posouzení rychlosti jednovláknového zatížení, včetně rychlosti vykreslování rozhraní, vlivu nákladů na údržbu virtuálního prostředí a případně přenos doklady, měsíční uzávěrka, výpočet mezd atd.