1С:Предприятие и многопоточность. Часть 2. Файловая база
По замыслу 1С файловая база предназначена для самых-самых маленьких и имеет серьезные ограничения как по размеру, так и по количеству одновременно работающих пользователей. И очень часто негативный опыт, полученный на файловых базах, переносится на всю систему 1С:Предприятие в целом.
Но начнем мы с краткого рассмотрения типов клиентов 1С, которые можно условно разделить на толстый и тонкие (сам тонкий, веб и мобильный клиенты). Основное отличие толстого клиента в том, что толстый клиент выполняет как серверный, так и клиентский код.
С файловой базой напрямую может работать только толстый клиент. А еще толстый клиент однопоточен. Все задачи ставятся в единую очередь и исполняются в один поток, преимущественно одним ядром. И критическое значение в данном случае имеет однопоточная производительность процессора и его тактовая частота.
Но, если вы уж совсем не сэкономили на процессоре, то это не доставляет пользователю существенных неудобств. Просто потому, что масштабы выполняемых задач не те. А для одного пользователя производительности даже одного потока вполне достаточно.
Кроме основного потока толстый клиент запускает второй, дополнительный поток для работы фоновых заданий. С их помощью могут выполняться как регламентные задания, так и тяжелые, длительные операции, чтобы не блокировать работу пользователя в основном потоке.
Таким образом пользователь может запустить тяжелый отчет или обработку, а сам перейти к другим разделам программы, скажем, вводить документы. И не испытывать при этом никаких особых неудобств, так как основные тяжелые вычисления будут выполняться вторым потоком.
Но следует помнить, что дополнительный поток также один и все фоновые задания будут становиться в нем в очередь. Поэтому внимательно отнеситесь к тому, что у вас запускается в фоне, особенно к регламентным заданиям:
✅ Почему тормозит 1С. Регламентные задания
Но вся эта благодать исчезает, как только в базе появляются дополнительные пользователи. Многим знакома картина, когда производительность файловой базы резко проседает уже при подключении к ней второго пользователя.
В чем тут дело? Вспоминаем, что с данными в СУБД может работать только сервер, в нашем случае сервер – это толстый клиент. Роль СУБД выполняет файловая база, которая является полноценной базой данных собственного формата.
При запуске нескольких толстых клиентов на разных рабочих местах мы получаем несколько серверов, взаимодействующих с СУБД, это приводит не только к кратному увеличению сетевого трафика и нагрузки на дисковую подсистему хранилища файловой базы, но и появлению блокировок.
Блокировка – это специальный режим работы СУБД, когда она для избежания рассогласования информации блокирует таблицы при обращении к ним одного из клиентов и остальным приходится ждать пока таблица освободиться.
А если кто-то запустил на медленном ПК длительную операцию в транзакции, то ждать будет вся сеть.
Файловая структура только все это усугубляет. Если у нас есть пять клиентов и каждый из которых хочет получить справочник номенклатуры, то все пять серверов толстого клиента по разу скачают себе этот справочник и самостоятельно займутся его обработкой. Без всякого кеширования и повторного использования.
Поэтому в файловых базах с разделяемым по сети общим ресурсом узким местом очень быстро становится не однопоточность (точнее двухпоточность), а блокировки и избыточное количество сетевого трафика. И если со вторым еще можно бороться апгрейдом или перепланировкой сети, то блокировки надежно убивают производительность уже начиная с трех-пяти активных клиентов.
Дополнительные материалы:
🔹 1С:Предприятие и многопоточность. Часть 1. Общие вопросы
По замыслу 1С файловая база предназначена для самых-самых маленьких и имеет серьезные ограничения как по размеру, так и по количеству одновременно работающих пользователей. И очень часто негативный опыт, полученный на файловых базах, переносится на всю систему 1С:Предприятие в целом.
Но начнем мы с краткого рассмотрения типов клиентов 1С, которые можно условно разделить на толстый и тонкие (сам тонкий, веб и мобильный клиенты). Основное отличие толстого клиента в том, что толстый клиент выполняет как серверный, так и клиентский код.
С файловой базой напрямую может работать только толстый клиент. А еще толстый клиент однопоточен. Все задачи ставятся в единую очередь и исполняются в один поток, преимущественно одним ядром. И критическое значение в данном случае имеет однопоточная производительность процессора и его тактовая частота.
Но, если вы уж совсем не сэкономили на процессоре, то это не доставляет пользователю существенных неудобств. Просто потому, что масштабы выполняемых задач не те. А для одного пользователя производительности даже одного потока вполне достаточно.
Кроме основного потока толстый клиент запускает второй, дополнительный поток для работы фоновых заданий. С их помощью могут выполняться как регламентные задания, так и тяжелые, длительные операции, чтобы не блокировать работу пользователя в основном потоке.
Таким образом пользователь может запустить тяжелый отчет или обработку, а сам перейти к другим разделам программы, скажем, вводить документы. И не испытывать при этом никаких особых неудобств, так как основные тяжелые вычисления будут выполняться вторым потоком.
Но следует помнить, что дополнительный поток также один и все фоновые задания будут становиться в нем в очередь. Поэтому внимательно отнеситесь к тому, что у вас запускается в фоне, особенно к регламентным заданиям:
✅ Почему тормозит 1С. Регламентные задания
Но вся эта благодать исчезает, как только в базе появляются дополнительные пользователи. Многим знакома картина, когда производительность файловой базы резко проседает уже при подключении к ней второго пользователя.
В чем тут дело? Вспоминаем, что с данными в СУБД может работать только сервер, в нашем случае сервер – это толстый клиент. Роль СУБД выполняет файловая база, которая является полноценной базой данных собственного формата.
При запуске нескольких толстых клиентов на разных рабочих местах мы получаем несколько серверов, взаимодействующих с СУБД, это приводит не только к кратному увеличению сетевого трафика и нагрузки на дисковую подсистему хранилища файловой базы, но и появлению блокировок.
Блокировка – это специальный режим работы СУБД, когда она для избежания рассогласования информации блокирует таблицы при обращении к ним одного из клиентов и остальным приходится ждать пока таблица освободиться.
А если кто-то запустил на медленном ПК длительную операцию в транзакции, то ждать будет вся сеть.
Файловая структура только все это усугубляет. Если у нас есть пять клиентов и каждый из которых хочет получить справочник номенклатуры, то все пять серверов толстого клиента по разу скачают себе этот справочник и самостоятельно займутся его обработкой. Без всякого кеширования и повторного использования.
Поэтому в файловых базах с разделяемым по сети общим ресурсом узким местом очень быстро становится не однопоточность (точнее двухпоточность), а блокировки и избыточное количество сетевого трафика. И если со вторым еще можно бороться апгрейдом или перепланировкой сети, то блокировки надежно убивают производительность уже начиная с трех-пяти активных клиентов.
Дополнительные материалы:
🔹 1С:Предприятие и многопоточность. Часть 1. Общие вопросы
👍14❤6👀2
🚀⚙️ Хотите упростить свою работу в Linux? Научитесь писать скрипты с помощью Bash!
👉 Присоединяйтесь к открытому вебинару 25 августа в 20:00 МСК и разберитесь, как с помощью Bash автоматизировать рутинные задачи в Linux. Мы объясним, как работать с интерпретатором Bash, создавать переменные, использовать условия и циклы.
💪 Этот вебинар поможет быстро освоить базовые навыки Bash и научиться автоматизировать простые операции, что значительно упростит рабочий процесс.
🎁 Запишитесь на вебинар и получите индивидуальное предложение на курс «Administrator Linux. Basic».
👉 Для участия зарегистрируйтесь: https://otus.pw/eJFt/?erid=2W5zFJ7nNzU
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
👉 Присоединяйтесь к открытому вебинару 25 августа в 20:00 МСК и разберитесь, как с помощью Bash автоматизировать рутинные задачи в Linux. Мы объясним, как работать с интерпретатором Bash, создавать переменные, использовать условия и циклы.
💪 Этот вебинар поможет быстро освоить базовые навыки Bash и научиться автоматизировать простые операции, что значительно упростит рабочий процесс.
🎁 Запишитесь на вебинар и получите индивидуальное предложение на курс «Administrator Linux. Basic».
👉 Для участия зарегистрируйтесь: https://otus.pw/eJFt/?erid=2W5zFJ7nNzU
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
❤1
Amber – делаем программирование на Bash проще
Bash – достаточно сложный в освоении скриптовый язык, особенно для тех, кто не пишет на нем постоянно. Сложности вызывает как синтаксис, так и то, что язык не предоставляет никаких проверок, оставляя все на откуп программиста.
И хорошо, когда у вас есть опыт и вы сразу видите опасные моменты и умеете обкладывать их дополнительными условиями, а если нет, то ваши скрипты могут «порадовать» вас нестандартным поведением в самый неожиданный момент.
Можно ли как-то облегчить процесс написания bash-скриптов? Можно. Одним из вариантов будет использование Amber – нового высокоуровневого языка программирования с синтаксисом, основанным на ECMA Script.
Кстати, широко распространенный JavaScript также основан на спецификации ECMA Script, что облегчает освоение нового языка и снижает порог вхождения. Если вы уже писали на JavaScript, то без особого труда освоите Amber.
Но ключевой особенностью Amber является то, что он не собирается заменить собой bash, наоборот, код, написанный на Amber при компиляции, будет преобразован в bash-скрипт.
В чем еще плюсы такого подхода, кроме более простого синтаксиса? В таких фишках как type-safe и runtime-safe. Для тех, кто не в курсе попробуем объяснить на пальцах.
Bash – язык со слабой, неявной динамической типизацией. Т.е. типы переменных не задаются и зависят от их содержимого, также в процессе исполнения кода типы переменных могут меняться или неявно преобразовываться.
Например, если мы присвоили одной переменной строковое значение, а второй целочисленное, а затем сложили их, то произойдет неявное преобразование числа в строку и последующая конкатенация (сложение двух строк). Итоговая переменная также станет строкой.
Это удобно, но требует от программиста постоянного контроля и проверки типов, в противном случае возможны ошибки, причем не всегда, а в зависимости от полученных скриптом данных или результатов других вычислений.
Amber позволяет взять этот вопрос на себя и на этапе компиляции сообщить вам об ошибках используемых типов данных (type-safe) или возможных проблемах при их обработке во время исполнения программы (runtime-safe).
При том, чтобы начать писать на Amber не нужно вообще ничего, кроме плагина к VS Code, сам Amber является только компилятором и его можно установить на любой Linux или в Windows WSL.
Ближе познакомиться с продуктом можно на сайте проекта: https://amber-lang.com
Несмотря на то, что продукт еще очень молодой он уже представляет определенный интерес и заслуживает внимания.
Bash – достаточно сложный в освоении скриптовый язык, особенно для тех, кто не пишет на нем постоянно. Сложности вызывает как синтаксис, так и то, что язык не предоставляет никаких проверок, оставляя все на откуп программиста.
И хорошо, когда у вас есть опыт и вы сразу видите опасные моменты и умеете обкладывать их дополнительными условиями, а если нет, то ваши скрипты могут «порадовать» вас нестандартным поведением в самый неожиданный момент.
Можно ли как-то облегчить процесс написания bash-скриптов? Можно. Одним из вариантов будет использование Amber – нового высокоуровневого языка программирования с синтаксисом, основанным на ECMA Script.
Кстати, широко распространенный JavaScript также основан на спецификации ECMA Script, что облегчает освоение нового языка и снижает порог вхождения. Если вы уже писали на JavaScript, то без особого труда освоите Amber.
Но ключевой особенностью Amber является то, что он не собирается заменить собой bash, наоборот, код, написанный на Amber при компиляции, будет преобразован в bash-скрипт.
В чем еще плюсы такого подхода, кроме более простого синтаксиса? В таких фишках как type-safe и runtime-safe. Для тех, кто не в курсе попробуем объяснить на пальцах.
Bash – язык со слабой, неявной динамической типизацией. Т.е. типы переменных не задаются и зависят от их содержимого, также в процессе исполнения кода типы переменных могут меняться или неявно преобразовываться.
Например, если мы присвоили одной переменной строковое значение, а второй целочисленное, а затем сложили их, то произойдет неявное преобразование числа в строку и последующая конкатенация (сложение двух строк). Итоговая переменная также станет строкой.
Это удобно, но требует от программиста постоянного контроля и проверки типов, в противном случае возможны ошибки, причем не всегда, а в зависимости от полученных скриптом данных или результатов других вычислений.
Amber позволяет взять этот вопрос на себя и на этапе компиляции сообщить вам об ошибках используемых типов данных (type-safe) или возможных проблемах при их обработке во время исполнения программы (runtime-safe).
При том, чтобы начать писать на Amber не нужно вообще ничего, кроме плагина к VS Code, сам Amber является только компилятором и его можно установить на любой Linux или в Windows WSL.
Ближе познакомиться с продуктом можно на сайте проекта: https://amber-lang.com
Несмотря на то, что продукт еще очень молодой он уже представляет определенный интерес и заслуживает внимания.
🫡4👍2🤣2❤1