Стандартен тест за натоварване. Стандартен тест за натоварване Нашата конфигурация за тестване

1C Test Center 8 е специализиран софтуерен продукт от 1C, който ви позволява да оцените производителността на системата и да проучите тесните места на информационната система.

Преди това разгледахме персонализирана конфигурация. Сега ще научим как да създаваме сценарии за тестване на многопотребителска конфигурация от потребители и да изпълняваме самото тестване.

Скриптът за тестване в 1C Test Center е написан в специално създадена обработка. Този шаблон се намира вътре в конфигурацията и има името „TCTestProcessingTemplate“. За да създадете свой собствен тестов скрипт, трябва да копирате този шаблон и въз основа на него да създадете свой собствен, нов, нека го наречем „Повторно осчетоводяване на разписка за стоки“:

Нека добавим нов атрибут към обработката и да го покажем във формата - “DocumentForCopying”, това е документът, който ще копираме.

Нека разгледаме по-отблизо модула за формуляри. В него можете да използвате три процедури - TCIinitialize(), TTSExecute(), Delete().

TCIinitialize - използва се за първоначално попълване на настройките на информационната база, например попълване на счетоводната политика.
TCExecute е основният модул, в който директно се пише скриптът за тестване.
TCUDeleteData е модул, който описва изтриването на обекти, създадени по време на процеса на тестване.

Нека напишем най-простия код в процедурата TCExecute(), която ще копира избрания документ 5 пъти подред и ще измерва копирането и публикуването на всеки документ:

За th=1 до 5 цикъл

Инструменти = KipExternalComponent.GetTools();
StartTime = KipExternalComponent.TimerValue(Инструменти);

Вземете безплатно 267 видео урока за 1C:

Създаване на документи ();

EndTime = KipExternalComponent.TimerValue(Инструменти);
Продължителност на изпълнение = (Краен час - Начален час) / 1000;

TCWriteIndicator("Време за изпълнение", Продължителност на изпълнение);

EndCycle;

Връщане на TCExecutionResultSuccessfully();

Процедурата CreateDocuments() ще бъде изпълнена на сървъра:

Процедура CreateDocuments()

NewDocument = TCObject.DocumentForCopying.Copy();
NewDocument.Date = CurrentDate();
NewDocument.Write(DocumentWriteMode.Post);

EndProcedure

Това завършва подготовката на скрипта, нека да преминем към тестовия център за провеждане на тестване на натоварването.

Настройка на 1C Test Center 8.3

След като напишем теста, ще започнем да настройваме самия тестов център. За да конфигурирате, трябва да попълните редица справочници:

Лечения— директория, съдържаща списък с процеси, свързани с тестване. Обработката може да бъде вътрешна и външна.
Роли— директория за съхраняване на връзката обработка-обработка на настройките. Настройките са данни, които са индивидуални за всеки тест (брой итерации, копиран документ и др.).
Потребители— списък на потребителите и техните пароли.
Компютри— списък на компютрите, на които ще бъде извършен тестът.
клиенти -настройка къде, от кого и в какъв режим ще се стартира натоварването.

Тестови сценарии

Основният справочник, който консолидира всички настройки: колко пъти, от кой потребител, под какво име ще се извършва тестване на натоварването.

Също така в раздела „Параметри“ можете да конфигурирате сценарий за техническо тестване:

След като настроите скрипта, остава само да го стартирате.

Стартиране на тестване в 1C: Тестови център

Когато всичко е готово, остава само да започнете работата по тестването.

За да направите това, трябва да стартирате поне две сесии на програмата: първата - в ролята на т.нар. „агент“, а вторият като инициатор на стартирането на скрипта.

Стартиране на агента:

Изпълнение на скрипта:

За да стартирате, просто изберете желания скрипт от списъка и щракнете върху бутона Run.

Всеки специалист по поддръжката има опит в получаването на абстрактни оплаквания от потребители. Всички са запознати с формулировките: „тя мисли много дълго време“, „имам червен прозорец“, „системата работи някак си погрешно“, а също „това не се е случвало отдавна и ето го е отново.”

