gifts2017

Технология In-Memory OLTP (для SQL Server 2014)

Опубликовал Денис Кирьяк (close_os) в раздел Администрирование - Системное

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2015 CONNECTION 15-17 октября 2015 года. Мой доклад, в свою очередь, стал результатом почти четырех месячных исследований в отрыве от какой-либо работы. Но «игра стоила свеч», и когда я получил свои результаты, я захотел поделиться ими с сообществом.

Началось все с одной истории, которая три года назад случилась в моей профессиональной карьере, когда я работал в Киргизии, в компании, которая представляла собой сеть розничных магазинов. Тогда у меня произошел разговор с моим директором по IT, который сказал: «Денис, у нас одна из важных, критичных операций – это проведение документа «Чек» на кассах. Как мы можем максимально ускорить этот процесс, распараллелить его, при этом получая оперативные остатки?»

Сразу скажу, что у нас на тот момент использовалась платформа 8.1 и автоматические блокировки. И я тогда ему ответил, что да, мы можем перейти на управляемые блокировки и распараллелить этот процесс на уровне номенклатуры. На что он мне задал естественный вопрос: «а что произойдет, если у нас на нескольких кассах одновременно будет проводиться одна и та же номенклатура?» Тогда я на этот вопрос какого-то внятного ответа дать не смог, но надеюсь, сейчас у меня это получится.

Тренды развития аппаратного обеспечения

Если мы посмотрим на развитие индустрии IT за последние несколько лет, мы увидим определенные тренды в аппаратном обеспечении:

  • Первый тренд касается памяти. Ни для кого не новость, что память со временем дешевеет, и на данный момент мы уже можем получить достаточно большой объем памяти за сравнительно небольшие деньги.
  • Второй тренд – по процессорам. Всем известно соответствие роста производительности, потребляемой мощности и выделяемой температуры процессоров по закону Мура. В определенный момент это соответствие на уровне одного ядра закончилось (сейчас у нас одно ядро уже долгое время не может выполнять одну простую операцию быстрее, чем раньше), но оно продолжилось на уровне многих ядер (многоядерных процессоров). Поэтому все наши надежды и помыслы идут в область параллельных вычислений, и мы, как разработчики и архитекторы СУБД, для повышения производительности наших приложений должны планировать в них параллельность работы.

Тренды развития бизнес-приложений

А что в это время происходит на уровне бизнеса? Мы наблюдаем: все большее количество пользователей, которые используют все большее количество устройств, на которых выполняется все большее количество программ, и все это в свою очередь генерирует все большее количество данных.

При этом большинство из этих процессов поддерживаются облаками.

Помимо облаков есть еще такая сущность, как мобильность, которая представляет собой сочетание всех мобильных устройств, а также программ и данных, ими генерируемых.

Облака и мобильность всегда были связаны между собой, и именно от взаимодействия этих двух сущностей мы в будущем сможем получать какие-то прорывы. Такое взаимодействие привело к появлению известной на Западе стратегии: Mobile-First – Cloud-First (изначально мобильное и изначально облачное).

Индустрия IT всегда менялась, и сейчас меняется, испытывает трансформацию. И в этом мире, изначально мобильном и изначально облачном, непрерывно возрастает темп формирования этих данных, и рост этот – экспоненциальный. Исходя из этого возникает проблема сохранения, накопления и актуализации информации, которая со все возрастающей скоростью попадает в наши системы.

Соответственно, возникает потребность в специальных технологиях. И, если касаться конкретно In-memory OLTP, то это – всего лишь одна из многих технологий, призванных на данный момент обеспечить дальнейшее развитие IT-индустрии.

Технология In-memory OLTP

Почему появилась технология In-memory OLTP? И почему она важна?

  • Дело в том, что бизнес предъявляет все большие требования:
    • к всевозрастающей пропускной способности:
    • к ожидаемому OLTP процессу с прогнозируемой скоростью и минимальными задержками и за небольшие деньги.
  • В свою очередь аппаратное обеспечение предъявляет требования к реляционным базам данных, чтобы они соответствовали последним изменениям в архитектуре аппаратного обеспечения.

Соответственно, In-memory OLTP  – это: высокопроизводительный механизм, который отвечает современному аппаратному обеспечению и максимально оптимизирован для работы с памятью.

И, что самое важное, In-memory OLTP – это не какой-то отдельный продукт (не какая-то отдельная лицензия, за которую нужно платить). Начиная с SQL Server 2014 In-memory OLTP – это часть ядра этого продукта, которая доступна в рамках редакции Enterprise.

