Teljesítményértékelés és előrejelzés
A fő feladat a megvalósítás után tájékoztatási rendszer a gyors, stabil és üzemidő ami kielégíti a felhasználókat.
Azonban gyakran a felhasználók számának, az adatok mennyiségének, a bevitel intenzitásának növekedésével a program teljesítménye katasztrofálisan csökken. A műveletek és a rendszer válaszideje kritikusan megnő.
Mindez a rendszer felhasználóinak minden szinten elégedetlenségéhez és nem hatékony munkához vezet.
Annak ellenére, hogy a rendszer ilyen viselkedése kiszámítható, sokan nem állnak készen erre a forgatókönyvre.
Nagyon sok olyan eset ismert, amikor a számviteli rendszerek létrehozását anélkül tervezték meg és hajtották végre, hogy előzetesen részletesen megvizsgálták volna, hogyan ezt a rendszert nagy mennyiségű adattal fog viselkedni (például több mint ezer ember párhuzamos intenzív munkájával). Az ilyen projektek hatalmas összegeket költöttek egy rendszer létrehozására. De a bevezetés után ezeknek a rendszereknek az élettartama másfél év volt. Majd elhangzott, hogy a rendszer nem birkózik meg a feladatokkal, új költségvetést különítettek el, és új projekt indult egy „jobb” rendszer bevezetésére, ami ugyanazokkal a következményekkel járt.
Jelenleg egyetlen megoldás létezik ez a probléma- Stresszteszt.
Stressz tesztelés
A terhelési tesztelés a rendszer viselkedésének elemzése valós felhasználói terhelés emulálásakor.
A terheléses tesztelés fő céljai:
- Tesztelje a teljesítményt különféle hardver- és szoftverkonfigurációkon
- Ellenőrizze a rendszer teljesítményét különböző mennyiségű adattal
- Határozza meg a rendszer viselkedését feszültségterhelés alatt!
Így a terhelési tesztnek lehetővé kell tennie a következő rendszerértékeléseket:
- az információs rendszer vagy egyes részei teljesítményének értékelése a vállalati modell adott paramétereivel annak érdekében, hogy:
- felszerelés kiválasztása;
- működési követelmények megfogalmazása;
- az információs rendszer alkalmazhatóságának felmérése;
- az információs rendszer skálázhatóságának értékelése változáskor:
- hangerő információs bázis;
- az egyidejű felhasználók száma;
- terhelés a rendszeren;
- a rendszer teljesítménymutatóiban bekövetkezett változások értékelése változtatáskor:
- a rendszer funkcionalitása (a rendszer vagy az egyes algoritmusok fejlesztése);
- hardver konfiguráció.
- olyan problémák azonosítása, amelyek csak a többfelhasználós munka során merülnek fel (zárkonfliktusok stb.).
A terhelési teszt nemcsak bizonyos jellemzők értékelésében segít. De ami a legfontosabb, lehetővé teszi a rendszer szűk keresztmetszetek előzetes azonosítását és a probléma leghatékonyabb megoldását.
Meglévő információs rendszer bármely bevezetése vagy módosítása esetén kötelező művelet a rendszer szükséges sebességének felmérése és a megvalósításhoz szükséges számítási erőforrások tervezése. Jelenleg nincs pontos megoldás erre a problémára Általános nézet, és ha bonyolultsága és költsége ellenére bármelyik gyártó javasol egy ilyen algoritmust, akkor a hardver, a szoftver verzió, a rendszerkonfiguráció vagy a felhasználók számának vagy szokásos viselkedésének kis változtatása is jelentős hibákhoz vezet.
Ennek ellenére elegendő számú módszer létezik a szükséges teljesítmény eléréséhez szükséges szoftverek és szoftverek konfigurációjának értékelésére. hardver. Mindezek a módszerek használhatók a kiválasztási folyamatban, de a fogyasztónak meg kell értenie azok terjedelmét és korlátait.
Többség meglévő módszereket a teljesítményértékelés egy bizonyos típusú tesztelésen alapul.
A tesztelésnek két fő típusa van: komponens és integrál.
A komponensteszttel a megoldás egyes összetevőit tesztelik, kezdve a processzorok vagy az információtároló alrendszerek teljesítményétől a szerver egészének teljesítményének teszteléséig, de egy adott üzleti alkalmazás terhelése nélkül.
Az integrált megközelítést a megoldás egészének, szoftveres és hardveres részeinek teljesítményének értékelése jellemzi. Ebben az esetben a végső megoldásban használt üzleti alkalmazás és néhány olyan modellalkalmazás is használható, amelyek emulálnak néhány szabványos üzleti folyamatot és munkaterhelést.
A grafikon zöld színe néhány jobb oldali mutatóval együtt, amelyeket feltételesen viszonyítási alapnak választottak, lehetővé teszi, hogy platformokon átívelő általánosított értékelést készítsünk a „jó” teljesítményről.
Hogyan élvezheti a teszteredményeket
Ennek eredményeként teljesítményindexet (sebesség) kapott. Nem számít, hogy az eredmény jó vagy rossz, ez a hardveren futó PLATFORM eredménye. Ügyfél esetén szerver verzió ez egy összetett kéréslánc eredménye, amely különböző webhelyeken halad át. Megkapja az összesített tényleges eredményt, amelyet a rendszer szűk keresztmetszete határoz meg. Mindig van egy szűk keresztmetszet.
Más szóval, mind a DBMS-beállítások, mind az operációs rendszer beállításai, mind a berendezések befolyásolják a csapat általános eredményét.
Melyik szerver jobb
Ez a teszt, amelyet egy adott szerveren hajtanak végre, a hardverbeállítások, az operációs rendszer, az alprogram stb. kombinációjára ad eredményt. Egy adott szerverhardveren elért magas pontszám azonban azt jelenti, hogy normál körülmények között ugyanaz az eredmény lesz az azonos szerverhardveren. Ez a teszt ingyenes segítség az 1C:Enterprise 8 platform által támogatott három különböző DBMS Windows és Linux alatti telepítésének összehasonlításához.
Teszt biztonság
A teszt teljesen biztonságos. Ez nem vezet a szerver „bedőléséhez” (nincs „stressz” algoritmus), és még „harci” szerveren sem igényel előzetes intézkedéseket. A bizalmas adatokat szintén nem rögzítik a teszteredmények. Információkat gyűjt a CPU, RAM, HDD paramétereiről. Sorozatszámok az eszközök nincsenek összeszerelve. Mindez könnyen ellenőrizhető - a tesztkód 100%-ban nyitva van. Az Ön tudta nélkül információátadás nem lehetséges.
Osztályozás TPC-A-helyi áteresztőképesség/ TPC-1C-GILV-A
A teszt az univerzális integrált keresztplatformos tesztek részéhez tartozik. Ezenkívül az 1C:Enterprise művelet fájl- és kliens-szerver változataira is alkalmazható. A teszt az 1C által támogatott összes DBMS-re működik.
Az univerzalitás lehetővé teszi a teljesítmény általános értékelését anélkül, hogy egy konkrét értékeléshez kötődne. tipikus konfiguráció platformok.
Másrészt ez azt jelenti, hogy egy egyedi projekt pontos számításaihoz a teszt lehetővé teszi, hogy előzetes értékelést készítsen a speciális terhelési tesztelés előtt.
Letöltés teszt
Ez a teszt nem kereskedelmi jellegű, és ingyenesen letölthető a 8.2-es verzióhoz és ingyenesen a 8.3-as verzióhoz.
Műszaki információk
Mi történik a tesztben a művelet "egy" ciklusán belül?
A teszt használatának jellemzői a PostgreSQL aloldalon
Állítsa be a standard_conforming_strings paraméter értékét erre konfigurációs fájl postgresql.conf "off" értékre
Hogyan mérjük meg a vas munkaterhelését
Megjegyzendő, hogy maga a teszt már részben elvégzi a mérést. A részletesebb képhez Mark Rusinovich Process Explorer segédprogramját javaslom.
Az ábra a fájlverzió mérésére mutat példát.
Minden ügyfélszolgálati szakember rendelkezik tapasztalattal a felhasználók absztrakt panaszainak fogadásában. Mindenki ismeri a megfogalmazást: "nagyon sokáig gondolkodik", "piros ablakom van", "valahogy rosszul működik a rendszer", és azt is, hogy "ez már rég nem történt meg, és itt van újra ”.
Ilyen helyzetben nagyon nehéz azonnal kitalálni, hol van a hiba, és mit kell tenni először. Ebben a cikkben megvizsgáljuk, hogy mitől függ az 1C teljesítménye, pl. Az 1C:Enterprise alapján létrehozott nagy terhelésű rendszerek olyan helyzetekben, amikor a tünetek nem teljesen ismertek, és lehetetlen konkrét diagnózist felállítani.
Az 1C teljesítményét befolyásoló fő okok
Az esetek több mint 60%-ában a gyenge teljesítmény okai a következők:
- szuboptimális lekérdezések és programozási kód konfigurációk (az esetek 26%-a);
- Objektumtáblázatok szuboptimális indexelése (az esetek 19%-a);
- Szuboptimális terhelés a lemez alrendszeren (az esetek 16%-a).
A Microsoft vezető fejlesztői szolidárisak ezzel.
Így egy adatbázis-alkalmazás teljesítményének jelentős javulása érdekében lehetőség nyílik az adatelérési terület optimalizálására, beleértve az adatbázisok logikai és fizikai tervezését (amennyire lehetséges az 1C-ben), valamint megfelelő lekérdezések létrehozásával és optimális indexeléssel. Az adatbázis-teljesítményproblémák egy része megoldható a hardver kapacitás növelésével, de nem mindig: az alkalmazott megoldás hibás kialakítását nem tudja kompenzálni egy erősebb szerver. Nem ritka, hogy anélkül, hogy megértenék a teljesítményproblémák okait, a felhasználó cégek nagy kiadásokat költenek új berendezések vásárlására, és a probléma továbbra is megoldatlan.
Az 1C teljesítményének kiváló minőségű diagnosztikája a meglévő eszközök teljes skálájával a sikeres problémamegoldás és a költségoptimalizálás kulcsa
A gyenge teljesítményű problémák azonosításának és kijavításának első lépése az írás teljes lista kulcsfontosságú problémás műveletek, jelezve azok végrehajtásának pillanatnyi pontos sebességét és a jövőben várható végrehajtási sebességet.
Példa:
Helytelen: A program lefagy jelentéskészítés közben. Azt akarom, hogy gyorsabban épüljön fel.
Jobbra: Az "Adósságnyilatkozat" jelentés elkészítése 5 perc 10 másodpercet vesz igénybe. A jelentés elkészítésének várható sebessége nem haladja meg a 20 másodpercet.
A problémalista összeállítása és digitalizálása után elemezni kell az okokat, kezdve a problémás kód keresésével, ha van ilyen (például „súlyos” kérések, hosszú várakozási zárak, holtpontok stb.).
Eszközök a problémás kód azonosítására
- 1C:Performance Management Center (az 1C által gyártott 1C:Corporate eszközkészletben található modul);
- felhő szolgáltatások Gilev;
- Rendszeres eszközök, amely a vezető gyártók DBMS-ébe van beépítve.
Ezen eszközök használatának hatékonyságát a fejlesztő "1C: Technological Expert" minősítése garantálja, ami azt jelenti, hogy részt vesz az 1C nagyszabású megvalósításában. Ugyanakkor a különböző szakértők egyéni tapasztalataik alapján előnyben részesíthetik egyik vagy másik eszközt/módszert.
Az egyik bemutatott eszköz használatával párhuzamosan a szabványos terhelésfigyelő eszközöket is alkalmazzák („Teljesítményfigyelők” számlálók).
A kapott mérések alapján kiderül az ok osztálya:
- A probléma a kódban van;
- És/vagy probléma a hardverben;
- A probléma az éles szervereken használt egyéb erőforrás-igényes programokban van.
1C terhelési tesztelés - a szerver hardverének értékelési módszere
Mint már említettük, az 1C teljesítményét pozitívan és negatívan befolyásoló tényezők között fontos helyet foglal el a szerver hardvere és konfigurációja. Fontolja meg a terhelés mérésének, értékelésének és a rendszer teljesítményének tesztelésének lehetőségeit a következő feltételek mellett:
- Az 1C szerver elérhető és található:
- DBMS-sel együtt;
- Külön szerveren.
Ahhoz, hogy a meglévő szerverhardver paraméterei megfeleljenek a rendszer követelményeinek, adatokat kell gyűjteni a hardver, ezen belül a processzor terheléséről, pl. terhelési vizsgálat 1C. Ehhez a "Teljesítményfigyelőt" használják - egy olyan eszközt, amely lehetővé teszi a munkakörön lévő berendezések mérését és a teljesítményszámlálók eltávolítását.
Az alábbiakban egy alapvető számlálókészlet található, amelyeket be kell állítani a hardver teljesítményének figyeléséhez a Windows rendszerben. A gyűjtemény minden olyan szerverről készül, amelyre 1C szerverek telepítve vannak.
Ha a processzor százalékos számlálója a "Processzor" nézetben magas, akkor azonosítani kell azokat a folyamatokat, amelyek a szerver működésének befolyásolása nélkül leállíthatók, és átvihetők más szerverekre.
A "Folyamat" nézet lehetővé teszi az egyes folyamatok megfigyelésének beállítását, valamint annak meghatározását, hogy melyik folyamat igényel a legtöbb CPU-időt. Ha csak az 1C szerver van telepítve a szerverre, akkor annak megértéséhez, hogy milyen terhelést ad a hardvernek, be kell állítania a következő számlálók gyűjteményét:
| \Process("1cv8*")\% Processzoridő |
| \Process("ragent*")\% Processzoridő |
| \Process("ragent*")\Privát bájtok |
| \Process("ragent*")\Virtuális bájtok |
| \Process("rmngr*")\% Processzoridő |
| \Process("rmngr*")\Private Bytes |
| \Process("rmngr*")\Virtuális bájtok |
| \Process("rphost*")\% Processzoridő |
| \Process("rphost*")\Private Bytes |
| \Process("rphost*")\Virtuális bájtok |
| \Process("1cv8*")\Private Bytes |
| \Process("1cv8*")\Virtuális bájtok |
Ha a jelenlegi rendszer nem kielégítő állapotban van, akkor az összegyűjtött mérések alapján alkalmazva lineáris függőség, ki kell számítania a berendezés paramétereit a célrendszer telepítéséhez.
Ha szerver hardver beszerzése csak tervben van, paraméterei a tervezett rendszer működésének emulálásával, de kisebb léptékben, a meglévő berendezéseken számíthatók. Ehhez az "1C: Test Center"-t használják, amely az 1C vállalati eszközkészletben található. A kapott mérések alapján a számítási módszerek segítségével meghatározzák a tervezett rendszer paramétereit, és ennek megfelelően a berendezésekkel szemben támasztott követelményeket. Ez a teszt a funkcionalitás kiegészítése és bővítése után többször is használható különböző mérésekhez. Ez a technika nagy pontossággal és egyszerű számítással rendelkezik.
Számviteli és vezetői számvitel Az 1C cégek a leggyakoribbak az Orosz Föderációban. Cégek ezrei végzik üzleti tevékenységüket szabványos és speciális 1C konfigurációk alapján. Ilyen tömeges használat mellett rendszeresen felmerül számos kérdés a szoftverek költségvetésének optimalizálásával és az erőforrások ésszerű felhasználásával kapcsolatban. A komplexum szerverrészei körüli viták nem csillapodnak, különös tekintettel arra, hogy melyik operációs rendszerre épüljön az 1C szerver, és melyik DBMS-re bízza az 1C adatbázisok feldolgozását. Tesztjeink során ezekre a kérdésekre próbálunk választ adni.
Teszt résztvevői
MS Server operációs rendszer és MS SQL DBMS
- Az 1C vállalat nyíltan pozícionálja ezt a csomagot a fő működési modellként, illetve az 1C termékeket elsősorban erre hozták létre.
- Közvetlen nagy sebességű információcsere protokolljának jelenléte SharedMemory
- Van egy tisztviselő technikai támogatásés szolgáltatási szerződések
- Tudásbázis és rengeteg információ áll rendelkezésre a telepítésről és finomhangolás 1C+MS SQL
Unix operációs rendszer és PostgreSQL DBMS
- A rendszer teljesen ingyenes (kivéve az 1C:Enterprise szerver licencét)
- Sok olyan paraméter rugalmasan konfigurálható, amelyek javítják a DBMS teljesítményét
- Az 1C termékek által bejelentett PostgreSQL DBMS támogatás
- Adatbázis replikáció lehetősége
Természetesen a projekt költsége, a hibatűrés és a műszaki támogatás fontos kritériumok az 1C információs rendszerének kiválasztásakor. Van azonban egy tényező, amely a legtöbb esetben drámaian befolyásolja a döntéshozatalt – ez a gyorsaság.
Mivel az interneten e két rendszer szakirodalma egyszerűen nagyszerű, hosszan lehetne vitatkozni a hosszú összehasonlító táblázatokról, amelyek a céloktól függően hangsúlyozzák egyik vagy másik termék előnyeit. Megbeszélheti ezt vagy azt a paramétert több száz hasonló típus között - mennyire egyedi a maga nemében, és hogyan befolyásolja az eredmény elérését. De az elmélet gyakorlat nélkül halott - ebben a cikkben azt javasoljuk, hogy hagyja ki az elméletet, és menjen közvetlenül a tényekre, hogy mindkét információs rendszer teljesítményét a gyakorlatban tesztelje, bizonyos szintű ajánlott beállítások mellett. különféle lehetőségeket szerver architektúra (lásd 2. táblázat).
Vizsgálati módszerek
Tesztjeink során a szintetikus terhelés generálásának és a felhasználói munka utánzásának két módszerére támaszkodunk 1C-ben. Ez a Gilev teszt (TPC-1C) és egy speciális teszt 1C "Tesztközpont" az 1C: KIP eszközkészletből speciális felhasználói forgatókönyvekkel.
Gilev-teszt (TPC-1C)
Gilev teszt az univerzális keresztplatformos terhelési tesztek részéhez tartozik. Fájlokhoz és kliens-szerver 1C:Enterprise architektúrához egyaránt használható. A teszt az egységnyi időegységre eső munka mennyiségét méri egy szálban, és alkalmas az egyszálas munkaterhelések sebességének felmérésére, beleértve a felület rajzolásának sebességét, az erőforrás költségek hatását, a dokumentumok újraküldését, a hónap végi eljárásokat, a bérszámfejtést. stb. Az univerzalitás lehetővé teszi a teljesítmény összefoglaló értékelését anélkül, hogy egyetlen platformkonfigurációhoz lenne kötve. A teszt eredménye a mért 1C rendszer teljes értékelése, tetszőleges mértékegységben kifejezve.
Speciális teszt a Tesztközpont 1C eszközkészletéből: KIP
Tesztközpont- egy eszköz az 1C: Enterprise 8-on alapuló rendszerek többfelhasználós terhelési tesztelésére (lásd 1. ábra). Segítségével valós felhasználók részvétele nélkül szimulálhatja a cég munkáját, ami lehetővé teszi az információs rendszer alkalmazhatóságának, teljesítményének és skálázhatóságának valós körülmények közötti értékelését. A rendszer egy olyan konfiguráció, amely mechanizmust biztosít a tesztelési folyamat kezelésére. Egy információs bázis teszteléséhez a tesztközpont konfigurációját a konfigurációk összehasonlításával és összevonásával integrálni kell a tesztelt adatbázis konfigurációjába. Az összevonás eredményeként a Tesztközpont működéséhez szükséges objektumok, közös modulok bekerülnek a tesztelés alatt álló adatbázis metaadatai közé.
1. ábra - A "Tesztközpont" 1C munkavázlata: műszerezés
Így az 1C: műszerkészletet használva, a valós 1C gyártási bázisokban rendelkezésre álló adatok alapján a programozó egy teljes értékű automatikus tesztelési forgatókönyvet generál a kulcsfontosságú dokumentumok és referenciakönyvek listája alapján. ebből a típusból konfiguráció (költési alapok igénylése, megrendelés szállítónak, áruk és szolgáltatások értékesítése stb.). A forgatókönyv futtatásakor a Tesztközpont automatikusan lejátssza a forgatókönyvben leírt többfelhasználós tevékenységet. Ehhez a Tesztközpont létrehozza a szükséges számú virtuális felhasználót (a szerepkörök listájának megfelelően), és megkezdi a műveletek végrehajtását.
Tesztopciók
Amikor nagyszámú felhasználó egyidejű munkáját megbízhatóan szimulálja a tesztforgatókönyveket, minden dokumentumtípushoz beállítanak bizonyos tesztparamétereket (lásd 1. táblázat):
- Dokumentum - egy adott dokumentumot jelöl a munkaadatbázisban, amely alapján terhelési vizsgálatot végeznek
- Futtatási prioritás – meghatározza az egyes dokumentumtípusokhoz tartozó tesztek futtatásának sorrendjét
- Dokumentumok száma – meghatározza a generált tesztdokumentumok mennyiségét
- Szünet, másodperc – késleltetés egy tesztsorozat indításakor ugyanazon a dokumentumtípuson belül
- A dokumentumban lévő sorok száma egy információs mutató, amely a tesztdokumentum „tömegességét” jelzi, ami befolyásolja a feldolgozási időt és az erőforrások terhelését.
A teszteket 3 iterációban hajtjuk végre, az eredményeket táblázatban rögzítjük. Így a kapott, másodpercben mért teszteredmények a legreálisabban és legobjektívebben tükrözik az 1C bázisok teljesítményszintjét a valóshoz lehető legközelebbi körülmények között (lásd 3.1 és 3.2 táblázat).
1. táblázat: Parancsfájl-paraméterek tesztelése
| Dokumentum | Indítsa el a Prioritást | Dokumentumok száma | Szünet, másodperc | Sorok száma a dokumentumban | |
| 1. szerep | Vevői számla | 1 | 25 | 51 | 62 |
| Áruátvétel | 2 | 25 | 80 | ||
| Árueladás | 3 | 25 | 103 | ||
| Pénzügyi átutalások | 4 | 25 | 1 | ||
| Vevő visszaküldi | 5 | 25 | 82 | ||
| 2. szerep | Vevői számla5 | 10 | 65 | 79 | |
| Áruátvétel | 1 | 22 | 80 | ||
| Árueladás | 2 | 25 | 103 | ||
| Pénzügyi átutalások | 3 | 25 | 1 | ||
| Vevő visszaküldi | 4 | 25 | 75 | ||
| 3. szerep | Vevői számla | 4 | 15 | 45 | 76 |
| Áruátvétel | 5 | 26 | 80 | ||
| Árueladás | 1 | 52 | 103 | ||
| Pénzügyi átutalások | 2 | 26 | 1 | ||
| Vevő visszaküldi | 3 | 32 | 90 | ||
| 4. szerep | Vevői számla | 3 | 45 | 38 | 70 |
| Áruátvétel | 4 | 30 | 80 | ||
| Árueladás | 5 | 30 | 103 | ||
| Pénzügyi átutalások | 1 | 20 | 1 | ||
| Vevő visszaküldi | 2 | 20 | 86 | ||
| 5. szerep | Vevői számla | 2 | 30 | 73 | 76 |
| Áruátvétel | 3 | 30 | 80 | ||
| Árueladás | 4 | 30 | 103 | ||
| Pénzügyi átutalások | 5 | 18 | 1 | ||
| Vevő visszaküldi | 1 | 18 | 91 | ||
| 6. szerep | Vevői számla | 1 | 40 | 35 | 86 |
| Áruátvétel | 2 | 40 | 80 | ||
| Árueladás | 3 | 40 | 103 | ||
| Pénzügyi átutalások | 4 | 40 | 1 | ||
| Vevő visszaküldi | 5 | 40 | 88 | ||
| 7. szerep | Vevői számla | 5 | 25 | 68 | 80 |
| Áruátvétel | 1 | 25 | 80 | ||
| Árueladás | 2 | 25 | 103 | ||
| Pénzügyi átutalások | 3 | 25 | 1 | ||
| Vevő visszaküldi | 4 | 25 | 90 | ||
| 8. szerep | Vevői számla | 3 | 25 | 62 | 87 |
| Áruátvétel | 4 | 25 | 80 | ||
| Árueladás | 5 | 25 | 103 | ||
| Pénzügyi átutalások | 1 | 25 | 1 | ||
| Vevő visszaküldi | 2 | 25 | 92 | ||
| 9. szerep | Vevői számla | 2 | 20 | 82 | 82 |
| Áruátvétel | 4 | 20 | 80 | ||
| Árueladás | 5 | 20 | 103 | ||
| Pénzügyi átutalások | 1 | 20 | 1 | ||
| Vevő visszaküldi | 3 | 20 | 98 | ||
| 10. szerep | Vevői számla | 4 | 50 | 2 | 92 |
| Áruátvétel | 1 | 50 | 80 | ||
| Árueladás | 2 | 50 | 103 | ||
| Pénzügyi átutalások | 5 | 50 | 1 | ||
| Vevő visszaküldi | 3 | 50 | 98 |
2. táblázat. Műszaki adatok próbapad
| №p\p | A rendszer szerepe | CPU\vCPU | RAM, GB | Lemez I/O rendszer |
| 1 | Terminál szerver – Virtuális gép tesztkezeléshez | 4 mag 2,9 GHz |
16 GB | Intel Sata SSD Raid 1 |
| 2 | 1. forgatókönyv. Szerver 1C + DBMS hardver | Intel Xeon E5-2690 16 mag |
96 GB | Intel Sata SSD Raid 1 |
| 3 | 2. forgatókönyv. 1C szerver + DBMS virtuális | 16 mag 2,9 GHz |
64 GB | Intel Sata SSD Raid 1 |
| 4 | 3. forgatókönyv. 1C virtuális szerver | 16 mag 2,9 GHz |
32 GB | Intel Sata SSD Raid 1 |
| 5 | 4. forgatókönyv. DBMS szerver virtuális | 16 mag 2,9 GHz |
32 GB | Intel Sata SSD Raid 1 |
| 6 | Szoftver |
|
||
| 7 | Konfigurációk 1C |
|
||
3.1. táblázat Vizsgálati eredmények Gilev-teszttel (TPC-1C). A legmagasabb érték tekinthető optimálisnak.
3.2 táblázat Vizsgálati eredmények speciális teszttel 1C: KIP. A legkisebb érték tekinthető optimálisnak.
| operációs rendszer Microsoft Server | Unix osztályú operációs rendszer | |||||
| Vizsgálatok listája (átlagérték 3 tesztsorozat eredménye alapján) | Hardverszerver 1C + DBMS, SharedMemory protokoll | Virtuális szerver 1C + DBMS, SharedMemory protokoll | 1C hardverszerver és DBMS hardverszerver, TCP-IP protokoll | Virtuális szerver 1C és virtuális szerver DBMS, TCP-IP protokoll | ||
| 1C: KIP tesztek végrehajtása egy meglévő adatbázison, konfiguráció Accounting Enterprise | ||||||
| Forgalmi mérleg | 1,741 mp | 2,473 mp | 2,873 mp | 2,522 mp | 13,866 mp | 9,751 mp |
| Az áruk vevőktől való visszaküldése | 0,695 mp | 0,775 mp | 0,756 mp | 0,781 mp | 0,499 mp | 0,719 mp |
| Fizetési megbízások feldolgozása | 0,048 mp | 0,058 mp | 0,063 mp | 0,064 mp | 0,037 mp | 0,065 mp |
| PTIS lebonyolítása | 0,454 mp | 0,548 mp | 0,535 mp | 0,556 mp | 0,362 mp | 0,568 mp |
| Áruk és szolgáltatások értékesítésének lebonyolítása | 0,667 mp | 0,759 mp | 0,747 mp | 0,879 mp | 0,544 mp | 0,802 mp |
| Számla feladása fizetésről | 0,028 mp | 0,037 mp | 0,037 mp | 0,038 mp | 0,026 mp | 0,038 mp |
| Költségbecslések számítása | 3,071 mp | 3,657 mp | 4,094 mp | 3,768 mp | 15,175 mp | 10,68 mp |
| 1C: KIP tesztek elvégzése a meglévő alapon, Trade Management konfiguráció | ||||||
| Lebonyolítás és visszaküldés az ügyféltől | 2,192 mp | 2,113 mp | 2,070 mp | 2,418 mp | 1,417 mp | 1,494 mp |
| Áruk szállítása és visszaküldése a szállítónak | 1,446 mp | 1410 mp | 1,359 mp | 1,467 mp | 0,790 mp | 0,849 mp |
| Értékesítési rendelés feladása | 0,355 mp | 0,344 mp | 0,335 mp | 0,361 mp | 0,297 mp | 0,299 mp |
| Áruk újraszámlálása | 0,140 mp | 0,134 mp | 0,131 mp | 0,144 mp | 0,100 mp | 0,097 mp |
| A specifikációk átvételének lebonyolítása | 1499 mp | 1,438 mp | 1,412 mp | 1,524 mp | 1,097 mp | 1,189 mp |
| A TS megvalósításának elvégzése | 1390 mp | 1,355 mp | 1,308 mp | 1,426 mp | 1,093 mp | 1,114 mp |
| RKO végrehajtása | 0,759 mp | 0,729 mp | 0,713 mp | 0,759 mp | 0,748 mp | 0,735 mp |
- Egy speciális 1C tesztben az „adatok olvasása és összetett számítások”, például a „Forgalmi mérleg” és a „Költségbecslések kiszámítása” műveletei többszörösen gyorsabbak a Microsoft MS SQL DBMS-én.
- A legtöbb tesztben az "adatírás és dokumentumok feladása" műveletekben az 1C-re optimalizált PostgreSQL DBMS mutatja a legjobb eredményt.
- Gilev szintetikus tesztje is megmutatja a PostgreSQL előnyeit. Ez összefügg azzal, hogy a szintetikus teszt bizonyos típusú bizonylatok létrehozásának és feladásának sebességének mérésén alapul, ami egyben az „adatrögzítés és iratfeladás” műveleteinek is tekinthető.
Fejezzük be a platformok közötti összehasonlítással, és folytassuk az egyes rendszereken belüli összehasonlításokat:
- Ahogy az várható volt, az 1C tesztek hardveres platformon jobb eredményeket mutatnak, mint egy virtuálison. A speciális 1C teszt eredményei között mindkét esetben kicsi a különbség, ami a virtuális hipervizor gyártók fokozatos optimalizálását jelzi.
- Az is várható, hogy a megosztott memória technológia (SharedMemory) használata felgyorsítja az adatcsere folyamatát az 1C szerver és a DBMS között. Ennek megfelelően a teszteredmények valamivel jobbak, mint a két szolgáltatás TCP-IP protokollon keresztüli hálózati interakciójával végzett séma eredményeinél.
Megállapíthatjuk, hogy az 1C és a DBMS helyes beállításával akár ingyenesen is jelentős eredményeket érhet el szoftver. Ezért az 1C új informatikai struktúrájának tervezésekor figyelembe kell venni a rendszer terhelési szintjét, az adatbázisban uralkodó műveletek típusát, a rendelkezésre álló költségvetést, a nem szabványos DBMS-ben dolgozó szakember jelenlétét, a külső szolgáltatásokkal való integráció igénye stb. Ezen adatok alapján már ki lehet választani a kívánt megoldást.
Olvasson tovább a teszteléshez.
Jó napot kedveseim.
Ez a jegyzet egy tipp számomra és mások számára.
Ez az információ hasznos kezdőknek az 1C adatbázis létrehozásához és optimalizálásához az SQL szerveren
Ha nincs tapasztalata az 1C szerver részével, akkor amikor ilyen vágy és/vagy igény merül fel, jó néhány árnyalat van, és nem nyilvánvaló dolgok.
Szomorú, hogy még egy olyan egyszerű küldetés, mint a szerver kiválasztása az 1C-hez, nem garantálja a sikert, és előfordulhat, hogy rendkívül lassú teljesítménnyel találkozhat.
Itt a szakaszban, hogy kitaláljuk, mi a hiba, és szükség lehet annak megértésére, hogy milyen sorrendben és mit kell tenni.
Kezdődik. Ne felejtsen el biztonsági másolatot készíteni adatairól.
A szerverem a Windows Server 2012 R2 szabványon és az SQL 2012-en alapul.
Lehet, hogy más postaládái vannak, ez nem számít (egyelőre).
Átvettük az Integrated USP szállítást (10 kliens licencet, egy szervert (csak 32 bites), valamint a ZUP, UT, Accounting és magát az USP konfigurációit tartalmazza. Figyelemre méltó, hogy a franchise átvevők a külön szállításokat teljes egészében, ill. A CORP azonnal jobb, az elemzés azt mutatta, hogy ez felesleges, és olcsóbb egy összetett konfigurációt venni.
A hardver kiválasztásakor fontos, hogy ne feledje, hogy az 1C kliens-szerver verziójában szüksége van a maximális processzor-frekvenciára, valamint a memória frekvenciájára (ne feledje ezt a hardver kiválasztásakor). (vagyis a Hyper kereskedést és mindenféle C1-2-3 állapotot legjobban letiltani a BIOS-ban).
Szükséges továbbá az alapfájl (MDF) és a naplófájl (LDF) „fizikai” szétosztása a merevlemezekre, nem pedig a logikai meghajtókra.
És ha a fájlverzióhoz optimális lenne egy SSD-t ajánlani, akkor itt nem minden olyan nyilvánvaló.
Látogasson el a Gilev fórumra, hogy megismerkedjen az 1C teljesítményének javítása érdekében felmerülő "rejtélyekkel". Sok érdekesség.
Az én esetemben adminisztrátortársak blade-et rendeltek hozzám egy blade szerveren, 2 fizikai processzorral AMD Quad-Core Opteron (tm) Processor 2354, 16 GB (667 MHz). Rendszer 2 lemezen egy tükörben. Az alap lemezeit a Fibre Chanel osztotta ki a HP EVA-n.
Most keresek egy másik konfigurációt, de egyelőre ezen kell élnem.
És a megvalósítás szakaszában, miközben az elemzés folyik arról, hogyan lehet adatokat átvinni egy másik ERP rendszerből, az 1C programozó felhívta a figyelmemet a lassú munkára és a hosszú dokumentumokra. Vagyis a rendszert még nem használják ki, de már lassul és haldoklik, és az újravezetés 3-szor lassabb, mint egy laptopon, és ezzel is dolgozni kell majd (3-4 fő és 25-40 időzítő).
Nem rendelni.
Javasolta a Gilev-teszt használatát (az oldalát könnyű google-zni), amely tele van támogatási szolgáltatásokkal és információkkal. Amit használt.
A teszt kimutatta, hogy minden rossz, és hiányzik az ajánlott számú felhasználó.
Jobban megnézve rájöttem, hogy az alap és a napló legalábbis különböző lemezeken van - de logikusan.
És ennek kijavítására készítettem képernyőképeket és ezt a megjegyzést a jövőre nézve magamnak és másoknak:
Adatbázis létrehozása benne SQL szerver vezetői stúdió. Az adatbázist és a naplót különböző fizikai lemezekre terjesztjük.
Válassza az Egyszerű helyreállítási módszert
Mi alkotunk új alap 1C kliensen keresztül számítógépen
Válassza ki az információs bázis hozzáadását. A mi esetünkben nincs konfiguráció.
Állítson be egy nevet. Bármelyik itt. Jobb, mint a szerveren.
Az adatokat kitöltjük. Amikor a szerveren jelezték, a kiszolgáló neve 127.0.0.1 - egyébként nem működött.
ne változtass itt semmit
Feltöltjük információs bázisunkat (korábban elérhető vagy új, pl. teszt)
Valójában az alap kiválasztása. Betöltöm a Gilev tesztjét a 8.3-as platformhoz
Megerősítjük
Megerősítjük
Teszt összefoglaló. Még mindig minden rossz, de az ajánlott felhasználószám meghaladja a szükségeset, ami jó.
P.S. Ne felejtsen el biztonsági másolatot készíteni.
P.P.S. amikor a Gilev-tesztet futtatja a tesztadatbázisban, amely ugyanazokon a tárolóhelyeken található, mint bármely harci adatbázis - ne feledje, hogy legalább a naplófájl általában mindent elfoglal szabad hely, ami tele van a harci bázis megállításával és a teszten való át nem menéssel !!!
A P.P.P.S ne feledje, hogy az SQL a TEMP adatbázis használatával fut, amely ugyanazon a helyen található, ahol az SQL telepítve van (alapértelmezés szerint a C-ben).
Ezért kívánatos ezen adatbázishoz való hozzáférés javítása is.
Szintén segítő információ - Az Effector Saver lehetővé teszi, hogy 1-et mentsen az alapból
Nincs értelme minden másról biztonsági másolatot készíteni, mivel az én esetemben a licencek szoftverek, és egy másik hardverre áthelyezve a licencek elszállnak.
Továbbitól.
Ha szabadságot szeretne adni a domain felhasználóknak bármilyen adatbázis létrehozására az 1C használatával, akkor fiókot 1C szerverszolgáltatások elegendő egy adatbázis létrehozására jogosult domain fiók létrehozásához rendszergazdák nélkül,
ugyanakkor nem kell beírni a bejelentkezést és a jelszót az infobázis tulajdonságai közé ...
Betöltés...