В такава ситуация е много трудно веднага да разберете къде е грешката и какво да направите първо. В тази статия ще разгледаме от какво зависи производителността на 1C, т.е. високо натоварени системи, създадени на базата на 1C:Enterprise, в ситуации, при които симптомите не са напълно разбрани и не може да се направи конкретна диагноза.

Основните причини, влияещи върху работата на 1C

В повече от 60% от случаите причините за ниската производителност са:

Неоптимални заявки и конфигурационен код (26% от случаите);
Неоптимално индексиране на обектни таблици (19% от случаите);
Неоптимално натоварване на дисковата подсистема (16% от случаите).

Водещите разработчици на Microsoft са съгласни с това.

По този начин, за да се постигне значително подобрение в производителността на приложение за база данни, е възможно да се оптимизира обхватът на достъпа до данни, включително логическия и физически дизайн на базите данни (доколкото е възможно в 1C), както и чрез създаване на правилния заявки и използване на оптимално индексиране. Някои проблеми с производителността на базата данни могат да бъдат решени чрез увеличаване на хардуерния капацитет, но не винаги: неправилният дизайн на приложното решение не може да бъде компенсиран от по-мощен сървър. Не е необичайно, без да разбират причините за проблем с производителността, компаниите потребители правят значителни разходи чрез закупуване на ново оборудване, но проблемът остава неразрешен.

Висококачествената диагностика на производителността на 1C с помощта на цялата гама от съществуващи инструменти е ключът към успешното решаване на проблеми и оптимизиране на разходите

Първата стъпка за идентифициране и разрешаване на проблеми с ниска производителност е да се разработи изчерпателен списък на ключовите проблемни дейности, включително текущата им скорост и очакваната бъдеща скорост.

Пример:

Неправилно: Програмата замръзва при генериране на отчет. Искам да се образува по-бързо.

Правилно: Отчетът „Дългова справка“ се генерира за 5 минути 10 секунди. Очакваната скорост на генериране на този отчет е не повече от 20 секунди.

След като списъкът с проблеми е съставен и дигитализиран, е необходимо да се анализират причините, като се започне с търсене на проблемен код, ако има такъв (например „тежки“ заявки, дълго чакане на заключвания, блокировки и др.).

Инструменти за идентифициране на проблемен код

„1C: Център за управление на производителността“ (модул, включен в инструменталния пакет „1C: Corporate“, произведен от 1C);
Облачни услуги Gilev;
Стандартни инструменти, вградени в СУБД от водещи производители.

Ефективността на използването на тези инструменти се гарантира от квалификацията на разработчика „1C: Експерт по технологични въпроси“, което предполага участието му в мащабни внедрявания на 1C. В същото време различни експерти, въз основа на своя личен опит, могат да дадат предпочитание на един или друг инструмент/метод.

Успоредно с използването на един от представените инструменти се използват и стандартни инструменти за наблюдение на натоварването на оборудването (броячи на монитори за производителност).

Въз основа на получените измервания се определя класът на причината:

Проблемът е в кода;
И/или проблемът е в хардуера;
Проблемът е в други програми, изискващи ресурси, използвани на производствени сървъри.

Тестване на натоварването 1C - метод за оценка на сървърното оборудване

Както вече споменахме, сред факторите, които могат да повлияят на работата на 1C, както положително, така и отрицателно, сървърният хардуер и неговата конфигурация заемат важно място. Нека разгледаме опциите за измервания, оценка на натоварването и тестване на производителността на системата при следните условия:

Сървърът 1C е наличен и се намира:
Заедно със СУБД;
На отделен сървър.

За оценка на съответствието на параметрите на съществуващото сървърно оборудване с изискванията на системата е необходимо да се съберат данни за натоварването на хардуера, включително процесора, т.е. 1C тестване на натоварване. За тази цел се използва “Performance Monitor” - инструмент, който ви позволява да измервате оборудването на работната верига и да четете броячите на производителността.

