Максимально ефективна за швидкістю роботи - серверна схема, для клієнт-серверної 1С 8.х

Передмова

Постійно стикався з висловлюваннями ІТ фахівців "мережа навантажена на 20%... процесори на 50%... черг до дисків мало... Значить мережа і сервери справляються... дивіться код в 1С проблеми виключно там ".

Насправді відбувалося наступне (сервер 1С і SQL рознесено на різні комп'ютери): мережа практично використовувалася по максимуму (ці "20% завантаження мережевого інтерфейсу" "=" 20% корисні дані "+" 80% втрата на службовій обробці "). І відповідно через малу ширину каналу обміну «корисними» даними - SQL сервер з «Сервером 1С» постійно очікували один одного, що вело до малої утилізації ресурсів CPU і дискової системи.

Ведення: Спочатку хочу загострити увагу на тому що ж таке 1С платформа?.

Отже почнемо з головного 1С - побудована на ORM (об'єктно-реляційному відображенні) -система і програміст в ній працює не безпосередньо з реляційним уявленням, а з об'єктами.

ru.wikipedia.org/wiki/ORM

Програміст у середовищі 1С - пише об'єктну логіку, а за складання/розбирання і запис об'єктів у «плаский вигляд» по таблицях бази даних відповідає сама платформа.

Основні "" + "і" "-" "з точки зору ORM:

«» + «» Програміст у середовищі ORM отримує перевагу у швидкості розробки програми через зменшення кількості коду і його простоти порівняно з виключно реляційним програмним кодом (приклад SQL запити). А також звільняється від написання коду працюючого безпосередньо із записами в таблицях Реляційної СУБД. * 1

"-" "Складнощі для творців" платформ "ORM і проблеми продуктивності:

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

* 1 «Уточнення». Незважаючи на те, що 1С 8.х дозволяє працювати з реляційно-подібним кодом (тільки читання) в об'єкті 1С «Запит» - це все-таки не безпосередньо один-в-один транслюваний в реляційну СУБД запит до таблиць зберігання даних, а насамперед «Об'єктний запит» - також не минає стадію збирання розбирання об'єктів. Тому найчастіше замість багато-тисячі рядкових «Об'єктних запитів» - найбільш оптимально за швидкодією коду і швидкістю розробки - написати об'єктний не ряляційно-подібний код.

Глава 1: Розглянемо модель клієнт-серверної 1С 8.х

Зазначу основні «вузькі» місця, що впливають на продуктивність:

1) Перше вузьке місце - це комунікаційне середовище передачі даних.

На малюнку стрілками показано потоки обміну даними, де «червоні» - це Реляційна СУБД < - > Об'єктна СУБ, «помаранчеві» - синхронізація між Об'єктними СУБД.

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

Розгляньмо на прикладі мережевого стандарту Ethernet Gigabit (графік залежності швидкості передачі даних... нижче)

на прикладі роботи Сервера 1С з MS SQL (типовий розмір комунікаційних пакетів 4 кб):

На графіку видно, що при використанні пакетів ДАНИХ = 4 кб пропускна здатність розглянутої мережі всього 250 Мегабіт/с. (як правильно помітили в коментарі до публікації: це не пакети протоколів наприклад рівня TCP, а пакети ДАНИХ які генерують програми, що беруть участь в обміні)

З практики: такий рознесення на Два окремі сервери

MS SQL (сервер № 1) < - Ethernet Gigabit --- > «Сервер 1С» (сервер № 1)

програвало за швидкістю роботи платформи

на 50% варіанту MS SQL (сервер № 1) < - Shared Memory (без мережі через ділянку пам'яті) --- > «Сервер 1С» (сервер № 1)... і це вже «на одному високонавантаженому сеансі користувача»

2) Вузьке місце - це кількість окремих комп'ютерів «кластерів 1С», чим їх більше тим більше витрати на синхронізацію і як наслідок зменшення продуктивності системи.

3) Вузьке місце - кількість окремих процесів сервера 1с, чим їх більше тим більше витрат на їх синхронізацію... Але тут швидше за все необхідно знайти «золоту середину» - для забезпечення стабільності. 2*

2 * «Уточнення» - для MS Windows існує таке правило:

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

Тому наприклад «Файлова 1С 8.х» завжди перевищує за швидкістю однокористувацької роботи платформи в клієнт-серверному варіанті. Все просто тому що у випадку «Файловий 1С 8.х» потік «Реляційної СУБД» спілкується з потоком «Об'єктної СУБД» всередині одного єдиного процесу.

4) Вузьке місце - одне-поточність сеансу користувача, оскільки кожен окремо взятий - сеанс користувача не розпаралелюється платформою на кілька, його робота обмежується використанням ресурсів одного ядра CPU = > отже бажана максимальна швидкість кожного ядра, в цьому випадку швидкодія платформи 1C наприклад на 10-ядерному CPU по 1 ггц - буде значно поступатися швидкодії платформи на 4-ох ядерному CPU по 3 Ггц - природно до певної кількості потоків.

Розділ 2 (Підсумок): Розглянемо не масштабований і масштабований варіанти - найбільш ефективних схем для платформи 1с 8.х. для OS Windows (пологаю для Linux ситуація аналогічна)

1-Варіант (не масштабований). У розрахунку на 100 «високонавантажених користувальницьких сеансу»

1) ефективний звичайний 2-ох сокетний сервер з 4-ох ядерними CPU по 3 Ггц.

2) швидка дискова система на SSD

3) MS SQL < - Shared memory -- > Сервер 1С

2-Варіант (масштабований). починаючи зі 100 «високонавантажених сеансів користувача» і далі....

Тут найлогічніше піти шляхом німецької 1с-ки «Sap HANA»))

Збирати модульний «Супер-комп'ютер» від фірми SGI - що складається з «лез» на 2-х сокетних материнських платах, кожна леза з'єднується один з одним складною топологією понад-швидкого інтерконекту на основі NUMA-чіпів, і все знаходиться під управлінням єдиної OS. Тобто. програми всередині такого сервера за визначенням мають доступ до ресурсів будь-якого «леза».

1) додаємо «леза» за необхідним навантаженням... з розрахунку приблизно одне «лезо» на 100 користувачів.

2) швидка дискова система на SSD

3) MS SQL < - Shared memory -- > Сервер 1С