Здесь вы видите три основных компонента, которые представляют собой технологию In-memory OLTP. Именно они позволяют ей осуществить такой прорывной эффект:

  • Первое – это четкая установка на то, что все данные находятся в памяти.
  • Второе, что немаловажно: эти данные располагаются в специально разработанных, свободных от блокировок структурах данных.
  • И третье – это нативная, родная компиляция. Она представляет собой хранимые процедуры, содержащие бизнес-логику, которые скомпилированы в машинный код в памяти SQL-сервера.

Сравнение инфраструктуры взаимодействия (традиционной схемы и In-Memory OLTP)

Если мы посмотрим традиционную схему взаимодействия клиента и СУБД, то тут все очевидно:

  • У нас есть клиент со своими клиентскими вызовами,
  • Есть сервер 1С:Предприятие, который вмещает всю бизнес-логику.
  • И есть сервер СУБД. Он в традиционной схеме используется в основном для манипуляции с данными (а конкретно - для четырех операций: выборка, накопление, изменение и удаление).

В случае применения схемы In-Memory OLTP в рамках платформы 1С, схема чуть-чуть меняется:

  • Остаются те же клиенты со своими клиентскими вызовами.
  • Но в данном случае сервер 1С:Предприятие немного трансформируется. В целом полностью остаются все его функции и назначение, но теперь нельзя сказать, что он полностью контролирует всю существующую бизнес-логику. Здесь я его назвал слоем программного сервера. Почему?
    • Потому что появляется дополнительное внешнее прямое соединение к СУБД, с помощью которого осуществляется вызов хранимых процедур, о которых я говорил ранее.
    • Сущность этих хранимых процедур теперь состоит в том, чтобы производить операции с данными в соответствии с той бизнес-логикой, которую вы заложили на уровне СУБД.

Яркий пример того, как физический слой «протек» на слой логический.

Основное преимущество In-Memory OLTP

Здесь на слайде перечислены некоторые основные характеристики технологии In-Memory OLTP. Более подробно об этом можно прочитать в интернете (в основном, на сайте Microsoft, а также в большом количестве блогов западных разработчиков). Здесь же я хочу уточнить один нюанс, о котором я еще не говорил: в In-memory OLTP появился совершенно новый мультиверсионный оптимистичный контроль параллельного выполнения. В его рамках полностью отсутствует какое-либо понятие блокировок при работе с данными. При его работе конфликты между различными потоками редки, но если они и случаются, то быстро решаются, и не нужно очень долго ждать, как в случае использования стандартного блокировочного механизма.

Тестовый сценарий для проверки работы технологии In-Memory OLTP в рамках платформы 1С

Анализируя те возможности, которые дает технология In-memory OLTP, я решил реализовать достаточно простой тестовый сценарий для проверки работы этой технологии в рамках платформы 1С. Демонстрационная среда, которая у меня получилась в результате, выглядела следующим образом:

  • Я взял очень простую конфигурацию с одним регистром накопления, в котором учитывались остатки по номенклатуре в разрезе количества.
  • Также в этой конфигурации было два документа – Приход и Расход, в которых была реализована следующая бизнес-логика:
    • Документ Приход обеспечивал поддержку минимального остатка.
    • А при проведении документа Расход контролировалось отсутствие нулевых остатков.
  • Для того чтобы сымитировать конкурентную многопоточную нагрузку при проведении этих документов, я использовал стандартный подход с фоновыми процессами, которых для проведения документа Расход было подавляющее большинство.
  • Также следует отметить, что я в своей демонстрационной сети использовал две виртуальные машины:
    • Одну – для сервера 1С:Предприятие,
    • А другую – для SQL-сервера.

Но обе виртуальные машины находились в рамках одного хоста виртуализации.

Первый замер – базовый показатель

После того, как эта схема была реализована, я провел контрольный замер базовых показателей для стандартного, традиционного проведения документов средствами 1С с использованием управляемых блокировок. Что я получил в результате первого замера?

На слайде подчеркнуто значение того показателя, который я получил: 120 документов в секунду при 64 фоновых процессах – это тот базовый показатель, который у меня был.

При этом была измерена нагрузка на процессоры:

  • Сверху – нагрузка на сервер 1С:Предприятие
  • И нижняя часть – это нагрузка на процессоры SQL-сервера.

