Оцінка та прогноз продуктивності
Основне завдання після впровадження інформаційної системиє її швидка, стабільна та безвідмовна робота, яка задовольняє користувачів.
Проте часто зі збільшенням кількості користувачів, обсягу даних, інтенсивності введення, швидкодія програми катастрофічно падає. Час виконання операцій та відгуку системи критично збільшується.
Все це призводить до невдоволення користувачів системи всіх рівнів і неефективної роботи.
Незважаючи на те, що така поведінка системи прогнозована, багато хто виявляється не готовим до цього варіанту подій.
Відома велика кількість випадків, коли планувалося та здійснювалося створення систем обліку без попереднього детального аналізу того, як дана системаповодитиметься з великими обсягами даних (наприклад при паралельній інтенсивній роботі більше тисячі осіб). Такі проекти витрачали величезні кошти створення системи. Але після застосування термін життя цих систем становив рік, півтора. Потім констатувалося, що система не справляється із завданнями, виділявся новий бюджет і починався новий проект впровадження «кращої» системи, яка спричиняла ті самі наслідки.
На даний момент є тільки одне рішення даного питання- тестування навантаження.
Тестування навантаження
Навантажувальне тестування – аналіз поведінки системи при емуляції реального навантаження користувача.
Основні цілі навантажувального тестування:
- Перевірити продуктивність на різних програмно-апаратних конфігураціях
- Перевірити продуктивність системи за різних обсягів даних
- Визначити поведінку системи при стресовому навантаженні
Таким чином, навантажувальний тест повинен дозволити зробити наступні оцінки системи:
- оцінку продуктивності інформаційної системи або окремих її частин при заданих параметрах моделі підприємства з метою:
- вибору обладнання;
- формулювання експлуатаційних вимог;
- оцінки застосування інформаційної системи;
- оцінку масштабованості інформаційної системи при зміні:
- обсягу інформаційної бази;
- кількості одночасно працюючих користувачів;
- навантаження на систему;
- оцінку зміни показників продуктивності системи при зміні:
- функціональність системи (доопрацювання системи або окремих алгоритмів);
- Зміни обладнання.
- виявлення проблем, що виникають тільки при розрахованій на багато користувачів роботі (конфлікти блокувань і т.п.).
Навантажувальний тест допомагає не лише оцінити ті чи інші характеристики. Але найголовніше дозволяє заздалегідь виявити вузькі місця системи та вирішити проблему найефективнішим шляхом.
Обов'язковою операцією за будь-якого впровадження чи зміні існуючої інформаційної системи є оцінка необхідної швидкодії системи та планування необхідних обчислювальних ресурсів її реалізації. В даний час не існує точного вирішення цього завдання загальному вигляді, і якщо, незважаючи на її складність та вартість, такий алгоритм буде запропонований будь-яким виробником, то навіть невеликі зміни в апаратній частині, версії програмного забезпечення, конфігурації системи або кількості або стандартній поведінці користувачів призведуть до появи значних помилок.
Тим не менш, існує достатня кількість способів оцінити необхідну для досягнення необхідної продуктивності конфігурацію програмного забезпечення апаратного забезпечення. Всі ці способи можуть застосовуватися в процесі вибору, але споживач повинен розуміти їх області застосування та обмеження.
Більшість існуючих методівоцінки продуктивності ґрунтується на тому чи іншому типі тестування.
Можна виділити два основних типи тестування: компонентне та інтегральне.
При компонентному тестуванні проводиться тестування окремих компонентів рішення, починаючи від продуктивності процесорів або підсистем зберігання інформації до тестування продуктивності сервера в цілому, але без корисного навантаження як того чи іншого бізнес-додатка.
Інтегральний підхід характеризується оцінкою продуктивності рішення загалом, як його програмної, і апаратної елементів. При цьому може використовуватися як бізнес-програма, яка буде використана в кінцевому рішенні, так і деякі модельні програми, що емулюють деякі стандартні бізнес-процеси та навантаження.
Зелений колір графіка разом з деякими умовно обраними за зразки показниками праворуч дозволяє зробити кросплатформенну узагальнену оцінку «непоганої» продуктивності.
Як радіти результатам тесту
Ви отримали як результат індекс продуктивності (швидкості). Не важливо, добрий чи поганий результат – це результат роботи ПЛАТФОРМИ на вашому «залізі». У разі клієнт - серверного варіантаце результат складного ланцюжка проходження запитів по різних ділянках. Ви отримуєте загальний фактичний результат, який визначається найвужчим місцем у системі. Вузьке місце є завжди.
Інакше кажучи, і налаштування СУБД, і налаштування ОС, і устаткування впливають загальний командний результат.
Який сервер краще
Даний тест, виконаний на конкретному сервері, дає результат із сукупності налаштувань hardware, операційної системи, субд і т.д. Проте високий результат на конкретному серверному обладнанні означає, що за дотримання нормальних умов такий самий результат буде на ідентичному серверному обладнанні. Цей тест є безкоштовною допомогою в можливості порівняти установку 1С:Підприємство під Windows та Linux, три різних СУБД, що підтримуються платформою 1С:Підприємство 8.
Безпека тесту
Тест є абсолютно безпечним. Він не призводить до падіння сервера (відсутня стрес-алгоритм) і не вимагає попередніх заходів навіть на бойовому сервері. Конфіденційні дані в результати тесту також не записуються. Збирається інформація про параметри CPU, RAM, HDD. Серійні номерипристроїв не збираються. У цьому можна легко переконатися - код тесту 100% відкритий. Жодного пересилання інформації без вашого відома неможливо.
Класифікація TPC-A-local Throughput / TPC-1C-GILV-A
Тест відноситься до розділу універсальних інтегральних кроссплатформенних тестів. Навіть більше, він застосовується для файлового та клієнт-серверного варіантів експлуатації 1С:Підприємство. Тест працює всім СУБД, підтримуваних 1С.
Універсальність дозволяє робити узагальнену оцінку продуктивності не прив'язуючись до конкретної типової конфігураціїплатформи.
З іншого боку це означає, що для точних розрахунків замовного проекту тест дозволяє зробити попередню оцінку перед спеціалізованим тестом навантаження .
Завантажити тест
Цей тест не є комерційним і його можна завантажити безкоштовно для 8.2 та безкоштовно для 8.3.
Технічні подробиці
Що відбувається у тесті у рамках «одного» такту операції?
Особливості використання тесту на субд PostgreSQL
Встановіть значення параметра standard_conforming_strings у конфігураційному файлі postgresql.conf на значення ‘off’
Як виміряти завантаженість заліза
Слід зазначити, що сам собою тест вже частково виконує замір. Для більш детальної картини рекомендую скористатися утилітою Марка Русиновича Process Explorer.
На малюнку показано приклад виміру для файлового варіанта.
Кожен спеціаліст підтримки має досвід отримання абстрактних скарг із боку користувачів. Всім знайомі формулювання: "вона дуже довго думає", "у мене червоне вікно", "система працює якось не так", а також "цього давно не було, і ось знову".
У такій ситуації відразу розібратися, де криється помилка, і що в першу чергу, дуже складно. У статті розглянемо чого залежить продуктивність 1С, тобто. високонавантажених систем, створених на базі «1С:Підприємство», у ситуаціях, коли симптоматика не до кінця зрозуміла та конкретний діагноз поставити неможливо.
Основні причини, що впливають на продуктивність 1С
Більш ніж у 60% випадків причинами низької продуктивності виявляються:
- Неоптимальні запити та програмний кодзміни (26% випадків);
- Неоптимальна індексація таблиць об'єктів (19% випадків);
- Неоптимальне навантаження на дискову підсистему (16% випадків).
З цим солідарні провідні розробники Microsoft
Таким чином, отримати значне покращення продуктивності програми бази даних, можна оптимізувати область доступу до даних, включаючи логічне та фізичне проектування баз (наскільки це можливо в 1С), а також за допомогою створення правильних запитів та використання оптимальної індексації. Частина проблем із продуктивністю баз даних може бути вирішена за допомогою нарощування апаратних потужностей, але не завжди: неправильне проектування прикладного рішення не може бути компенсовано потужнішим сервером. Нерідкі випадки, коли, не розібравшись із причинами проблеми продуктивності, компанії-користувачі йдуть на серйозні витрати, купуючи нове обладнання, а проблема так і залишається невирішеною.
Якісна діагностика продуктивності 1С із застосуванням всього спектра існуючих інструментів – запорука успішного вирішення проблем та оптимізації витрат
Першим кроком до виявлення та усунення проблем низької продуктивності має стати складання повного перелікуключових проблемних операцій, із зазначенням точної швидкості їх виконання на поточний момент та очікуваної швидкості їх виконання у майбутньому.
Приклад:
Неправильно: Під час формування звіту програма «зависає». Хочу, щоби формувала швидше.
Правильно: Формування звіту «Відомість із заборгованості» здійснюється 5 хвилин 10 секунд. Очікувана швидкість формування цього звіту – не більше 20 секунд.
Після того як перелік проблем складено та оцифровано, необхідно провести аналіз причин, розпочавши з пошуків проблемного коду, якщо такий є (наприклад, «важкі» запити, тривалі очікування на блокуваннях, deadlock' та ін.).
Інструменти для ідентифікації проблемного коду
- «1С:Центр управління продуктивністю» (модуль, що входить до інструментального пакету «1С:Корпоративний», виробником якого є фірма 1С);
- Хмарні послугиГільова;
- Штатні інструменти, вбудовані в СУБД провідних вендорів
Ефективність використання даних інструментів гарантує кваліфікація розробника «1С:Експерт з технологічних питань», що передбачає його участь у масштабних запровадженнях 1С. При цьому різні експерти, виходячи зі свого індивідуального досвіду, можуть надавати перевагу тому чи іншому інструменту/методу.
Паралельно з використанням одного з представлених інструментів застосовуються і штатні засоби моніторингу завантаження обладнання (лічильники «Performance monitors»).
З отриманих вимірів виявляється клас причини:
- Проблема у коді;
- та/або проблема в апаратній частині;
- Проблема в інших ресурсомістких програмах, що використовуються на робочих серверах.
Навантажувальне тестування 1С - методика оцінки серверного обладнання
Як уже згадувалося, серед факторів, здатних вплинути на швидкодію 1С, як у позитивну, так і негативну сторону, важливе місце займає серверне обладнання та його налаштування. Розглянемо варіанти вимірів, оцінки навантаження та тестування працездатності системи в наступних умовах:
- Сервер 1С є в наявності та розташовується:
- Спільно із СУБД;
- На окремому сервері.
Для оцінки відповідності параметрів наявного серверного обладнання вимогам системи необхідно зробити збір даних із навантаження на апаратну частину, зокрема і процесор, тобто. навантажувальне тестування 1С. Для цього застосовується «Performance Monitor» – інструмент, що дозволяє зробити замір обладнання на робочому контурі та зняти лічильники продуктивності.
Нижче наведено базовий набір лічильників, які необхідно налаштувати для моніторингу продуктивності обладнання Windows. Збір провадиться з усіх серверів, де встановлені сервери 1С.
Якщо показник лічильника відсотка завантаженості процесора для виду «Processor» має високе значення, слід виявити процеси, які можна зупинити без шкоди для роботи сервера, а також перенести інші сервера.
Вигляд «Process» дозволить налаштувати моніторинг для кожного окремого процесу, а також визначити, які процеси займають найбільше процесорного часу. Якщо на сервері встановлено лише сервер 1С, то щоб зрозуміти, яке навантаження він дає на залізо, необхідно налаштувати збір наступних лічильників:
| \Process("1cv8*")\% Processor Time |
| \Process("ragent*")\% Processor Time |
| \Process("ragent*")\Private Bytes |
| \Process("ragent*")\Virtual Bytes |
| \Process("rmngr*")\% Processor Time |
| \Process("rmngr*")\Private Bytes |
| \Process("rmngr*")\Virtual Bytes |
| \Process("rphost*")\% Processor Time |
| \Process("rphost*")\Private Bytes |
| \Process("rphost*")\Virtual Bytes |
| \Process("1cv8*")\Private Bytes |
| \Process("1cv8*")\Virtual Bytes |
Якщо поточна система знаходиться у незадовільному стані, то на підставі зібраних вимірів, застосовуючи лінійну залежність, слід провести розрахунок параметрів устаткування установки цільової системи.
Якщо придбання серверного обладнання лише планується, розрахувати його параметри можна проеммулировав роботу планованої системи, але у меншому масштабі, у наявному оборудовании. Для цього використовується «1С:Тест-цент», що входить до Корпоративного інструментального пакету 1С. На підставі отриманих вимірів, за допомогою методик розрахунку визначаються параметри планованої системи та, відповідно, вимоги до обладнання. Цей тест можна використовувати багаторазово під різні виміри, попередньо доповнивши та розширивши функціонал. Ця методика має високу точність та простоту розрахунку.
Продукти з бухгалтерського та управлінського облікуКомпанії 1С найбільш поширені біля РФ. Тисячі компаній ведуть свій бізнес, спираючись на типові та спеціалізовані конфігурації 1С. При такому масовому використанні регулярно виникає низка питань щодо оптимізації бюджету на ПЗ та розумного використання ресурсів. Не вщухають суперечки навколо серверних елементів даного комплексу, зокрема – на якій операційній системі базувати сервер 1С та який СУБД довірити обробку баз 1С. У ході наших тестів ми намагатимемося відповісти на ці запитання.
Учасники тестування
Операційна система MS Server та СУБД MS SQL
- Фірма 1С відкрито позиціонує цю зв'язку як основну робочу модель, відповідно продукти 1С створюються насамперед для неї
- Наявність протоколу прямого швидкісного обміну інформацією SharedMemory
- Є офіційна технічна підтримката сервісні контракти
- Є база знань та тонни інформації щодо інсталяції та тонкому настроюванню 1C+MS SQL
Операційна система Unix та СУБД PostgreSQL
- Система повністю безкоштовна (крім ліцензії на сервер 1С:Підприємство)
- Є можливість гнучкої установки безлічі параметрів, що покращують працездатність СУБД
- Заявлено підтримку СУБД PostgreSQL продуктами 1С
- Є можливість реплікації баз
Звичайно ж, вартість проекту, стійкість до відмов та технічна підтримка є важливими критеріями при виборі інформаційної системи для 1С. Однак, є фактор, який у більшості випадків кардинально впливає на прийняття рішення – це швидкодія.
Оскільки технічної літератури за цими двома системами на просторах Інтернету просто безліч, можна було б довго сперечатися про довгі порівняльні таблиці, які, залежно від цілей, підкреслюють вигоди того чи іншого продукту. Дискутувати можна про той чи інший параметр серед сотень інших таких самих - наскільки він унікальний у своєму роді і як він впливає на досягнення результату. Але теорія без практики мертва - пропонуємо в цій статті опустити теорію і перейти безпосередньо до фактів, щоб саме на практиці перевірити швидкодію обох інформаційних систем з певним рівнем рекомендованих налаштувань різних варіантахсерверної архітектури (див. таблицю 2).
Методи тестування
У наших випробуваннях ми спиратимемося на два методи синтетичної генерації навантаження та імітації роботи користувачів у 1С. Це тест Гільова (TPC-1C) та спеціальний тест 1С «Тест центр» з інструментарію 1С:КІП зі спеціальними сценаріями роботи користувачів.
Тест Гільова (TPC-1C)
Тест Гільованалежить до розділу універсальних кросплатформних навантажувальних тестів. Він може використовуватися як для файлової, так і для клієнт-серверної архітектури 1С:Підприємство. Тест вимірює кількість роботи в одиницю часу в одному потоці і підходить для оцінки швидкості однопоточних навантажень, включаючи швидкість промальовування інтерфейсу, впливу ресурсних витрат, перепроведення документів, процедур закриття місяця, розрахунку зарплати і т.п. Універсальність дозволяє виконувати сумарну оцінку продуктивності, не прив'язуючись до однієї конфігурації платформи. Результатом тесту є тотальна оцінка вимірюваної системи 1С, яка виражена в умовних одиницях.
Спеціалізований тест із інструментарію «Тест центр» 1С: КВП
Тест-центр– інструмент проведення розрахованих на багато користувачів навантажувальних випробувань систем на базі 1С:Підприємство 8 (див. малюнок 1). З його допомогою можна моделювати роботу компанії без участі реальних користувачів, що дозволяє оцінювати застосовність, продуктивність та масштабованість інформаційної системи в реальних умовах. Система є конфігурацією, що надає механізм управління процесом тестування. Для тестування інформаційної бази необхідно інтегрувати конфігурацію Тест-центру в конфігурацію бази, що тестується за допомогою порівняння та об'єднання конфігурацій. В результаті об'єднання, до метаданих бази, що тестується, будуть додані об'єкти та загальні модулі, необхідні для роботи Тест-центру.
Рисунок 1 – Схема роботи «Тест центр» 1С: КВП
Таким чином, використовуючи інструментарій 1С: КВП, на підставі наявних даних у реальних виробничих базах 1С - програміст формує повноцінний автоматичний сценарій тестування, заснований на переліку документів та довідників, ключових для даного типуконфігурації (заявка на витрачання коштів, замовлення постачальнику, реалізація товарів та послуг тощо). При запуску сценарію Тест-центр автоматично відтворюватиме багатокористувацьку діяльність, описану в сценарії. Для цього Тест-центр створить необхідну кількість віртуальних користувачів (відповідно до списку ролей) і запустить виконання дій.
Параметри тестування
При налаштуванні сценаріїв тестування для достовірної імітації одночасної роботи великої кількості користувачів задаються певні параметри тестування кожного типу документа (див. таблицю 1):
- Документ – вказує конкретний документ у робочій базі, на основі якого проводитиметься навантажувальне тестування
- Пріоритет запуску – формує порядок запуску тестів для кожного типу документів
- Кількість документів – визначає обсяг формованих тестових документів
- Пауза, секунд – затримка під час запуску серії тестів, в рамках одного типу документів
- Кількість рядків у документі – інформаційний покажчик, що повідомляє про «масивність» тестового документа, що впливає на час обробки та навантаження на ресурси
Тести виконуються у 3 ітераціях, результати записуються до таблиці. Таким чином, отримані результати тестування, що вимірюються в секундах, найбільш реалістично та об'єктивно відображають рівень продуктивності баз 1С в умовах, максимально наближених до реальних (див. таблицю 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. Технічні характеристики тестового стенду
| №п\п | Роль системи | CPU\vCPU | RAM, Гб | Дискова система введення/виводу |
| 1 | Сервер терміналів – віртуальна машинадля керування тестами | 4 ядра 2.9 GHz |
16 Гб | Intel Sata SSD Raid1 |
| 2 | Сценарії 1.Сервер 1С + СУБД апаратний | Intel Xeon E5-2690 16 ядер |
96 Гб | Intel Sata SSD Raid1 |
| 3 | Сценарій 2Сервер 1С + СУБД віртуальні | 16 ядер 2.9 GHz |
64 Гб | Intel Sata SSD Raid1 |
| 4 | Сценарій 3.Сервер 1С віртуальний | 16 ядер 2.9 GHz |
32 Гб | Intel Sata SSD Raid1 |
| 5 | Сценарій 4.Сервер СУБД віртуальний | 16 ядер 2.9 GHz |
32 Гб | Intel Sata SSD Raid1 |
| 6 | Програмне забезпечення |
|
||
| 7 | Конфігурації 1С |
|
||
Таблиця 3.1. Результати тестування за допомогою тесту Гілева (TPC-1C). Оптимальним вважається найбільше значення
Таблиця 3.2 Результати тестування за допомогою спеціального тесту 1С:КІП. Оптимальним вважається найменше значення
| Операційна система Microsoft Server | Операційна система класу Unix | |||||
| Перелік тестів (середнє значення за підсумками серії із 3 тестів) | Апаратний сервер 1С+СУБД, протокол SharedMemory | Віртуальний сервер 1С+СУБД, протокол SharedMemory | Апаратний сервер 1С та апаратний сервер СУБД, протокол TCP-IP | Віртуальний сервер 1С та віртуальний серверСУБД, протокол TCP-IP | ||
| Проведення тестів 1С:КІП на існуючій базі, конфігурація Бухгалтерія Підприємства | ||||||
| Оборотно-сальдова відомість | 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 сек |
| Проведення ПТІУ | 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 сек |
| Проведення тестів 1С:КІП на існуючій базі, конфігурація Управління Торгівлею | ||||||
| Проведення та повернення від клієнта | 2,192 сек | 2,113 сек | 2,070 сек | 2,418 сек | 1,417 сек | 1,494 сек |
| Проведення та повернення товарів постачальнику | 1,446 сек | 1,410 сек | 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 сек |
| Проведення надходження ТУ | 1,499 сек | 1,438 сек | 1,412 сек | 1,524 сек | 1,097 сек | 1,189 сек |
| Проведення реалізації ТУ | 1,390 сек | 1,355 сек | 1,308 сек | 1,426 сек | 1,093 сек | 1,114 сек |
| Проведення РКО | 0,759 сек | 0,729 сек | 0,713 сек | 0,759 сек | 0,748 сек | 0,735 сек |
- У спеціальному тесті 1С операції «читання даних та складних обчислень», такі як «Оборотно-сальдова відомість» та «Розрахунок калькуляцій собівартості» у кілька разів швидше виконуються на СУБД MS SQL від Microsoft.
- При операціях «запису даних та проведення документів» у більшості тестів найкращий результат показує СУБД PostgreSQL, оптимізований для 1С.
- Синтетичний тест Гільова також показує перевагу PostgreSQL. Пов'язаний цей факт про те, що синтетичний тест заснований на вимірі швидкості створення та проведення певних типів документів, що вважається також операціями «запису даних та проведення документів».
Закінчимо з кросплатформним порівнянням, перейдемо до порівнянь усередині кожної системи:
- Очікується, що тести 1С на апаратній платформі показують результати краще, ніж на віртуальній. Різниця в результатах спеціального тесту 1С в обох випадках невелика, що свідчить про поступову оптимізацію виробниками віртуальних гіпервізорів.
- Також очікується, що використання технології пам'яті (SharedMemory) прискорює процес обміну даними між сервером 1С і СУБД. Відповідно, показання тестів трохи краще, ніж у схеми з мережевою взаємодією цих двох сервісів за допомогою протоколу TCP-IP.
Можна зробити висновок, що при правильному налаштуванні 1С і СУБД, можна досягти значних результатів навіть на безкоштовному програмне забезпечення. Тому при проектуванні нової ІТ-структури для 1С потрібно враховувати рівень навантаження на систему, тип превалюючих операцій у базі, наявний бюджет, наявність спеціаліста з нестандартних СУБД, необхідність інтеграції із зовнішніми сервісами тощо. Виходячи з цих даних, вже можна підбирати потрібне рішення.
Читайте продовження тестування.
Доброї доби, шановні.
Ця нотатка є підказкою мені, та іншим.
Ця інформація стане в нагоді новачкам для створення та оптимізації бази 1С на сервері SQL
Коли у тебе немає досвіду роботи з серверною частиною 1С, то при появі такого бажання та/або необхідності з'являється чимало нюансів та не очевидностей.
Сумно, що навіть такий простий квест як вибір сервера під 1С не гарантує успіху, і ви можете зіткнутися з його вкрай повільною продуктивністю.
Ось на етапі з'ясування, що не так, і може знадобитися розуміння того, в якій послідовності і що робити.
Починаємо. Не забудьте зробити бекап даних.
Мій сервер базується на Windows Server 2012 R2 standart і SQL 2012.
У вас можуть бути інші, що входять, це не важливо (зараз).
Ми взяли Комплексне постачання УТП (до неї входить 10 клієнтських ліцензій, сервер (тільки 32 біт), і конфігурації ЗУП, УТ, Бухгалтерії, і сама УТП. Примітно що франзайзі на всю хотіли включити окремі поставки, і краще відразу КОРП. Аналіз показав що це зайве, і дешевше купувати комплексну конфігурацію.
При підборі заліза вам важливо пам'ятати, що в клієнт-серверному варіанті роботи 1С потрібно, щоб частота роботи процесора була максимальною, як і частота роботи пам'яті (пам'ятайте про це, вибираючи залізо). (тобто Hyper трейдинг та всякі С1-2-3 state краще відключити в BIOS).
Також треба «фізично» розносити файл бази (MDF) та лога (LDF) на окремі жорсткі, а не логічні диски.
І якщо для файлової версії оптимально буде рекомендувати SSD, то тут не все так очевидно.
Зайдіть на форум Гільова, щоб ознайомитися із «загадками», що виникають у спробі покращити продуктивність 1С. Багато цікавого.
У моєму випадку колеги адміни виділили мені лезо на блейд сервері, з двома фіз.процесорами AMD Quad-Core Opteron (tm) Processor 2354, з 16 Гб (667 МГц). Система на 2 дисках у дзеркалі. Диски під базу виділялися на Fiber chanel, на HP EVA.
Зараз шукаю іншу конфігурацію, але поки що треба і на цьому пожити.
І ось на етапі впровадження, поки ведеться аналіз, як переносити дані з іншої ERP системи, 1С програміст звернув мою увагу на повільну роботу, і тривале проведення документів. Тобто систему ще не експлуатують, а вона вже гальмує і помирає, а переведення разу в 3 повільніше, ніж у людини на ноутбуці, а з цим ще й люди працювати повинні (3-4 основних, і 25-40 табельників).
Чи не порядок.
Він порекомендував використовувати тест Гільова (легко гуглиться його сайт), у якого повного сервісів підтримки, та інформації. Чим і користувався.
Тест показав, що все погано, і рекомендована кількість користувачів відсутня.
Подивившись уважніше я зрозумів, що база і лог хоч на різних дисках - але логічних.
І ось для виправлення цього і зробив скріншоти та цю пам'ятку на майбутнє собі та іншим:
Створення бази даних у SQL Server Management Studio. Базу та лог розносимо на різні фізичні диски.
Методі відновлення вибираємо Simple
Створюємо нову базучерез клієнта 1С на комп'ютері
Вибираємо додавання інформаційної бази. У разі без зміни.
Задаємо назву. Тут будь-яке. Найкраще як на сервері.
Заповнюємо дані. Коли вказував на сервер, ім'я сервера вказував 127.0.0.1 - інше не працювало.
тут нічого не міняємо
Робимо завантаження нашої інформаційної бази (попередньо наявної або нової, наприклад, тесту)
Власне, вибір бази. Я завантажую тест Гільова для платформи 8.3
Підтверджуємо
Підтверджуємо
Підсумок тесту. Ще все погано, але рекомендована кількість користувачів більша за потрібне, що добре.
P.S. Не забувайте робити бекап.
P.P.S запускаючи тест Гільова в тестовій базі, яка розташована в тих же місцях зберігання що і будь-яка бойова - майте на увазі, що як мінімум Лог файл прагнути зайняти все вільне місце, Що чревато зупинкою бойової бази і не проходженням тесту!
P.P.P.S також пам'ятайте, що SQL при роботі використовує TEMP базу, що знаходиться там, де встановлено SQL (за замовчуванням на C).
Тому доступ до цієї бази бажано також покращити.
Також інформація на допомогу - Effector Saver дозволяє зберігати 1с бази
Бекапит все інше значення мало, тому що в моєму випадку ліцензії програмні і при переносі на інше залізо ліцензії злітають.
Із додаткового.
Якщо Вам захочеться дати користувачам домену безкарно створювати будь-які БД засобами 1С, то облікового записуслужби сервера 1С зробити доменну облік, що має право створювати бази без будь-яких сисадмінів цілком достатньо,
при цьому логін та пароль у властивостях інформаційної бази писати не треба…
Завантаження...