Оценка и прогноза на ефективността
Основната задача след изпълнението информационна системае бърз, стабилен и ъптаймкоето удовлетворява потребителите.
Въпреки това, често с увеличаване на броя на потребителите, количеството данни, интензивността на въвеждане, производителността на програмата пада катастрофално. Операциите и времето за реакция на системата са критично увеличени.
Всичко това води до недоволство на потребителите на системата на всички нива и неефективна работа.
Въпреки факта, че подобно поведение на системата е предсказуемо, мнозина не са готови за този сценарий.
Известни са голям брой случаи, когато създаването на счетоводни системи е планирано и извършено без предварителен подробен анализ на това как тази системаще се държи с големи количества данни (например при паралелна интензивна работа на повече от хиляда души). Такива проекти изразходваха огромни суми пари за създаване на система. Но след въвеждането животът на тези системи беше година и половина. Тогава беше заявено, че системата не се справя със задачите, беше разпределен нов бюджет и започна нов проект за въвеждане на „по-добра“ система, което доведе до същите последствия.
В момента има само едно решение този проблем- Стрес тестване.
Стрес тестване
Тестването на натоварването е анализ на поведението на системата при емулиране на реално потребителско натоварване.
Основни цели на тестването на натоварване:
- Тествайте производителността на различни хардуерни и софтуерни конфигурации
- Проверете производителността на системата с различни количества данни
- Определете поведението на системата при стресово натоварване
По този начин тестът за натоварване трябва да позволява следните оценки на системата:
- оценка на работата на информационната система или отделни нейни части при зададените параметри на модела на предприятието с цел:
- избор на оборудване;
- формулиране на оперативни изисквания;
- оценка на приложимостта на информационната система;
- оценка на мащабируемостта на информационната система при промяна:
- сила на звука информационна база;
- броя на едновременните потребители;
- натоварване на системата;
- оценка на промените в показателите за ефективност на системата при промяна:
- функционалност на системата (подобряване на системата или отделни алгоритми);
- хардуерна конфигурация.
- идентифициране на проблеми, които възникват само по време на работа с много потребители (конфликти при заключване и др.).
Тестът за натоварване помага не само да се оценят определени характеристики. Но най-важното е, че ви позволява да идентифицирате тесните места в системата предварително и да разрешите проблема по най-ефективния начин.
Задължителна операция при всяко внедряване или модификация на съществуваща информационна система е да се оцени необходимата скорост на системата и да се планират необходимите изчислителни ресурси за нейното внедряване. В момента няма точно решение на този проблем в общ изгледи ако, въпреки сложността и цената си, такъв алгоритъм бъде предложен от който и да е производител, тогава дори малки промени в хардуера, софтуерната версия, системната конфигурация или броя или стандартното поведение на потребителите ще доведат до значителни грешки.
Въпреки това има достатъчен брой начини за оценка на конфигурацията на софтуера и софтуера, необходим за постигане на необходимата производителност. хардуер. Всички тези методи могат да се използват в процеса на подбор, но потребителят трябва да разбира техния обхват и ограничения.
Мнозинство съществуващи методиоценката на ефективността се основава на определен тип тестване.
Има два основни типа тестване: компонентно и интегрално.
С компонентното тестване се тестват отделни компоненти на решението, вариращи от производителността на процесори или подсистеми за съхранение на информация до тестване на производителността на сървъра като цяло, но без полезния товар под формата на конкретно бизнес приложение.
Интегралният подход се характеризира с оценка на производителността на решението като цяло, както на неговата софтуерна, така и на хардуерна част. В този случай могат да се използват както бизнес приложение, което ще се използва в крайното решение, така и някои моделни приложения, които емулират някои стандартни бизнес процеси и работни натоварвания.
Зеленият цвят на графиката, заедно с някои индикатори вдясно, условно избрани като бенчмаркове, ни позволяват да направим междуплатформена обобщена оценка на „доброто“ представяне.
Как да се насладите на резултатите от теста
В резултат на това сте получили индекс на ефективност (скорост). Няма значение дали резултатът е добър или лош, той е резултат от ПЛАТФОРМАТА, работеща на вашия хардуер. В случай на клиент сървърна версиятова е резултат от сложна верига от заявки, преминаващи през различни сайтове. Получавате общия реален резултат, който се определя от тясното място в системата. Винаги има тясно място.
С други думи, както настройките на СУБД, настройките на ОС, така и оборудването влияят върху общия резултат на екипа.
Кой сървър е по-добър
Този тест, извършен на конкретен сървър, дава резултат за комбинация от хардуерни настройки, операционна система, субд и т.н. Въпреки това, висок резултат на определен сървърен хардуер означава, че при нормални условия същият резултат ще бъде на идентичен сървърен хардуер. Този тест е безплатна помощ за възможността да се сравни инсталацията на 1C:Enterprise под Windows и Linux, три различни СУБД, поддържани от платформата 1C:Enterprise 8.
Тествайте безопасността
Тестът е абсолютно безопасен. Не води до „падане“ на сървъра (няма „стрес“ алгоритъм) и не изисква предварителни мерки дори на „боен“ сървър. Поверителните данни също не се записват в резултатите от теста. Събира информация за параметрите на CPU, RAM, HDD. Серийни номераустройствата не са сглобени. Всичко това може лесно да се провери - тестовият код е 100% отворен. Не е възможно прехвърляне на информация без ваше знание.
Класификация TPC-A-локална пропускателна способност/ TPC-1C-GILV-A
Тестът принадлежи към раздела на универсалните интегрални междуплатформени тестове. Освен това е приложим за файлови и клиент-сървърни варианти на работа на 1C:Enterprise. Тестът работи за всички СУБД, поддържани от 1C.
Универсалността ви позволява да направите обобщена оценка на ефективността, без да сте обвързани с конкретна. типична конфигурацияплатформи.
От друга страна, това означава, че за точни изчисления на персонализиран проект, тестът ви позволява да направите предварителна оценка преди специализирано тестване на натоварване.
Изтегляне на тест
Този тест не е комерсиален и може да бъде изтеглен безплатно за 8.2 и безплатно за 8.3.
Технически подробности
Какво се случва в теста в рамките на "един" цикъл на операцията?
Характеристики на използването на теста в подраздела PostgreSQL
Задайте стойността на параметъра standard_conforming_strings на конфигурационен файл postgresql.conf на "изключено"
Как да измерим натоварването на желязото
Трябва да се отбележи, че самият тест вече частично извършва измерването. За по-подробна картина препоръчвам да използвате помощната програма Process Explorer на Mark Rusinovich.
Фигурата показва пример за измерване за версията на файла.
Всеки специалист по поддръжката има опит в получаването на абстрактни оплаквания от потребители. Всички са запознати с формулировките: „тя мисли много дълго време“, „имам червен прозорец“, „системата работи някак неправилно“, а също „това не се е случвало отдавна и ето го отново ”.
В такава ситуация е много трудно веднага да разберете къде е грешката и какво да направите на първо място. В тази статия ще разгледаме от какво зависи производителността на 1C, т.е. системи с високо натоварване, създадени на базата на 1C:Enterprise, в ситуации, при които симптомите не са напълно разбрани и е невъзможно да се направи конкретна диагноза.
Основните причини, влияещи върху работата на 1C
В повече от 60% от случаите причините за лошото представяне са:
- неоптимални заявки и програмен кодконфигурации (26% от случаите);
- Неоптимално индексиране на обектни таблици (19% от случаите);
- Неоптимално натоварване на дисковата подсистема (16% от случаите).
Водещите разработчици на Microsoft са солидарни с това.
По този начин, за да се постигне значително подобрение в производителността на приложение за база данни, е възможно да се оптимизира областта на достъпа до данни, включително логическия и физически дизайн на базите данни (доколкото е възможно в 1C), както и чрез създаване на правилните заявки и използване на оптимално индексиране. Част от проблемите с производителността на базата данни могат да бъдат решени чрез увеличаване на хардуерния капацитет, но не винаги: грешният дизайн на приложеното решение не може да бъде компенсиран от по-мощен сървър. Не е необичайно, без да разбират причините за проблем с производителността, потребителските компании правят големи разходи, като закупуват ново оборудване, а проблемът остава неразрешен.
Висококачествената диагностика на производителността на 1C с помощта на цялата гама от съществуващи инструменти е ключът към успешното решаване на проблеми и оптимизиране на разходите
Първата стъпка за идентифициране и коригиране на проблеми с лошото представяне трябва да бъде писането пълен списъкключови проблемни операции, като се посочва точната скорост на изпълнението им в момента и очакваната скорост на изпълнението им в бъдеще.
Пример:
Неправилно: Програмата замръзва, докато генерира отчет. Искам да се изгражда по-бързо.
Вдясно: Оформянето на справка "Дългова справка" отнема 5 минути 10 секунди. Очакваната скорост на генериране на този отчет е не повече от 20 секунди.
След като списъкът с проблеми бъде съставен и дигитализиран, е необходимо да се анализират причините, като се започне с търсенето на проблемен код, ако има такъв (например „тежки“ заявки, дълго чакане на заключвания, блокирания и др.).
Инструменти за идентифициране на проблемен код
- 1C:Performance Management Center (модул, включен в инструментариума 1C:Corporate, произведен от 1C);
- облачни услугиГилев;
- Редовни инструменти, вграден в СУБД на водещи производители.
Ефективността на използването на тези инструменти се гарантира от квалификацията на разработчика "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 бази данни. По време на нашите тестове ще се опитаме да отговорим на тези въпроси.
Участници в теста
Операционна система MS Server и СУБД MS SQL
- Компанията 1C открито позиционира този пакет като основен работен модел, съответно продуктите на 1C са създадени предимно за него.
- Наличие на протокол за директен високоскоростен обмен на информация SharedMemory
- Има официален техническа поддръжкаи договори за услуги
- Има база от знания и много информация за инсталирането и фина настройка 1C+MS SQL
Операционна система Unix и СУБД PostgreSQL
- Системата е напълно безплатна (с изключение на лиценза за сървъра 1C:Enterprise)
- Възможно е гъвкаво конфигуриране на много параметри, които подобряват производителността на СУБД
- Декларирана поддръжка за PostgreSQL DBMS от продуктите на 1C
- Възможност за репликация на база данни
Разбира се, цената на проекта, устойчивостта на грешки и техническата поддръжка са важни критерии при избора на информационна система за 1C. Има обаче фактор, който в повечето случаи драматично влияе върху вземането на решение - това е бързината.
Тъй като техническата литература за тези две системи в Интернет е просто страхотна, може да се спори дълго за дълги сравнителни таблици, които в зависимост от целите подчертават предимствата на един или друг продукт. Можете да обсъждате този или онзи параметър сред стотици други от същия вид - колко е уникален по рода си и как влияе върху постигането на резултата. Но теорията без практика е мъртва - предлагаме в тази статия да пропуснете теорията и да преминете директно към фактите, за да тествате работата на двете информационни системи на практика с определено ниво на препоръчителните настройки и в различни опциисървърна архитектура (вижте таблица 2).
Методи за изпитване
В нашите тестове ще разчитаме на два метода за генериране на синтетично натоварване и имитация на работа на потребителя в 1C. Това е тестът Gilev (TPC-1C) и специален тест 1C "Test Center" от инструментариума 1C: KIP със специални потребителски сценарии.
Тест на Гилев (TPC-1C)
Гилев тестпринадлежи към раздела за универсални крос-платформени тестове за натоварване. Може да се използва както за файлова, така и за клиент-сървърна архитектура 1C:Enterprise. Тестът измерва количеството работа за единица време в една нишка и е подходящ за оценка на скоростта на натоварвания с една нишка, включително скоростта на чертане на интерфейса, въздействието на разходите за ресурси, повторно публикуване на документи, процедури в края на месеца, заплати и т.н. Универсалността ви позволява да направите обобщена оценка на производителността, без да сте обвързани с конфигурация на една платформа. Резултатът от теста е обща оценка на измерената система 1C, изразена в произволни единици.
Специализиран тест от инструментариума на тестовия център 1C: KIP
Тестови център- инструмент за многопотребителско тестване на натоварване на системи, базирани на 1C: Enterprise 8 (виж Фигура 1). С негова помощ можете да симулирате работата на компанията без участието на реални потребители, което ви позволява да оцените приложимостта, производителността и мащабируемостта на информационната система в реални условия. Системата представлява конфигурация, която осигурява механизъм за управление на процеса на тестване. За да тествате информационна база, е необходимо да интегрирате конфигурацията на тестовия център в конфигурацията на тестваната база данни чрез сравняване и обединяване на конфигурации. В резултат на сливането обектите и общите модули, необходими за работата на Тестовия център, ще бъдат добавени към метаданните на тестваната база данни.
Фигура 1 - Схема на работа "Център за тестване" 1C: оборудване
По този начин, използвайки инструментариума 1C: инструментариум, въз основа на наличните данни в реални производствени бази на 1C, програмистът генерира пълноценен сценарий за автоматично тестване въз основа на списък от документи и справочници, които са ключови за от този типконфигурация (заявка за разходване на средства, поръчка към доставчик, продажба на стоки и услуги и др.). Когато стартирате сценария, Тестовият център автоматично ще възпроизведе дейността за много потребители, описана в сценария. За да направите това, тестовият център ще създаде необходимия брой виртуални потребители (в съответствие със списъка с роли) и ще започне изпълнението на действията.
Опции за тестване
Когато настройвате тестови сценарии за надеждно симулиране на едновременната работа на голям брой потребители, за всеки тип документ се задават определени тестови параметри (вижте таблица 1):
- Документ - посочва конкретен документ в работната база данни, на базата на който ще се извърши тестване на натоварване
- Приоритет на изпълнение - формира реда, в който се изпълняват тестове за всеки тип документ
- Брой документи – определя обема на генерираните тестови документи
- Пауза, секунди - забавяне при стартиране на серия от тестове в рамките на един и същи тип документ
- Броят на редовете в документа е информационен указател, който отчита „масивността“ на тестовия документ, което влияе върху времето за обработка и натоварването на ресурсите
Тестовете се извършват в 3 итерации, резултатите се записват в таблица. По този начин получените резултати от теста, измерени в секунди, най-реалистично и обективно отразяват нивото на производителност на 1C базите в условия, възможно най-близки до реалните (вижте таблици 3.1 и 3.2).
Таблица 1. Параметри на тестовия скрипт
| Документ | Приоритетно стартиране | Брой документи | Пауза, секунди | Брой редове в документа | |
| Роля 1 | Фактура на купувача | 1 | 25 | 51 | 62 |
| Получаване на стоки | 2 | 25 | 80 | ||
| Продажба на стоки | 3 | 25 | 103 | ||
| Парични преводи | 4 | 25 | 1 | ||
| Купувачът връща | 5 | 25 | 82 | ||
| Роля 2 | Фактура на купувача5 | 10 | 65 | 79 | |
| Получаване на стоки | 1 | 22 | 80 | ||
| Продажба на стоки | 2 | 25 | 103 | ||
| Парични преводи | 3 | 25 | 1 | ||
| Купувачът връща | 4 | 25 | 75 | ||
| Роля 3 | Фактура на купувача | 4 | 15 | 45 | 76 |
| Получаване на стоки | 5 | 26 | 80 | ||
| Продажба на стоки | 1 | 52 | 103 | ||
| Парични преводи | 2 | 26 | 1 | ||
| Купувачът връща | 3 | 32 | 90 | ||
| Роля 4 | Фактура на купувача | 3 | 45 | 38 | 70 |
| Получаване на стоки | 4 | 30 | 80 | ||
| Продажба на стоки | 5 | 30 | 103 | ||
| Парични преводи | 1 | 20 | 1 | ||
| Купувачът връща | 2 | 20 | 86 | ||
| Роля 5 | Фактура на купувача | 2 | 30 | 73 | 76 |
| Получаване на стоки | 3 | 30 | 80 | ||
| Продажба на стоки | 4 | 30 | 103 | ||
| Парични преводи | 5 | 18 | 1 | ||
| Купувачът връща | 1 | 18 | 91 | ||
| Роля 6 | Фактура на купувача | 1 | 40 | 35 | 86 |
| Получаване на стоки | 2 | 40 | 80 | ||
| Продажба на стоки | 3 | 40 | 103 | ||
| Парични преводи | 4 | 40 | 1 | ||
| Купувачът връща | 5 | 40 | 88 | ||
| Роля 7 | Фактура на купувача | 5 | 25 | 68 | 80 |
| Получаване на стоки | 1 | 25 | 80 | ||
| Продажба на стоки | 2 | 25 | 103 | ||
| Парични преводи | 3 | 25 | 1 | ||
| Купувачът връща | 4 | 25 | 90 | ||
| Роля 8 | Фактура на купувача | 3 | 25 | 62 | 87 |
| Получаване на стоки | 4 | 25 | 80 | ||
| Продажба на стоки | 5 | 25 | 103 | ||
| Парични преводи | 1 | 25 | 1 | ||
| Купувачът връща | 2 | 25 | 92 | ||
| Роля 9 | Фактура на купувача | 2 | 20 | 82 | 82 |
| Получаване на стоки | 4 | 20 | 80 | ||
| Продажба на стоки | 5 | 20 | 103 | ||
| Парични преводи | 1 | 20 | 1 | ||
| Купувачът връща | 3 | 20 | 98 | ||
| Роля 10 | Фактура на купувача | 4 | 50 | 2 | 92 |
| Получаване на стоки | 1 | 50 | 80 | ||
| Продажба на стоки | 2 | 50 | 103 | ||
| Парични преводи | 5 | 50 | 1 | ||
| Купувачът връща | 3 | 50 | 98 |
Таблица 2. Спецификации стенд за изпитване
| №p\p | Ролята на системата | CPU\vCPU | RAM, GB | Дискова I/O система |
| 1 | Терминален сървър – виртуална машиназа управление на тестове | 4 ядра 2,9 GHz |
16 гигабайта | Intel Sata SSD Raid1 |
| 2 | Сценарий 1.Сървър 1C + СУБД хардуер | Intel Xeon E5-2690 16 ядра |
96 GB | Intel Sata SSD Raid1 |
| 3 | Сценарий 2.Сървър 1C + СУБД виртуален | 16 ядра 2,9 GHz |
64 GB | Intel Sata SSD Raid1 |
| 4 | Сценарий 3.Сървър 1C виртуален | 16 ядра 2,9 GHz |
32 GB | Intel Sata SSD Raid1 |
| 5 | Сценарий 4. DBMS сървър виртуален | 16 ядра 2,9 GHz |
32 GB | Intel Sata SSD Raid1 |
| 6 | Софтуер |
|
||
| 7 | Конфигурации 1C |
|
||
Таблица 3.1 Резултати от теста с теста на Гилев (TPC-1C). Най-високата стойност се счита за оптимална.
Таблица 3.2 Резултати от теста с помощта на специален тест 1C: KIP. Най-малката стойност се счита за оптимална.
| операционна система Microsoft сървър | Операционна система от клас Unix | |||||
| Списък с тестове (средна стойност въз основа на резултатите от серия от 3 теста) | Хардуерен сървър 1C + СУБД, протокол SharedMemory | Виртуален сървър 1C + СУБД, протокол SharedMemory | 1C хардуерен сървър и СУБД хардуерен сървър, TCP-IP протокол | Виртуален сървър 1C и виртуален сървърСУБД, TCP-IP протокол | ||
| Извършване на 1C: KIP тестове на съществуваща база данни, конфигурация Accounting Enterprise | ||||||
| Оборотна ведомост | 1.741 сек | 2,473 сек | 2,873 сек | 2,522 сек | 13.866 сек | 9.751 сек |
| Извършване на връщане на стоки от купувачи | 0,695 сек | 0,775 сек | 0,756 сек | 0.781 сек | 0,499 сек | 0,719 сек |
| Обработка на платежни нареждания | 0,048 сек | 0,058 сек | 0,063 сек | 0,064 сек | 0,037 сек | 0,065 сек |
| Провеждане на PTIS | 0,454 сек | 0,548 сек | 0,535 сек | 0,556 сек | 0,362 сек | 0,568 сек |
| Извършване на продажба на стоки и услуги | 0,667 сек | 0,759 сек | 0,747 сек | 0,879 сек | 0,544 сек | 0,802 сек |
| Осчетоводяване на фактура за плащане | 0,028 сек | 0,037 сек | 0,037 сек | 0,038 сек | 0,026 сек | 0,038 сек |
| Изчисляване на прогнозни разходи | 3.071 сек | 3,657 сек | 4.094 сек | 3,768 сек | 15.175 сек | 10.68 сек |
| Провеждане на 1C: KIP тестове на съществуващата база, конфигурация за управление на търговията | ||||||
| Изнасяне и връщане от клиента | 2.192 сек | 2.113 сек | 2.070 сек | 2,418 сек | 1.417 сек | 1,494 сек |
| Изнасяне и връщане на стоки към доставчика | 1,446 сек | 1410 сек | 1.359 сек | 1,467 сек | 0,790 сек | 0,849 сек |
| Осчетоводяване на поръчка за продажба | 0,355 сек | 0,344 сек | 0,335 сек | 0,361 сек | 0,297 сек | 0,299 сек |
| Извършване на преброяване на стоки | 0,140 сек | 0.134 сек | 0.131 сек | 0.144 сек | 0,100 сек | 0,097 сек |
| Извършване на получаване на спецификации | 1499 сек | 1,438 сек | 1.412 сек | 1,524 сек | 1.097 сек | 1.189 сек |
| Осъществяване изпълнението на ТС | 1390 сек | 1,355 сек | 1.308 сек | 1,426 сек | 1.093 сек | 1.114 сек |
| Провеждане на RKO | 0,759 сек | 0,729 сек | 0,713 сек | 0,759 сек | 0,748 сек | 0,735 сек |
- В специален тест 1C операциите за „четене на данни и сложни изчисления“, като „Оборотен баланс“ и „Изчисляване на прогнозни разходи“ са няколко пъти по-бързи на MS SQL СУБД от Microsoft.
- В операциите за "записване на данни и публикуване на документи" в повечето тестове СУБД PostgreSQL, оптимизирана за 1C, показва най-добър резултат.
- Синтетичният тест на Гилев също показва предимството на PostgreSQL. Този факт е свързан с факта, че синтетичният тест се основава на измерване на скоростта на създаване и осчетоводяване на определени видове документи, което също се счита за операциите „запис на данни и осчетоводяване на документи“.
Нека завършим със сравнението между платформи, нека преминем към сравненията във всяка система:
- Както се очакваше, тестовете на 1C на хардуерна платформа показват по-добри резултати, отколкото на виртуална. Разликата в резултатите от специалния тест 1C и в двата случая е малка, което показва постепенната оптимизация на производителите на виртуални хипервизори.
- Очаква се също, че използването на технологията за споделена памет (SharedMemory) ускорява процеса на обмен на данни между 1C сървъра и СУБД. Съответно резултатите от теста са малко по-добри от тези на схемата с мрежово взаимодействие на тези две услуги чрез TCP-IP протокола.
Можем да заключим, че с правилната настройка на 1C и СУБД можете да постигнете значителни резултати дори на безплатна софтуер. Следователно, когато се проектира нова ИТ структура за 1C, е необходимо да се вземе предвид нивото на натоварване на системата, вида на преобладаващите операции в базата данни, наличния бюджет, наличието на специалист по нестандартна СУБД, необходимостта от интеграция с външни услуги и др. Въз основа на тези данни вече е възможно да се избере необходимото решение.
Прочетете за тестване.
Добър ден мили мои.
Тази бележка е намек за мен и другите.
Тази информация е полезна за начинаещи за създаване и оптимизиране на базата данни 1C на SQL сървъра
Когато нямате опит със сървърната част на 1C, тогава когато възникне такова желание и / или нужда, има доста нюанси и не очевидни неща.
Тъжно е, че дори такова просто търсене като избора на сървър за 1C не гарантира успех и може да срещнете изключително бавната му производителност.
Тук на етапа на разбиране какво не е наред и може да е необходимо да разберете в каква последователност и какво да правите.
Започнете. Не забравяйте да архивирате вашите данни.
Моят сървър е базиран на Windows Server 2012 R2 стандарт и SQL 2012.
Може да имате други входящи кутии, няма значение (засега).
Взехме интегрираната доставка на USP (тя включва 10 клиентски лиценза, сървър (само 32 бита) и конфигурации на ZUP, UT, счетоводство и самата USP. Трябва да се отбележи, че франчайзополучателите искаха да включат изцяло отделни доставки и CORP е по-добре веднага.Анализът показа, че това е излишно и е по-евтино да се вземе сложна конфигурация.
Когато избирате хардуер, важно е да запомните, че във версията клиент-сървър на 1C се нуждаете от максималната честота на процесора, както и честотата на паметта (запомнете това, когато избирате хардуер). (тоест Hyper trading и всички видове C1-2-3 състояния е най-добре да бъдат деактивирани в BIOS).
Също така е необходимо „физически“ да се разпространи основният файл (MDF) и лог файлът (LDF), за да се разделят твърдите дискове, а не логическите дискове.
И ако за файловата версия би било оптимално да се препоръча SSD, тогава тук не всичко е толкова очевидно.
Отидете във форума на Gilev, за да се запознаете с "мистериите", които възникват в опит да се подобри работата на 1C. Много интересно.
В моя случай колегите администратори ми назначиха блейд на блейд сървър, с 2 физически процесора AMD Quad-Core Opteron (tm) Processor 2354, с 16 GB (667 MHz). Система на 2 диска в огледало. Дисковете за основата бяха разпределени от Fiber Chanel, на HP EVA.
Сега търся друга конфигурация, но засега трябва да живея на тази.
И на етапа на внедряване, докато се извършва анализът как да се прехвърлят данни от друга ERP система, програмистът 1C ми обърна внимание на бавната работа и дългите документи. Тоест системата все още не се експлоатира, но вече се забавя и умира, а повторното провеждане е 3 пъти по-бавно от това на човек на лаптоп и хората също ще трябва да работят с това (3-4 основни и 25-40 таймера).
Не ред.
Той препоръча използването на теста Gilev (сайтът му е лесен за гугъл), който е пълен с услуги за поддръжка и информация. Което той използва.
Тестът показа, че всичко е лошо и липсва препоръчителният брой потребители.
Като се вгледах по-внимателно, разбрах, че базата и дневникът са поне на различни дискове - но логически.
И за да коригирам това, направих екранни снимки и тази бележка за бъдещето за себе си и другите:
Създаване на база данни в SQL сървърмениджмънт студио. Ние разпространяваме базата данни и регистрационния файл на различни физически дискове.
Изберете Прост метод за възстановяване
Ние създаваме нова базачрез 1C клиент на компютър
Изберете да добавите информационна база. В нашия случай няма конфигурация.
Задайте име. Всеки тук. По-добре отколкото на сървъра.
Попълваме данните. Когато е посочено на сървъра, името на сървъра е 127.0.0.1 - иначе не работи.
не променяй нищо тук
Зареждаме нашата информационна база (налична преди или нова, например тест)
Всъщност изборът на база. Зареждам теста на Гилев за платформа 8.3
Потвърждаваме
Потвърждаваме
Резюме на теста. Всичко все още е лошо, но препоръчителният брой потребители е повече от необходимия, което е добре.
P.S. Не забравяйте да направите резервно копие.
P.P.S., когато изпълнявате теста Gilev в тестовата база данни, която се намира на същите места за съхранение като всяка бойна база данни - имайте предвид, че поне лог-файлът има тенденция да заема всичко свободно място, което е изпълнено със спиране на бойната база и не преминаване на теста !!!
P.P.P.S също така не забравяйте, че SQL работи с помощта на базата данни TEMP, разположена на същото място, където е инсталиран SQL (по подразбиране в C).
Затова е желателно да се подобри достъпът и до тази база данни.
Също така информация за помощ - Effector Saver ви позволява да запазите 1s от основата
Няма смисъл да архивирам всичко останало, тъй като в моя случай лицензите са софтуерни и когато се прехвърлят на друг хардуер, лицензите излитат.
От доп.
Ако искате да дадете на потребителите на домейн свободата да създават всяка база данни с помощта на 1C, тогава сметка 1C сървърните услуги за създаване на акаунт на домейн, който има право да създава бази данни без никакви системни администратори, са достатъчни,
в същото време не е необходимо да пишете потребителско име и парола в свойствата на информационната база ...
Зареждане...