Как вы видите, и там, и там нагрузка небольшая – процессоры отдыхают, работают только управляемые блокировки.

Второй замер – миграция в In-Memory только таблиц

Следующим шагом я решил сделать миграцию структур, в которых хранились стандартные данные, в In-memory-таблицы. И после того, как я их мигрировал, я запустил свой стандартный тест. В нем происходило все то же самое: средствами платформы 1С проводились документы, но только теперь они уже хранились в In-Memory-таблицах (сама платформа об этом не знала).

Результат получился в районе 150 документов в секунду, следовательно, небольшой рост все-таки произошел, но незначительный, и в некоторых системах вы можете даже и не увидеть этого увеличения. В целом, в данном случае нагрузка на процессоры никак не поменялась, поэтому я их здесь даже не привожу.

Хочу добавить к этому, что если кто пытался реализовать эту же задачу, то обычно она вызывает проблемы – чуть позже я расскажу, как эти проблемы решаются.

Третий замер – миграция в In-Memory и таблиц, и бизнес-логики

На третьем шаге помимо того, что была полностью реализована миграция структур данных в In-memory-таблицы, также была полностью смигрирована и та бизнес-логика, которая была нужна для проведения документов – все действия, необходимые для:

  • Формирования документов и их табличных частей;
  • Их записи;
  • Формирования движений документов;
  • И изменения текущих остатков.

В итоге был получен результат 250 документов в секунду. По сути, по отношению к базовому показателю 120 и 250 – это выигрыш чуть больше, чем в два раза.

Тут можно немного посмеяться и сказать, что мы же можем взять железо в два раза мощнее и получить примерно тот же результат. Но все объясняется, если посмотреть на загрузку процессоров в этом случае:

  • Сервер 1С:Предприятия полностью загружен;
  • В то время как сервер SQL занят только на треть.

Мне удалось выяснить, что данная нагрузка на сервер 1С:Предприятие показывала, что он просто не успевал сгенерировать это количество документов на лету, а также не успевал их отдавать на проведение SQL-серверу, чтобы полностью его загрузить.

Позже удалось выяснить, что для того, чтобы полностью загрузить SQL-сервер в данном примере, потребовалось бы около восьми подобных виртуальных машин. Но в этом все равно не было бы никакого смысла, потому что у меня использовался только один хост виртуализации, и никакого дополнительного железного выделенного оборудования у меня не было. Но в дальнейшем это и не понадобилось.

Четвертый замер – передача 15 документов для проведения за один вызов

Четвертый замер я сделал в надежде на то, что удастся все-таки за один сетевой вызов отдавать на SQL-сервер побольше работы. Для этого бизнес-логика была переписана таким образом, чтобы за один вызов отдавать на проведение сразу 15 документов. В результате скорость выросла до 550 документов в секунду.

При этом, как видно на графиках, сервер 1С:Предприятие был все так же полностью загружен, а SQL-сервер продолжал «отдыхать».

По сути, этот сценарий скорее фейковый, потому что он вообще не имеет никакой практической пользы, и был реализован только в качестве проверки. Но в любом случае мы явно видим проблему переноса достаточной нагрузки на SQL-сервер, чтобы полностью его загрузить.

Пятый замер – запуск подготовленной нагрузки на стороне SQL Server

Следующим шагом я решил сгенерировать всю нагрузку предварительно. Эта нагрузка выглядела в виде 64 сформированных файлов SQL-скриптов на 700 мегабайт. Я перенес их на SQL-сервер, и с помощью известной утилиты OStress, которой можно «скормить» эти файлы, чтобы запустить параллельную нагрузку, получил следующий результат.

  • По загрузке процессора – получившееся время отработки поместилось в стандартное окошко диспетчера задач: есть начало нагрузки, потом полностью все процессоры почти на 100% отработали, и нагрузка закончилась.
  • В результате нагрузки было создано 112 тысяч документов, при этом полностью сохранялись все те процессы, которые были при проведении документов «Расход»: контролировались все остатки, выполнялись все действия.
  • Нагрузка заняла 53 с лишним секунды.
  • Если сделать определенные вычисления, получится, что среднее время проведения одного документа составило менее половины миллисекунды,
  • а средняя скорость проведения документов составила больше 2000 документов в секунду.

Когда я первый раз получил этот результат – не мог поверить. Просто представьте себе, какие объемы вам теперь доступны, вы теперь можете мыслить в совсем других категориях. И теперь я могу ответить своему бывшему директору по IT, как мы можем ускорить проведение документов «Чек» на кассах. И даже если при этом у нас будут какие-то конфликты, блокировки, сам процесс теперь пройдет очень быстро.