По-долу е даден основен набор от броячи, които трябва да бъдат конфигурирани за наблюдение на производителността на хардуера в Windows. Събирането се извършва от всички сървъри, където са инсталирани 1C сървъри.

Ако броячът на процента натоварване на процесора за изгледа „Процесор“ има висока стойност, трябва да идентифицирате процеси, които могат да бъдат спрени, без да се засяга работата на сървъра, и също така да бъдат прехвърлени към други сървъри.

Изгледът „Процес“ ще ви позволи да конфигурирате наблюдение за всеки отделен процес, както и да определите кои процеси заемат най-много процесорно време. Ако на сървъра е инсталиран само 1C сървър, тогава, за да разберете какво натоварване поставя върху хардуера, трябва да конфигурирате колекцията от следните броячи:

\Process("1cv8*")\% Процесорно време

\Process("ragent*")\% Процесорно време

\Process("ragent*")\Private Bytes

\Process("ragent*")\Virtual Bytes

\Process("rmngr*")\% процесорно време

\Process("rmngr*")\Private Bytes

\Процес("rmngr*")\Виртуални байтове

\Process("rphost*")\% процесорно време

\Process("rphost*")\Private Bytes

\Process("rphost*")\Virtual Bytes

\Process("1cv8*")\Private Bytes

\Process("1cv8*")\Virtual Bytes

Ако текущата система е в незадоволително състояние, тогава въз основа на събраните измервания, като се използва линейна връзка, трябва да се изчислят параметрите на оборудването за инсталиране на целевата система.

Ако само се планира закупуването на сървърно оборудване, неговите параметри могат да бъдат изчислени чрез емулиране на работата на планираната система, но в по-малък мащаб, като се използва съществуващо оборудване. За тази цел се използва „1C: Test Center“, който е включен в 1C Corporate Toolkit. Въз основа на получените измервания, като се използват изчислителни методи, се определят параметрите на планираната система и съответно изискванията към оборудването. Този тест може да се използва многократно за различни измервания, като преди това е допълнена и разширена функционалността. Тази техника има висока точност и лекота на изчисление.

За да разбера реалното натоварване на оборудването, беше необходимо да тествам производителността на 1C терминален сървър в производството, което направих съвсем наскоро и сега искам да представя резултатите, за да могат всички да ги видят.

Прочетете повече в статията.

Ще намерите други статии за 1C в съответния раздел -.

В няколко предишни статии за 1C работих върху изчисляването на сървърни конфигурации за различни натоварвания, генерирани от усилията на основните потребители на 1C, а именно служители на счетоводните и търговските отдели. Задачите на счетоводителите зависят не само от изготвянето на отчети и въвеждането на данни в програмата и затова е по-предпочитано те да имат пълен терминален достъп и да работят с всичко необходимо оттам (). За мениджърите всичко е много по-просто и за тях публикуването на приложение () е напълно приемлив случай на употреба.

Не рискувах да пусна сървъра в производство, без да провеждам реално тестване, така че беше организирано широкомащабно тестване. Предимството му лично за мен беше, че можех да потвърдя (или опровергая) на практика моите теоретични изчисления, чиято основа бяха много субективни показатели за ефективност на работните станции на служителите.

Тестова среда

И така, за тестване взехме сървър с процесор Intel Xeon E5-1650 v3 @ 3,50 GHz, 128 GB RAM, 2*SSD в RAID 1. На този сървър е разположена виртуална машина, която е само терминален сървър, с инсталирани приложения 1C 8.2, 1C 8.3, MS Office 2013 Pro.

Веднага ще кажа, че естеството на натоварването беше смесено, тоест имаше клиенти, работещи чрез RemoteApp, и имаше такива, които влязоха изцяло чрез RDP и използваха програмите, необходими за тяхната работа (не само 1C, но и Office ). Разпределението беше приблизително както следва: 24 RemoteApp сесии, 5 RDP клиента.

Потребителите бяха изправени пред задачата да влизат в приложения на всеки 30 минути в продължение на два часа и да изпълняват ежедневни задачи в тях - създаване на отчети, отпечатване на данни, публикуване на документи, експортиране на данни в други формати и т.н. Основното е, че нямаше цел да поставите сървъра целта беше да се даде реално средно дневно натоварване.

Резултати от тестовете

Всичко започна както обикновено - потребителите от третото натискане, вече от ръководители на отдели и по-горе, започнаха да влизат в 1C и да изпълняват рутинни задачи. Всичко това не продължи дълго и имах само един шанс да взема показателите за производителност на сървъра възможно най-близо до реалното натоварване. Ето какво получих в крайна сметка:

RAM (динамично разпределената памет беше зададена на виртуалния сървър, така че ако е необходимо, текущото количество RAM постоянно се променяше нагоре):

Сега е необходимо да се анализират резултатите и да се направят изводи.

Анализ на данни

Трябва да се отбележи, че изчисленията за процесора се оказаха изключително точни.

В статията емпирично установих, че потреблението на процесорен ресурс на една сесия на 1C RemoteApp е средно 122 775 процесорни единици за производителност (данните за производителността са взети от уебсайта www.cpubenchmark.net). В друга статия изчислих ресурсите, необходими за стартиране на пълна RDP сесия и те възлизат на 4% от Core i5 4460, тоест 0,04 * 6622 (данните също са с www.cpubenchmark.net) = 264,88.

Общо получаваме:

пълна RDP сесия изяжда 264,88 единици за производителност на процесора;
сесия 1C RemoteApp консумира 122,775 единици.

Най-отгоре споменах, че има 24 потребители на RemoteApp и 5 RDP. Ние броим:

24 * 122,775 + 5 * 264,88 = 4271

Относителният индекс на производителност на Intel Xeon E5-1650 v3 е 13477 единици. Тоест теоретично Натоварването на процесора трябва да бъде около 32% (4271 / 13477 * 100).

Графиката на натоварване на процесора показва, че във времевия интервал 10:30 - 10:50 процесорът се натоварва с 25 - 40% (пиковете не се броят). Разбира се, няма да получите права линия на натоварване на процесора от 32%; все още ще има колебания от минимуми до относителни максимуми, но като цяло можем да приемем, че реалните данни са в съответствие с теоретичните. Между другото, колкото повече потребители има на вашия сървър, толкова по-равномерно ще бъде натоварването.

Всъщност данните от RAM се оказаха по-ценни. Според изчисленията от предишни статии имах:

2GB на RDP сесия;
100 MB на сесия на RemoteApp.

Тоест обемът на заетата памет трябваше да е максимум 12,4 GB + малко за ОС. Но, както се оказа и аз по принцип имах предчувствие, тази стойност на практика беше съвсем друга цифра. 1C се оказа много алчен за RAM, за мое съжаление. Освен това приложението се държи по такъв начин, че след като е заело място, не смята за необходимо да го освободи в момента, в който вече не е необходимо:

Е, нормално ли е да изяде 2GB RAM и да седи и да не прави нищо (натоварването на процесора на сесията е 0%). Съвременните програмисти изобщо не се интересуват от оптималното използване на ресурсите. Лично аз, когато бях в университета, бях принуден да пренапиша кода на приложението, ако беше написан нерационално по отношение на използването на изчислителни ресурси. Явно квалификацията на съвременните програмисти е паднала под цокъла или може би това е просто подход - защо да оптимизираме вече написан код, когато е по-добре да разработваме нова функционалност. Като цяло не е важното, бомбардира и това е добре.

От 16 GB „говорители“, разпределени на сървъра, той ги изяде всички и най-вероятно поиска повече. На теория, ако има недостиг на RAM, операционната система ще се смени на диска и в този случай започва сериозен спад в производителността. В моя случай това не беше така и най-вероятно това се дължи на SSD, който практически не показа никакво натоварване - само два краткотрайни пика през целия тестов период (от 10:00 до 12:00). Въпреки това, както показва практиката, не препоръчвам да спестявате RAM на терминалния сървър.

Стандартният тест за натоварване е предназначен да оцени производителността на сървърния хардуер и софтуер в така наречените „Стандартни 1C потребители“. Основната област на приложение на този тест е изборът на сървърни хардуерни и софтуерни конфигурации за целите на конкретна реализация.

