Тест гільова 8.3 результати. Стандартний тест навантаження. Як опублікувати результати тесту

Передісторія

Обов'язковою операцією за будь-якого впровадження чи зміні існуючої інформаційної системи є оцінка необхідної швидкодії системи та планування необхідних обчислювальних ресурсів її реалізації. В даний час не існує точного вирішення цього завдання в загальному вигляді, і якщо, незважаючи на
її складність і вартість, такий алгоритм буде запропонований будь-яким виробником, навіть невеликі зміни в апаратній частині, версії програмного забезпечення, конфігурації системи або кількості або стандартній поведінці користувачів призведуть до появи значних помилок.
Проте існує достатня кількість способів. Всі ці способи можуть застосовуватися в процесі вибору, але споживач повинен розуміти їх області застосування та обмеження.

Більшість існуючих методів оцінки продуктивності ґрунтуються на тому
або іншому типі тестування.

Можна виділити два основні типи тестування:
компонентне та інтегральне.

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

Інтегральний підхід характеризується оцінкою
продуктивності рішення загалом, як його програмної, і апаратної елементів.
При цьому може використовуватися як бізнес-додаток, який буде використаний
в кінцевому рішенні, так і деякі модельні програми, що емулюють
деякі стандартні бізнес-процеси та навантаження.

Тести TPCта інші універсальні тести дозволяють вибрати найбільш перспективні платформи та порівнювати між собою пропозиції різних виробників, але є лише довідковою інформацією, яка не враховує специфіки бізнесу. Спеціалізовані тести дозволяють точніше вибрати конкретну модель сервера та його конфігурацію. Однак найбільш обґрунтовані рішення приймаються лише на основі результатів проведення навантажувальних тестів. Тільки вони дозволяють оптимально налаштувати вибрану
серверну платформу та провести її налаштування на максимальну продуктивність.

Що таке TPC-1C-GILV

Це серія незалежних тестів, призначених для оцінки швидкодії платформи 1С:Підприємство 8.1 на вашому комп'ютері.

Зрозуміло, " незалежний " тест означає, що не спонсорується фірмою 1С.

В даний час доступний тест TPC-A-local Throughput / TPC-1C-GILV-A" (останнє оновлення - серпень 2008р. версія 1.0.3)

Ідея тесту TPC-A-local Throughput / TPC-1C-GILV-A

Ви завантажуєте з цього сайту файл вивантаження конфігурації (~400 Кб) та завантажуєте у себе. Якщо розгорнете конфігурацію у файлових варіантах, то значною мірою тест буде тестувати зв'язку "CPU вашого комп'ютера - HDD де лежить база".

Якщо розгорнете конфігурацію в клієнт-серверний варіант, то переважно навантаження піддається CPU сервера додатків - CPU сервера субд - - сервера субд.

У тесті виконується інтенсивний запис 5000 документів. Глибокого сенсу в бізнес-логіці коду немає, оцінюватися просто умовно обрана за стандарт продуктивність документа Х.

Головна принада тесту в тому, що Вам не треба знати технічних подробиць. Тест виконується сам і сам видає оцінку. До того ж результат комусь повідомляти Вам теж не обов'язково:)

Ви можете порівняти продуктивність декількох серверів або одного сервера з різними характеристиками дискової підсистеми.

Виконуючи тест із сервера додатків та з клієнта по мережі, можна зрозуміти вплив мережі на ділянці від клієнта до сервера.

Як запустити тест

Запустити тест дуже просто. Потрібно натиснути кнопку

і дочекатися, поки індикатор тесту (праворуч від кнопки) досягне 100%.

Зазвичай тест триває близько 8 хвилин.

Що означають результати тесту

Результат тесту представляється як "швидкість запису" даних тесту. Похибка тесту становить 2 одиниці. Для точної оцінки можна повторити тест тричі.

Після того, як індикатор тесту досягне 100%, ви побачите приблизно такі графіки:

Нижче за графіками розташовані деякі раніше проведені аналогічні тести.

Колір графіка підказує про поточну якість "загальної" продуктивності для роботи без урахування блокувань.

Зелений колір графіка в сукупності з деякими умовно обраними за зразки показниками праворуч дозволяє зробити кросплатформенну узагальнену оцінку "непоганої" продуктивності:)

Як радіти результатам тесту

Ви отримали як результат якийсь індекс продуктивності (вважай швидкості). Не важливо, добрий чи поганий результат – це результат роботи ПЛАТФОРМИ на вашому "залізі". У випадку клієнт-серверного варіанта це результат. Ви отримуєте загальний фактичний результат, який визначається НАЙВУЖЧИМ МІСЦЕМ в системі. ВУЗЕ МІСЦЕ Є ЗАВЖДИ!

Іншими словами, і налаштування СУБД, і налаштування ОС, та обладнання впливають на загальний командний результат:)

Який сервер краще

Даний тест, виконаний на конкретному сервері, дає результат із сукупності налаштувань hardware, операційної системи, субд і т.д. Проте високий результат на конкретному серверному обладнанні означає, що за дотримання нормальних умов такий самий результат буде на ідентичному серверному обладнанні. Даний тест є безкоштовною допомогою в можливості порівняти установку 1С:Підприємство під Windows і Linux, три різних СУБД, що підтримуються платформою 1С:Підприємство 8.1.

Безпека тесту

Тест є абсолютно безпечним. Він не призводить до падіння сервера (відсутня стрес-алгоритм) і не вимагає попередніх заходів навіть на бойовому сервері. Конфіденційні дані в результати тесту також не записуються. Збирається інформація про параметри CPU, RAM, HDD. Серійні номери не збираються. У цьому можна легко переконатися - код тесту 100% відкритий. Жодного пересилання інформації без вашого відома неможливо.

Як опублікувати результати тесту

Якщо ви бажаєте допомогти розвивати тест, ви можете виконати ряд тестів на своїх серверах. Потім загального переліку зроблених тестів залиште тільки ті, що хочете опублікувати та надішліть dt-вивантаження з результатами.

Дані будуть вручну перевірені (що вони не є помилковими), в колонку "автор" тестів додається адресат тестів і додаються у розвантаження, доступне для скачування всім.

Класифікація TPC-A-local Throughput / TPC-1C-GILV-A

Тест відноситься до розділу універсальних інтегральних кроссплатформенних тестів. Навіть більше, він застосовується для файлового та клієнт-серверного варіантів експлуатації 1С:Підприємство. Тест працює для всіх СУБД, що підтримуються 1С.

Універсальність дозволяє робити узагальнену оцінку продуктивності, не прив'язуючись до конкретної типової конфігурації платформи.

З іншого боку це означає, що для точних розрахунків замовного проекту тест дозволяє зробити попередню оцінку перед спеціалізованим тестом навантаження (наприклад за допомогою 1С:Тестцентр).

Примітка. Модифікація тесту A" означає "автоматичне управління блокуваннями" . Після виходу офіційних версій типових рішень від 1С, планується модифікувати тест для роботи в режимі "керованих блокувань" і позначити буквою " M".

Завантажити тест

Цей тест не є комерційним та .

Результати тестування

Топ - 3 найкращих клієнт-серверних інсталяцій 1С на MS SQL Server. Ви також можете потрапити до цієї таблиці. Докладніше можна переглянути результати, завантаживши тест.

Технічні подробиці

Що відбувається у тесті в рамках "одного" такту операції?

Як виміряти завантаженість заліза

Слід зазначити, що сам собою тест вже частково виконує замір. Для більш детальної картини рекомендую скористатися утилітою Марка Русиновича.

На малюнку показано приклад виміру для файлового варіанта.

Контакти для TPC-1C-GILV

http://сайт/1c/ tpc

результати тестів, пропозиції щодо розвитку

Результати тесту навантаження TPC-1 продуктивності 1С по Гільову для конфігурації з файловою базою даних:

Продуктивність сервера оцінюється не завантаженістю та чергами до CPU, а здатністю виконати певну кількість операцій за одиницю часу.
Конкурування за такі ресурси, як процесор, знижує швидкість виконання операцій, коли час відгуку визначається:

• часом операції
• часом очікування обладнання
• часом логічних очікувань на кшталт блокувань

У цьому ключовою характеристикою є швидкість операції.

Примітка. Для процесора найбільш значущою характеристикою є частота процесора, а не завантаженість. Нижче скріншот результатів проведеного тестування (Щоб збільшити картинку – натисніть на неї).

Швидкодія системи та планування необхідних обчислювальних ресурсів для її реалізації є обов'язковою операцією за будь-якого впровадження або зміни існуючої ІТ системи.

Більшість існуючих методів оцінки продуктивності ґрунтуються на тому чи іншому типі тестування.

Можна виділити два основних типи тестування: компонентне та інтегральне.

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

Інтегральний підхід характеризується оцінкою продуктивності рішення загалом, як його програмної, і апаратної елементів. При цьому може використовуватися як бізнес-додаток, який буде використаний у кінцевому рішенні, так і деякі модельні програми, що емулюють деякі стандартні бізнес-процеси та навантаження.

У нашому тесті якраз і використовується такий підхід.

Ми отримали як результат якийсь індекс продуктивності (швидкості). Це результат роботи платформи загалом на нашому залізі. У разі клієнт-серверного варіанту це результат складного ланцюжка проходження запитів по різних ділянках. Ви отримуєте загальний фактичний результат, який визначається найвужчим місцем у системі. Налаштування СУБД, і налаштування ОС, та обладнання впливають на загальний результат продуктивності системи.

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

Доброї доби, шановні.
Ця нотатка є підказкою мені, та іншим.
Ця інформація стане в нагоді новачкам для створення та оптимізації бази 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С зробити доменний облік, що має право створювати бази без будь-яких сісадмінів цілком достатньо,
при цьому логін та пароль у властивостях інформаційної бази писати не треба…

Продукти з бухгалтерського та управлінського обліку компанії 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. Параметри тестових сценаріїв

Таблиця 2. Технічні характеристики тестового стенду

Таблиця 3.1. Результати тестування за допомогою тесту Гілева (TPC-1C). Оптимальним вважається найбільше значення

Таблиця 3.2 Результати тестування за допомогою спеціального тесту 1С:КІП. Оптимальним вважається найменше значення

1. У спеціальному тесті 1С операції «читання даних та складних обчислень», такі як «Оборотно-сальдова відомість» та «Розрахунок калькуляцій собівартості» у кілька разів швидше виконуються на СУБД MS SQL від Microsoft.
2. При операціях «запису даних та проведення документів» у більшості тестів найкращий результат показує СУБД PostgreSQL, оптимізований для 1С.
3. Синтетичний тест Гільова також показує перевагу PostgreSQL. Пов'язаний цей факт про те, що синтетичний тест заснований на вимірі швидкості створення та проведення певних типів документів, що вважається також операціями «запису даних та проведення документів».

Закінчимо з кросплатформним порівнянням, перейдемо до порівнянь усередині кожної системи:

1. Очікується, що тести 1С на апаратній платформі показують результати краще, ніж на віртуальній. Різниця в результатах спеціального тесту 1С в обох випадках невелика, що свідчить про поступову оптимізацію виробниками віртуальних гіпервізорів.
2. Також очікується, що використання технології пам'яті (SharedMemory) прискорює процес обміну даними між сервером 1С і СУБД. Відповідно, показання тестів трохи краще, ніж у схеми з мережевою взаємодією цих двох сервісів за допомогою протоколу TCP-IP.

Можна зробити висновок, що при правильному налаштуванні 1С і СУБД, можна досягти значних результатів навіть на безкоштовному програмному забезпеченні. Тому при проектуванні нової ІТ-структури для 1С потрібно враховувати рівень навантаження на систему, тип превалюючих операцій у базі, наявний бюджет, наявність спеціаліста з нестандартних СУБД, необхідність інтеграції із зовнішніми сервісами тощо. Виходячи з цих даних, вже можна підбирати потрібне рішення.

Читайте продовження тестування.

Основна мета написання статті – щоб не повторювати очевидні нюанси тим адміністраторам (і програмістам), які ще не набрали досвіду з 1С.

Вторинна мета, якщо маю якісь недоліки, — на Інфостарті мені це вкажуть найшвидше.

Якимсь стандартом "де факто" вже став тест В. Гільова. Автор на своєму сайті дав цілком зрозумілі рекомендації, я ж наведу деякі результати, і прокоментую найбільш ймовірні помилки. Природно, що результати тестування на Вашому устаткуванні можуть відрізнятися, це просто для орієнтиру, що має бути і чого можна прагнути. Відразу хочу зазначити, що зміни треба робити крок за кроком, і після кожного кроку перевіряти, який результат це дало.

На Інфостарті подібні статті є, у відповідних розділах ставитиму на них посилання (якщо пропущу щось - прохання підказати в коментарях, додам). Отже, припустимо у вас гальмує 1С. Як діагностувати проблему, і як зрозуміти, хто винен, адміністратор чи програміст?

Вихідні дані:

Комп'ютер, що тестується, основний піддослідний кролик: HP DL180G6, в комплектації 2*Xeon 5650, 32 Gb, Intel 362i, Win 2008 r2. Для порівняння, порівнянні результати в однопоточному тесті показує Core i3-2100. Обладнання спеціально взяв не найновіше, на сучасному обладнанні результати помітно кращі.

Для тестування рознесених серверів 1С і SQL, SQL: IBM System 3650 x4, 2*Xeon E5-2630, 32 Gb, Intel 350, Win 2008 r2.

Для перевірки 10 Gbit мережі використовувалися Intel 520-DA2 адаптери.

Файлова версія. (База лежить на сервері в розшарованій папці, клієнти підключаються по мережі, протокол CIFS/SMB). Алгоритм за кроками:

0. Додаємо на файловий сервер тестову базу Гільова в ту саму папку, що й основні бази. З клієнтського комп'ютера підключаємось, запускаємо тест. Запам'ятовуємо результат.

Передбачається, що навіть для старих комп'ютерів 10-річної давності (Pentium на 775 socket ) час від натискання на ярлик 1С: Підприємство до появи вікна бази має пройти менше хвилини. ( Celeron = Повільна робота).

Якщо у Вас комп'ютер гірший, ніж Пентіум на 775 socket з 1 гб оперативної пам'яті, то я Вам співчуваю, і комфортної роботи на 1С 8.2 у файловій версії Вам буде важко. Подумайте або про апгрейд (давно пора), або про перехід на термінальний (або web, у разі тонких клієнтів та керованих форм) сервер.

Якщо комп'ютер не гірший, можна штовхати адміністратора. Як мінімум – перевірити роботу мережі, антивірусу та драйвера захисту HASP.

Якщо тест Гільова на цьому етапі показав 30 "папуг" і вище, але робоча база 1С все одно працює повільно – питання вже до програміста.

1. Для орієнтира, скільки ж може "вичавити" клієнтський комп'ютер, перевіряємо роботу тільки цього комп'ютера без мережі. Тестову базу ставимо на локальний комп'ютер (на швидкий диск). Якщо клієнтському комп'ютері немає нормального ССД, то створюється рамдиск. Поки що, найпростіше і безкоштовне - Ramdisk enterprise.

Для тестування версії 8.2 цілком достатньо 256 мегабайт рамдиска, і! Найголовніше. Після перезавантаження комп'ютера, з працюючим рамдиском, на ньому має бути вільно 100-200 мегабайт. Відповідно, без рамдиска, для нормальної роботи вільної пам'яті має бути 300-400 мегабайт.

Для тестування версії 8.3 рамдиска 256 мегабайт вистачить, але вільної оперативної пам'яті треба більше.

Під час тестування слід дивитися на завантаження процесора. У випадку, близькому до ідеального (рамдиск), локальна файлова 1с при роботі завантажує 1 ядро ​​процесора. Відповідно, якщо при тестуванні у вас ядро ​​процесора завантажено не повністю, шукайте слабкі місця. Трохи емоційно, але загалом коректно, вплив процесора працювати 1С описано . Просто для орієнтиру, навіть на сучасних Core i3 з високою частотою, цілком реальні цифри 70-80.

Найпоширеніші помилки цьому етапі.

а) Неправильно налаштований антивірус. Антивірусів багато, налаштування для кожного свої, скажу лише те, що при грамотному налаштуванні ні веб, ні касперський 1С не заважають. При налаштуваннях "за замовчуванням" - може забиратися приблизно 3-5 папуг (10-15%).

б) режим продуктивності. Чомусь на це мало хто звертає уваги, а ефект – найвагоміший. Якщо потрібна швидкість - робити це обов'язково, і на клієнтських і на серверних комп'ютерах. (Гарний опис у Гілева. Єдиний нюанс, на деяких материнських платах якщо вимкнути Intel SpeedStep то не можна включати TurboBoost).

Якщо коротко - під час роботи 1С відбувається дуже багато очікувань відповіді з інших пристроїв (диск, мережа тощо). Під час очікування відповіді, якщо режим продуктивності включений збалансований, процесор знижує свою частоту. Приходить відповідь від пристрою, треба працювати 1С (процесору), але перші такти йдуть зі зниженою частотою, потім частота підвищується - а 1С знову чекає відповіді від пристрою. І так - багато сотень разів на секунду.

Включати режим продуктивності можна (і бажано) у двох місцях:

Через BIOS. Вимкнути режими C1, C1E, Intel С-state (C2, C3, C4). У різних біосах вони називаються по-різному, але сенс один. Шукати довго, потрібно перезавантаження, але якщо зробив один раз – потім можна забути. Якщо у BIOS все зробити правильно, то швидкості додасться. На деяких материнських платах налаштуваннями BIOS можна зробити так, що режим продуктивності Windows ролі не гратиме. (Приклади налаштування BIOS у Гільова). Ці налаштування здебільшого стосуються серверних процесорів або "просунутих" BIOS, якщо Ви таке у себе не знайшли, і у вас НЕ Xeon – нічого страшного.

Панель управління – Електроживлення – Висока продуктивність. Мінус - якщо ТО комптютера давно не проводилося, він дужче гудітиме вентилятором, більше грітиметься і споживатиме більше енергії. Це – плата за продуктивність.

Як перевірити, що режим увімкнено. Запускаємо диспетчер завдань – швидкодія – монітор ресурсів – ЦП. Чекаємо, поки процесор нічим не зайнятий.

Це налаштування за замовчуванням. У BIOS C-state включені, режим енергоспоживання збалансований
У BIOS C-state включені, режим високої продуктивності Для Pentium та Core на цьому можна зупинитися, з Xeon ще можна вичавити трохи "папужок"
У BIOS C-state вимкнені, режим високої продуктивності. Якщо не використовувати Turbo boost - саме так має виглядати сервер, налаштований на продуктивність

А зараз цифри. Нагадаю: Intel Xeon 5650, ramdisk. У першому випадку тест показує 23.26, в останньому – 49.5. Різниця – майже дворазова. Цифри можуть змінюватись, але співвідношення залишається практично таким же для Intel Core.

Шановні адміністратори, ви можете як завгодно лаяти 1С, але якщо кінцевим користувачам потрібна швидкість, необхідно включати режим високої продуктивності.

в) Turbo Boost. Спочатку треба зрозуміти, чи підтримує Ваш процесор цю функцію, наприклад. Якщо підтримує, можна ще цілком легально отримати трохи продуктивності. (Питання розгону по частоті, особливо серверів, торкатися не хочу, робіть це на свій страх і ризик. Але погоджуся з тим, що підвищення Bus speed зі 133 до 166 дає дуже відчутний приріст як швидкості, так і тепловиділення)

Як включати turbo boost написано, наприклад, . Але! Для 1С є деякі нюанси (не найочевидніші). Складність у цьому, що максимальний ефект від turbo boost проявляється тоді, коли включені C-state. І виходить приблизно така картинка:

Зверніть увагу, що множник – максимальний, частота Core speed – найкрасивіша, продуктивність – висока. Але що буде в результаті з 1с?

А в результаті виходить, що за тестами продуктивності ЦПУ варіант з множником 23 попереду, за тестами Гілева у файловій версії - продуктивність з множником 22 і 23 однакова, а ось у клієнт-серверній - варіант з множником 23 жах жах жах (навіть, якщо C -state виставити на рівень 7, все одно повільніше, ніж з вимкненим C-state). Тому рекомендація, перевірте обидва варіанти у себе, та виберіть з них найкращий. У будь-якому випадку, різниця 49,5 та 53 папуги – досить значна, тим більше це без особливих зусиль.

Висновок – turbo boost включати обов'язково. Нагадаю, що недостатньо включити пункт Turbo boost у біосі, треба ще подивитися й інші налаштування (BIOS: QPI L0s, L1 – disable, demand scrubbing – disable, Intel SpeedStep – enable, Turbo boost – enable. Панель управління – Електроживлення – Висока продуктивність) . І я все-таки (навіть для файлової версії) зупинився на варіанті, де c-state вимкнений, хоч там множник і менше. Вийде якось так...

Досить спірним моментом є частота пам'яті. Наприклад, ось частота пам'яті показується як дуже сильно впливає. Мої ж тести – такої залежності не виявили. Я не порівнюватиму DDR ​​2/3/4, я покажу результати зміни частоти в межах однієї лінійки. Пам'ять та сама, але у біосі примусово ставимо менші частоти.

І результати тестування. 1С 8.2.19.83, для файлового варіанта локальний рамдиск, для клієнт-серверного 1С та SQL на одному комп'ютері, Shared memory. Turbo boost в обох випадках вимкнено. 8.3 показує порівняні результати.

Різниця – у межах похибки вимірювань. Я спеціально витягнув скрини CPU-Z щоб показати, що зі зміною частоти змінюються й інші параметри, ті ж самі CAS Latency і RAS to CAS Delay, що нівелює зміну частоти. Різниця буде тоді, коли фізично змінюватимуться модулі пам'яті, з повільніших на швидші, але й там цифри не надто значні.

2. Коли з процесором та пам'яттю клієнтського комп'ютера розібралися, переходимо до наступного дуже важливого місця – мережі. Про тюнінг мережі написано багато томів книг, є статті на Інфостарті ( , та інші), тут я на цю тему загострювати увагу не буду. Перед початком тестування 1С прохання переконатися, що iperf між двома комп'ютерами показує всю смугу (для 1 гбіт карток – ну хоча б 850 мбіт, а краще 950-980), що виконані поради Гільова. Потім - найпростішою перевіркою роботи буде, хоч як це дивно, копіювання одного великого файлу (5-10 гігабайт) по мережі. Непрямою ознакою нормальної роботи на мережі в 1 гбіт буде середня швидкість копіювання 100 мб/сек, хорошої роботи - 120 мб/сек. Хочу звернути увагу, що слабким місцем (зокрема) може бути завантаженість процесора. SMB протокол на Linux досить погано паралеліться, і під час роботи він цілком спокійно може з'їсти одне ядро ​​процесора, і більше не споживати.

І ще. За замовчуванням windows клієнт найкраще працює з windows server (або навіть windows робоча станція) і протоколом SMB/CIFS, linux клієнт (debian, ubuntu інші не дивився) краще працює з linux і NFS (з SMB теж працює, але на NFS папуги вище). Те, що при лінійному копіюванні вин-лінукс сервер на НФС копіюється в один потік швидше, ще ні про що не говорить. Тюнінг debian для 1С - тема окремої статті, я до неї ще не готовий, хоча можу сказати, що у файловій версії отримував навіть трохи більшу продуктивність, ніж Win варіант на цьому ж обладнанні, але з postgres при користувачах понад 50 у мене поки що все дуже погано.

Найголовніше , про що знають адміністратори, що не "обпеклися", але не враховують початківці. Є багато способів задати шлях до бази 1с. Можна зробити \\server\share, можна \\192.168.0.1\share, можна net use z: \\192.168.0.1\share (і в деяких випадках такий спосіб теж спрацює, але далеко не завжди) і потім вказувати диск Z. Начебто всі ці шляхи вказують на те саме місце, але для 1С є тільки один спосіб, досить стабільно дає нормальну продуктивність. Так ось, правильно робити треба так:

У командному рядку (або в політиках, або як Вам зручно) - робите net use DriveLetter:\server\share. Приклад: net use m: \\server\bases. Я спеціально наголошую, НЕ IP адресу, а саме ім'ясервера. Якщо сервер на ім'я не видно - додайте його в dns на сервері, або локально у файл hosts. Але звернення має бути на ім'я. Відповідно - в дорозі до бази звертатися до цього диска (див. картинку).

А тепер я на цифрах покажу, чому саме така порада. Вихідні дані: Карти Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. ОС Win 2008 R2, Win 7, Debian 8. Драйвера останні, оновлення застосовані. Перед тестуванням я переконався, що Iperf дає повну смугу (крім 10 гбіт карток, там вийшло тільки 7.2 Gbit вичавити, пізніше подивлюся чому тестовий сервер ще не налаштований як треба). Диски різні, але скрізь SSD (спеціально вставив одиночний диск для тестування, більше не навантажений) або рейд з SSD. Швидкість 100 Mbit отримана шляхом обмеження в налаштуваннях адаптера Intel 362. Різниці між 1 Gbit мідь Intel 350 та 1 Gbit оптика Intel X520-DA2 (отриманої шляхом обмеження швидкості адаптера) не виявлено. Максимальна продуктивність, турбобуст вимкнений (просто для сумісності результатів, турбобуст для хороших результатів додає трохи менше 10%, для поганих – взагалі може не позначитися). Версії 1С 8.2.19.86, 8.3.6.2076. Цифри наводжу не всі, а найцікавіші, щоб було з чим порівнювати.

Висновки (з таблиці, і з особистого досвіду. Стосується лише файлової версії):

По мережі можна отримати цілком нормальні цифри для роботи, якщо цю мережу нормально налаштувати і правильно прописати шлях в 1С. Навіть перші Core i3 можуть давати 40+ папуг, що досить непогано, причому це не тільки папуги, в реальній роботі різниця теж помітна. Але! обмеженням при роботі кількох (більше 10) користувачів вже виступатиме не мережа, тут 1 Гбіт ще вистачить, а блокування при розрахованій на багато користувачів роботі (Гілів).

Платформа 1C 8.3 в рази вимогливіша до грамотного настроювання мережі. Базові налаштування - див Гільов, але врахуйте, що впливати може все. Бачив прискорення від того, що деінсталювали (а не просто відключали) антивірус, від прибирання протоколів типу FCoE, від зміни драйверів на більш стару, але microsoft certified версію (особливо стосується дешевих карток типу асусів та довжин), від прибирання другої мережевої картки із сервера . Багато варіантів, налаштовуйте мережу вдумливо. Цілком можливо ситуація, коли платформа 8.2 дає прийняті цифри, а 8.3 - у два або навіть більше разів менше. Спробуйте погратися з версіями платформи 8.3, іноді виходить дуже великий ефект.

1С 8.3.6.2076 (може і пізніші, точну версію ще не шукав) по мережі все-таки налаштувати простіше, ніж 8.3.7.2008. Домогтися від 8.3.7.2008 нормальної роботи по мережі (у порівнянних папугах) вдалося всього кілька разів, повторити для більш загального випадку не зміг. Сильно не розбирався, але судячи з онуч від Process Explorer там запис не так йде, як у 8.3.6.

Незважаючи на те, що при роботі на 100Мбіт мережі графік її завантаженості невеликий (можна сказати що мережа вільна), швидкість роботи все одно набагато менше, ніж на 1 гбіт. Причина – затримки (latency) мережі.

За інших рівних умов (добре працюючої мережі) для 1С 8.2 з'єднання Intel-Realtek повільніше на 10%, ніж Intel-Intel. А ось realtek-realtek взагалі можуть дати різкі просідання на рівному місці. Тому, якщо є гроші – краще скрізь тримати мережеві картки Intel, якщо грошей немає – то Intel ставити тільки на сервер (ваш К.О.). Та й інструкцій з тюнінгу інтелевих мережевих карток у рази більше.

Налаштування антивірусів за замовчуванням (на прикладі drweb 10 версії) забирають близько 8-10% папуг. Якщо налаштувати як треба (дозволити процесу 1cv8 робити все, хоч це і не безпечно) – швидкість така сама, як і без антивірусу.

Лінуксовий гуру НЕ читати. Сервер із samba це здорово і безкоштовно, але якщо на сервер поставити Win XP або Win7 (а ще краще – серверні ОС), то у файловій версії 1с працюватиме швидше. Так, і samba і стек протоколів та налаштування мережі та багато іншого в debian/ubuntu добре тюнінгується, але робити це рекомендується фахівцям. Немає сенсу ставити лінукс з параметрами за замовчуванням і потім говорити, що він повільно працює.

Досить добре перевіряти роботу дисків, підключених через net use, з допомогою fio . Принаймні буде зрозуміло, чи це проблеми з платформою 1С, чи з мережею/диском.

Для однокористувацького варіанта не можу вигадати тести (або ситуацію), де була б видна різниця між 1Гбіт і 10 Гбіт. Єдине, де 10Гбіт для файлової версії дав результат краще – це підключення дисків по iSCSI, але це тема окремої статті. Все-таки вважаю, що для файлової версії 1 Гбіт карток достатньо.

Чому при 100 Мбіт мережі 8.3 працює помітно швидше за 8.2 - не розумію, але факт мав місце бути. Все інше обладнання, всі інші установки абсолютно однакові, просто в одному випадку тестується 8.2, а в іншому - 8.3.

Не тюнінгований NFS win-win або win-lin дає 6 папуг, у таблицю включати не став. Після тюнінгу 25 отримав, але нестабільно (розбіг у вимірах більше 2 одиниць). Поки що не можу дати рекомендації щодо використання windows та NFS протоколу.

Після всіх налаштувань і перевірок запускаємо знову тест з клієнтського комп'ютера, радіємо результату, що покращився (якщо вийшло). Якщо результат покращився, папуг стало більше 30 (а особливо більше 40), користувачів одночасно працює менше 10 а робоча база все одно гальмує - практично однозначно проблеми програміста (або Ви вже досягли піку можливостей файлової версії).

Термінальний сервер. (База лежить на сервері, клієнти підключаються по мережі, протокол RDP). Алгоритм за кроками:

0. Додаємо на сервер тестову базу Гільова в ту саму папку, що й основні бази. З цього сервера підключаємося, запускаємо тест. Запам'ятовуємо результат.

1. Так само, як і у файловій версії, налаштовуємо роботу . Що стосується термінального сервера - процесор взагалі несе у собі основну роль (маю на увазі, що немає явних слабких місць, типу браку пам'яті чи величезної кількості непотрібного ПЗ).

2. Налаштування мережевих карток у разі термінального сервера мало впливає працювати 1с. Для забезпечення "особливого" комфорту, якщо у вас сервер видає більше 50 папуг можна погратися з новими версіями RDP протоколу, просто для комфорту роботи користувачів, швидшого відгуку та скролінгу.

3. При активній роботі великої кількості користувачів (а тут вже можна пробувати і 30 осіб на одну базу підключити, якщо постаратися) дуже бажано поставити диск SSD. Чомусь вважається, що диск не дуже впливає на роботу 1С, але всі тести проводять із включеним на запис кешем контролера, що неправильно. Тестова база маленька, вона цілком міститься в кеш, звідси й високі цифри. На реальних (великих) базах все буде зовсім інакше, тому для тестів кеш вимкнено.

Наприклад, перевірив роботу тесту Гілева з різними варіантами дисків. Диски ставив із того, що було під рукою, просто тенденцію показати. Різниця між 8.3.6.2076 та 8.3.7.2008 невелика (у варіанті Ramdisk Turbo boost 8.3.6 видає 56.18 а 8.3.7.2008 видає 55.56, в решті тестів різниця ще менша). Енергоспоживання – максимальна продуктивність, turbo boost відключено (якщо не сказано інше).

Увімкнений кеш RAID контролера нівелює всю різницю між дисками, цифри однакові і для сата, і для сас. Тестування з нею для невеликого обсягу даних марна і є якимось показником.

Для платформи 8.2 різниця у продуктивності між SATA та SSD варіантами - більш ніж удвічі. Це не помилка. Якщо під час тесту на CATA дисках дивитися на монітор продуктивності. то там явно видно активний час роботи диска (в%) 80-95. Так, якщо включити кеш самих дисків на запис, швидкість зросте до 35, якщо включити кеш рейд контролера - до 49 (незалежно від того, які диски тестуються в даний момент). Але це - синтетичні папуги кешу, у реальній роботі при великих базах ніколи не буде 100% write cache hit ratio.

Швидкість навіть дешевих ССД (я тестував на Agility 3) цілком вистачає для роботи файлової версії. Ресурс запису - інша річ, тут треба дивитися в кожному конкретному випадку, зрозуміло, що у Intel 3700 він буде на порядок вище, але там і ціна відповідна. І так, я розумію, що при тестуванні SSD диска я теж тестую переважно кеш цього диска, реальні результати будуть меншими.

Найправильнішим (на мою думку) рішенням буде виділити 2 ССД диска в дзеркальний рейд для файлової бази (або кількох файлових баз), і нічого більше туди не поміщати. Так, при дзеркалі ССД зношуються однаково і це мінус, але хоча б від помилок електроніки контролера хоч якось застраховані.

Основні плюси ССД дисків для файлового варіанта з'являться тоді, коли буде багато баз і в кожній по кілька користувачів. Якщо баз 1-2 і користувачів в районі 10, то і SAS дисків вистачить. (але у будь-якому разі - дивитися завантаження цих дисків, хоча б через perfmon).

Основні плюси термінального сервера – у нього можуть бути дуже слабкі клієнти, і налаштування мережі на термінальний сервер впливають набагато менше (знову ваш К.О.).

Висновки: якщо на термінальному сервері запустити тест Гілева (з того ж диска, де лежать робочі бази) і в ті моменти, коли гальмує робоча база, і тест Гілева покаже хороший результат (вище 30) - то в повільній роботі основної робочої бази винен, найімовірніше, програміст.

Якщо ж і тест Гілева показуємо маленькі цифри, і у вас і процесор з високою частотою, і швидкі диски, то ось тут адміністратору треба брати як мінімум perfmon, причому із записом всіх результатів куди-небудь, і дивитися, спостерігати, робити висновки. Однозначних порад не буде.

Клієнт-серверний варіант.

Тести проводив лише з 8.2, т.к. на 8.3 все досить серйозно залежить від версії.

Для тестування вибирав різні варіанти серверів та мережі між ними, щоб показати основні тенденції.

Начебто всі цікаві варіанти розглянув, якщо щось цікавить ще – пишіть у коментарі, постараюся зробити.

САС на СХД працює повільніше, ніж локальні ССД, навіть незважаючи на те, що СХД має великі розміри кешу. ССД і локальні та на СХД для тесту Гілева працюють з порівнянною швидкістю. Якийсь стандартний багатопотоковий тест (не тільки запису, а всього обладнання) крім навантажувального 1С із ЦУП я не знаю.

Зміна сервера 1С з 5520 на 5650 дала майже подвоєння продуктивності. Так, конфігурації серверів не збігаються повністю, але тенденцію показує (нічого дивного).

Збільшення частоти на сервері SQL звичайно дає ефект, але не такий, як на сервері 1С, MS SQL сервер чудово вміє (якщо його про це попросити) використовувати багатоядерність та вільну пам'ять.

Зміна мережі між 1С та SQL з 1 гбіт на 10 гбіт дає приблизно 10% папуг. Чекав на більше.

Включення Shared memory ефект все-таки дає, хоч і не 15%, як описано. Робити обов'язково, благо це швидко та просто. Якщо хтось при установці дав серверу SQL іменований інстанс, то для роботи 1С ім'я сервера треба вказувати не FQDN (працюватиме tcp/ip), не через localhost або просто ServerName, а через ServerName\InstanceName, наприклад zz-test\zztest. (Інакше буде помилка СУБД: Microsoft SQL Server Native Client 10.0: Постачальник спільної пам'яті: Не знайдено бібліотеку спільної пам'яті, що використовується для встановлення з'єднання з SQL Server 2000 . state=1, Severity=10, native=126, line=0).

Для користувачів менше 100 єдиний сенс для рознесення на два окремі сервери – це ліцензія на Win 2008 Std (і старіші версії), яка підтримує лише 32 Гб ОЗУ. У всіх інших випадках - 1С і SQL однозначно треба ставити на один сервер і давати йому більше (хоча б 64 Гб) пам'яті. Давати MS SQL менше 24-28 Гб ОЗУ - невиправдана жадібність (якщо Ви думаєте, що у Вас цієї пам'яті йому вистачає і все нормально працює - може Вам і файлової версії 1С вистачило?)

Наскільки гірше працює зв'язка 1С і SQL у віртуальній машині – тема окремої статті (підказка – помітно гірша). Навіть у Hyper-V все не так однозначно.

Збалансований режим продуктивності – це погано. Результати цілком корелюють із файловою версією.

У багатьох джерелах написано, що режим налагодження (ragent.exe -debug) дає сильне зниження продуктивності. Ну знижує, так, але 2-3% я не назвав би значним ефектом.