Методология миграции

Если же вернуться к методологии миграции в In-Memory OLTP, то надо отметить, что она подходит не для всех случаев. Ее надо использовать только для некоторых узких мест вашей системы, где важен гарантированно быстрый доступ к данным. Поэтому прежде, чем внедрять эту технологию, нужно провести тщательный анализ:

  • Например, если сравнить стеки выполнения (традиционный и In-Memory OLTP), то на уровне сетевого взаимодействия ничего не поменялось. Поэтому, если ваша программа (ваше приложение) очень «разговорчивое», обменивается с сервером СУБД очень большим количеством сообщений, то вам технология In-Memory совсем не поможет – здесь нет никаких улучшений.
  • Также, если мы посмотрим на уровень журнала регистрации базы данных, то тут тоже особо ничего не поменялось. Хотя размер журнала регистрации при операциях In-memory OLTP сокращается, минимальная задержка транзакций при записи в этот журнал остается той же.
  • Основную выгоду вы сможете получить только на уровне выполнения запросов и доступа к данным.

Преимущество технологии In-memory OLTP не в том, что данные располагаются в памяти. Хотя технология и называется In-memory, выигрыш происходит не от этого – ускорение происходит за счет того, что меняется инфраструктура самой базы данных:

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

И, если мы посмотрим на стандартную систему, то в случае добавления в нее большого количества потоков, они со временем начинают друг другу мешать, тем самым пропускная способность вашей системы уменьшается. В то же время при использовании технологии In-memory OLTP система при увеличении количества пользователей продолжает масштабироваться, поскольку нет блокировок (используются новые структуры данных, которые их лишены), а также применяются быстрые, предварительно скомпилированные хранимые процедуры.

Что можно сказать по поводу самого процесса миграции в In-memory? Он в целом состоит из двух шагов, которые поочередно повторяются:

  • Первый шаг – это миграция структур данных.
  • И второй шаг – это миграция вашей критичной бизнес-логики на сторону СУБД.

Решение проблемы записи в In-Memory из 1С

При работе из 1С с мигрированными на сторону СУБД  структурами данных возможны некоторые трудности. Например, если при смигрированных таблицах в рамках платформы 1С кто-либо попытается осуществить какую-то запись в таблицы либо в документы (Приход или Расход), вы увидите стандартное сообщение об ошибке, которое в целом говорит о каких-то проблемах в уровнях изоляции.

С чем связана такая ошибка? Стандартная схема выполнения поддерживает пять уровней изоляции, а механизм In-memory OLTP – только три уровня. При этом платформа 1С по умолчанию использует уровень изоляции ReadCommited, которому как раз нет соответствия в механизме In-Memory OLTP. Соответственно, возникает проблема согласованности между этими уровнями изоляции.

Пытаясь решить эту задачу, я потратил очень много времени. И поиск решения даже завел меня в реверс-инжиниринг («обратный инжиниринг»), мне казалось, что придется динамически перехватывать запросы, которые идут от платформы к СУБД, и изменять их текст на лету для того, чтобы они стали соответствовать синтаксису In-Memory. Но оказалось, что решение находится на поверхности – оно тривиальное и простое.

В самом SQL Server 2014, в котором как раз и появилась технология In-Memory, есть такое свойство базы данных, как is_memory_optimized_elevate_to_snapshot_on. По умолчанию, оно неактивно, выключено – это можно проверить запросом, который показан на слайде.

Соответственно, если вы выполните команду, которая активирует это свойство, то проблем с согласованностью уровней изоляции у вас не будет.

При этом вы поднимете уровень изоляции, который СУБД использует по умолчанию, и он как раз будет соответствовать уровню изоляции Snapshot, по умолчанию использующийся для таблиц In-Memory. Таким образом, проведя небольшие манипуляции на стороне СУБД, у вас в In-Memory-таблицы будут записываться любые документы и любые данные.

Общая схема миграции бизнес-логики на сторону СУБД

Что же можно сказать по поводу общей схемы миграции самой бизнес-логики на сторону СУБД?

Она включает в себя два объекта:

  • Во-первых, это та скомпилированная процедура, которая будет выполнять непосредственную работу.
  • И над ней обертка, которая реализует так называемую RetryLogic (логику перезапуска). Почему? Потому что нет никакой гарантии того, что ваша хранимая процедура выполнится. В процессе ее выполнения может произойти какой-то конфликт, поэтому необходимо сделать так, чтобы в результате конкретного сетевого вызова эта процедура, реализующая вашу бизнес-логику, обязательно выполнилась до конца.

Вот примерная схема реализация «обертки». Здесь AddOutcome – это внешний StandardT-SQL-(обертка). Внутри цикла располагается процедура, уже непосредственно скомпилированная в машинные коды. Видно блок TRY (Retry). Соответственно, если возникает конфликт, то происходит исключение, в котором вы, как разработчик, закладываете какой-то период ожидания, чтобы конфликтующая транзакция успела выполниться, а затем, соответственно, выполнится ваша.

Заключение

Ну и в заключение можно сказать, что миграция в таблицы In-Memory OLTPприменительно к 1С потребует задействовать:

  • Большое количество интеллектуальных и финансовых ресурсов,
  • Подключение большого количества специалистов.
  • Ну и самый основной вопрос – это то, что поддержка технологии In-Memory OLTP на данный момент в платформе отсутствует, и в этом плане можно только смотреть в сторону фирмы 1С. По крайней мере, я надеюсь, что они хорошо отреагируют на появление возможности использования этой технологии в рамках платформы.

*****************

Приглашаем вас на новую конференцию INFOSTART EVENT 2016 DEVELOPER.

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Alexander Speshilov (speshuric) 20.09.16 13:12
Не применительно к 1С, а вообще, моё ИМХО. InMemory OLTP пока слишком хлопотная и молодая техника, которую имеет смысл применять ОЧЕНЬ точечно: а) она "плывёт" пока от версии к версии, слишком много ограничений, слишком много специфики.
Зато Delayed Transaction Durability может существенно помочь (если есть возможность принять соответствующие риски). Плюс в том, что можно обойтись вообще без изменений логики. Если у вас основные тормоза на WRITELOG и они не устранимы переконфигурированием структуры хранения, если при этом потеря последних нескольких транзакций несущественна (например, есть возможность снова их прокрутить/перепровести/перезагрузить или бизнес принимает риск потери данных при полном отказе сервера в пару минут - на самом деле для относительно небольших систем это типично). То в этих условиях Delayed Transaction Durability может дать хороший прирост, а главное, без увеличения стоимости сопровождения и без дополнительной разработки. Но, конечно, это не 30-100 раз, как InMemory OLTP.
2. Михаил Максимов (МихаилМ) 20.09.16 16:10
1с индустрии проблема квалифицированных кадров. всегда 1 вопрос: @а кто будет поддерживать это чудо когда, когда уйдет мега гений".
3. Alexander Speshilov (speshuric) 20.09.16 20:42
(2) Именно в InMemory OLTP вопрос даже не в этом. 1С для своих таблиц не предполагает и не поддерживает использование in memory. Как минимум из этого следует необходимость работы прямыми запросами, сложности при реструктуризации и вообще геморрой с обслуживанием и хождение по граблям. Для этих таблиц и native compiled процедур есть гора ограничений:
  • Редакция SQL - Enterprise 64-bit (для 20-ядерного сервера это порядка 7 млн руб).
  • Куча неподдерживаемых моментов со стороны SQL: https://msdn.microsoft.com/en-us/library/dn246937(v=sql.130).aspx
  • В том числе нет кластеризованных индексов (не нужны). Первичный ключ только в виде хэш-индекса. Это достаточно специфичная штука. Уникальных индексов нет (по крайней мере в 2014).
  • Жёсткие требования по памяти (снизу - объём таблиц, сверху - 250 ГБ) и требование удвоенного дискового пространства. https://msdn.microsoft.com/en-us/library/dn170449(v=sql.130).aspx
  • И еще куча всего, можно начать читать тут: https://www.brentozar.com/blitz/hekaton-memory-oltp-tables-use/
В общем, если решение не на 1С и есть пара таблиц, которые направшиваются (явное продиагностированное узкое место, которое лечится in-memory OLTP), область общения с этими таблицами ограничена и есть вменяемый DBA, то можно использовать (особенно для промежуточных расчетов).
Короче, мощная, но капризная высокоточная снайперская винтовка, требующая высококлассных специалистов и немалых затрат на обслуживание.
Незаменима для определённого класса задач (например обработка более 1000 событий в секунду и онлайн-аналитика по ним), но для 1С как-то слишком хлопотно.

С другой стороны - за темой in-memory реально будущее. MS SQL Server, SAP Hana, Oracle Database In-Memory - все они прорабатывают эту тему. В in-memory существенно отличаются подходы к обработке данных по сравнению с классическими "дисковыми" РСУБД (активное использование хэш-индексов, колоночных индексов), к обеспечению ACID. До вендоров коробочных массовых решений это доползет лишь через несколько лет.
4. Сергей (Sybr) 21.09.16 09:32
Из статьи я так и не понял, как выглядит работа с OLTP базой со стороны 1С, нужно подключаться напрямую через ADO и получать данные нативными SQL запросами?
5. bulpi bulpi (bulpi) 21.09.16 12:29
"Горе от ума" (с) Грибоедов.
Написать толковую конфигурацию вместо типовой не пробовали ? Ну хоть раз в жизни ?
6. Александр Хомяк (logarifm) 22.09.16 11:23
Очень много безмысленных картинок, Тренды шменды. еле дочитал!
swimdog; Sheff; +2 Ответить
7. Александр Хомяк (logarifm) 22.09.16 11:28
(3) speshuric, еще забыл уточнить, прямые запросе ВНЕ 1С это нарушение лицензионного соглашения целестности данных.
8. Алексей Шардаков (IB0P0HI) 22.09.16 16:16
(7) logarifm,
Запросы только на запись? Если дамп или копирования таблицы типа справочника(ну пусть номенклатура) в свою сторонню БД средствами SQL сервера не думаю что нарушил. Тут идет чтение и права на уровне БД(потому как то же самое можно регламентным заданием сделать - но увы на больших табличка SQL нативный будет в разы шустрее.

9. Геннадий Николаев (genayo) 23.09.16 12:01
(7) Есть хотябы один пример, когда за это у нарушителей были хоть малейшие проблемы с 1С?
10. Руслан Хитров (Sheff) 26.09.16 16:04
11. Михаил Максимов (МихаилМ) 27.09.16 12:30
(9) genayo, есть один.
были у софтпоинта проблемы с 1с.
12. Алексей Белый (mrstomak) 04.10.16 10:48
Статья вызвала удивление.
Если мы переносим бизнес-логику на SQL-сервер, то мы вообще-то теряем те самые управляемые блокировки платформы, т.к. они реализованы на уровне сервера приложений.
Потому что бизнес-логика в ряде мест не укладывается в пресловутый Read Committed.

Описанное преимущество "мультиверсионности" и отсутствия необходимости в блокировках не выдерживает критики - СУБД-версионники существуют десятки лет, Read Committed Snapshot для MS SQL поддерживается начиная с 8.3, но когда ты контролируешь остатки, распределяешь партии или взаиморасчеты, концепция "версий" не обеспечивает целостности данных, т.к. недопустимо, чтобы каждый поток видел свою "версию" остатков - здесь бизнес-логика требует видеть реальный остаток именно сейчас. Именно для этого и используются управляемые блокировки, "дополняющие" используемый уровень изоляции СУБД (Да даже в автоматическом режиме с Serializable на регистрах нужно было хинтить for update!).

Показанные замеры с переносом логики в ХП SQL не имеют смысла, если потеряна поддержка управляемых блокировок - потому что очевидно, что при контроле остатков, задержка была именно в ожидании установки блокировки!

Не совсем ясно, как вообще выполняются ХП? откуда берется код? Вот платформа проверяет наличие записей в регистре, проверяет его настройки по метаданным, пишет со сплиттером или без, с учетом разделителя данных в multitanancy и в определенном порядке, добавляет условия RLS,обновляет таблицу итогов - это всё помимо управляемых блокировок. Неужто всё это перенесено на уровень SQL и учтено в замерах?

Ответ на вопрос "директора" есть на ИТС, ИС, Мисте, где угодно, странно видеть это основанием к подобному исследованию.
13. Sergey Andreev (starik-2005) 27.10.16 14:33
Смысл статьи в том, что нужно отказаться от 1С в плане реализации бизнес-логики и написать ее на чем-нибудь вменяемом, а в 1С реализовать выгрузку для отчетности регуляторам и, возможно, ведение операций банка и кассы.

1С в принципе не заточена под высокую нагрузку - она просто не умеет. Скорость интерпретатора весьма низкая, эффективность кода на языке никакая, методов оптимизации кода на 1С почти нет - даже утилиты анализа кода на 1С - это редкая штука за какие-то деньги с никаким качеством анализа и минимумом советов по улучшению.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа