
Максимально ефективна за швидкістю роботи - серверна схема, для клієнт-серверної 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С