Проблеми за решаване

Изчисляване на производителността на дадена конфигурация на сървърен хардуер и софтуер
Сравняване на производителността на различни сървърни хардуерни и софтуерни конфигурации
Избор на необходимото оборудване за функционирането на тази информационна система
Изчисляване на параметрите на оборудването, необходимо за работата на тази информационна система

Какво оценява тестът?

Тестът оценява ефективността целият набор от сървърен хардуер и сървърен софтуерот гледна точка на задачите, характерни за системи, работещи на платформата 1C:Enterprise 8. Тоест получената оценка не отразява производителността на нито един сървърен компонент на системата (например работещ сървър в клъстер 1C:Enterprise), а по-скоро цялата конфигурация на сървъра като цяло. Сървърната част на системата, чиято производителност се измерва с този тест, включва:

всички работещи сървъри, използвани за разгръщане на клъстера 1C:Enterprise и СУБД сървъри
операционни системи на всички работещи сървъри;
настройки на операционни системи, 1C:Enterprise и СУБД.

По време на тестването тестът автоматично ще увеличи броя на едновременните потребители, докато един от хардуерните или софтуерните компоненти на системата вече не може да се справи с натоварването. Това ще доведе до лоша оценка за ефективност и тестът ще спре с последната добра стойност като резултат. В същото време останалите компоненти могат да бъдат подтоварени в една или друга степен.

По този начин тестът оценява производителността на сървърната част на системата въз основа на нейното тясно място, тоест нейният най-малко продуктивен компонент.

Ако сървърната част на системата не е добре балансирана за работа с 1C:Enterprise, тогава чрез премахване на пречка (замяна или надграждане на най-малко продуктивния компонент) можете да получите по-висок рейтинг на производителност.

Моля, обърнете внимание, че тестът по никакъв начин не оценява производителността на клиентската част на системата, така че този фактор трябва да бъде напълно изключен. С други думи, клиентските работни станции не трябва да се превръщат в тясно място на системата. Този въпрос е разгледан по-подробно в главата „Подготовка на клиентската част на тестовия стенд“.

Как работи тестът

Стандартният тест за натоварване е информационна база 1C:Enterprise 8.2 с конфигурация, базирана на „Manufacturing Enterprise Management“. Конфигурацията е комбинирана с Test Center 2.0, който включва един тестов скрипт.

Сценарият за тестване включва емулация на бизнес процеса „продажби в SCP“, а именно: създаване на няколко различни документа, генериране на отчети и други приложени действия. Тестът работи в пълен паралелен режим, т.е. всеки потребител работи със свои собствени уникални данни и няма чакания при заключване. Потребителят извършва един пълен цикъл на продажба на минута.

Внедряването на 1C инфраструктура на Linux е древна тема, но все още актуална. Наскоро публикувахме статия 1C Application Server на Linux, но въпросът за реалната производителност в сравнение с решение за Windows остана отворен. Тестването беше проведено и в ръчен режим, но за обективност на резултатите ще публикувам резултатите от теста на Гилев, който беше проведен на една и съща хардуерна платформа с различни операционни системи: Linux CentOS 7 и MS Windows Server 2012 .

За сървър е използвана стойка с два процесора Intel Xeon E5-2670, 8x4GB RAM и Intel SSD.

Обобщена таблица на средните стойности на резултатите от теста на Гилев.

Примери за резултати

Приемливите резултати от тестовете, лекотата на внедряване и ниските разходи за лицензиране ни подтикнаха да създадем цялостен продукт: Linux-базиран 1C сървър от кутията.

Всеки модел има удобен конфигуратор, в който можете да изберете оптималната конфигурация за вашите задачи. Ето малко повече за това.

Създаването на калкулатор за изчислителна мощност на 1C сървър не е тривиална задача. И създаването на универсален 1C конфигуратор за всички възможни случаи е почти невъзможно.

Със сигурност има много администратори в центъра, които имат собствена представа за изискванията за натоварване и изчислителна мощност на 1C сървърите (Вашите коментари ще увеличат стойността на тази статия). Има и официални препоръки на 1C, в които всичко ще работи на всичко...

Но все още има основни параметри, които могат да бъдат изчислени, приложими към типична оперативна схема. Знаейки колко ресурси на процесора и RAM консумира терминална сесия, колко IOPS SQL ще изисква за определен брой потребители и въз основа на резултатите от многобройни тестове, ние разработихме конфигуратор за стандартно решение за 1C.

Разбира се, всеки случай е уникален и изисква подробна предварителна продажба, но за приблизително изчисление е достатъчно да посочите броя на потребителите, вида на базата данни, обема на текущата база данни и да изберете необходимите лицензи.

За да сравня цената на готово решение, базирано на Linux и Windows, ще дам пример от конфигуратора с цени на дребно.

Сървър за 20 потребители с SQL база данни до 80 GB, лиценз 1C: Accounting 8 PROF, базиран на Linux CentOS, ще струва 522 759,43 рубли. Подобна конфигурация, базирана на Windows - 1 036 279,43 рубли.

Гамата от сървъри за 1C STSS Flagman се състои от 3 модела за Linux и Windows.

1C113.5-020UL- начален 1C сървър, поддръжка на до 20 потребители с SQL база данни. Количеството дисково пространство се изчислява, като се вземе предвид нарастването на базата данни с 20% годишно за 3 години. RAID1 масивът е базиран на Intel Enterprise SSD. Има възможност за инсталиране на двойно захранване и допълнителни дискове за „студени“ данни. Предлага се избор от софтуерни услуги: PostgreSQL, xrdp и httpd.

1C216.4-200UL- модел, базиран на 2-процесорна платформа, която осигурява работата на 1C инфраструктура за до 200 едновременни връзки. Хранилището се изчислява по същия принцип - размерът на базата данни, като се вземе предвид растежът, но е изграден на базата на RAID10 масив от 4xSSD с необходимия обем.

1C217.2-050UL-REF- това е решение за клиенти с ограничен бюджет, изградено на базата на сървър, възстановен в нашето производство (след гаранционна подмяна, демо фонд и т.н.) Сървърите преминават същите тестове за натоварване преди изпращане като новите модели, но имат съкратен гаранционен срок (1 година). Сървърът поддържа до 50 връзки и, с изключение на лицензите, струва само 203 705,00 рубли с масив за база данни от 40 GB.

1C113.5-020UW- начален 1C сървър, поддръжка на до 20 потребители с SQL база данни. Количеството дисково пространство се изчислява, като се вземе предвид нарастването на базата данни с 20% годишно за 3 години. RAID1 масивът е базиран на Intel Enterprise SSD. Има възможност за инсталиране на двойно захранване и допълнителни дискове за „студени“ данни.

1C216.4-200UW- Модел, базиран на Windows, поддържащ до 200 потребители. Хранилището е изградено на базата на RAID10 масив от 4xSSD с необходимия обем.

1C217.2-050UW-REF- същата платформа като базираното на Linux решение. Бюджетен вариант за 50 връзки, 1 година гаранция.

Следните лицензи могат да бъдат избрани като платформа 1C във всички модели:

1C: Управление на малка фирма 8 ПРОФ
1C: Управление на търговията 8 ПРОФ
1С: Счетоводство 8 ПРОФ
1C: Счетоводство 8 CORP
1C: Заплата и управление на персонала 8 ПРОФ
1C: Заплата и управление на персонала 8 CORP
1C: Документооборот 8 ПРОФ
1C: Документооборот 8 KORP

Ако клиентът има достатъчно опит, за да избере сървър за 1C, той може да използва класически модели сървърно оборудване. Но ако няма такава експертиза, тогава, надявам се, нашият сървърен конфигуратор за 1C ще ви помогне да направите оптималния избор на система.

Благодаря за вниманието! Надявам се, че потребителите на habra, близки до тази тема, ще споделят опита си при избора на оборудване за 1C в коментарите.

Може да е полезно да прочетете: