Я про то, что в статье - про PostgreSQL. А изменение "Оптимизирована очистка временных таблиц в MS SQL Server в условиях высокой нагрузки" - оно про MS SQL Server.
Статья на официальном сайте датирована февралём 2025 года. Что-то с тех пор принципиально поменялось, почему на Хабре материал был опубликован в июле 2025 года?
Потребовалось время для подготовки статьи и для принятия принципиального решения - какие именно детали будем публиковать "наружу". Пресс-релиз о результатах - это одно, статья на Хабре - совсем другое)
Релизы СУБД и платформы 1С с анонсированными изменениями были опубликованы с тех пор в общий доступ?
Что значит не содержат сложных инструкций? Небольшой SELECT с нескольким количеством JOIN'ов и парой выражений уже вполне сложная конструкция.
Конечно, сама по себе операция SELECT невероятно сложна. Но ядро СУБД, выполняя операцию SELECT, оперирует машинными инструкциями x64. При компиляции исходного кода в машинные инструкции "мощные CISC" инструкции практически не используются. Большинство имеют полный аналог в ARM и реализуются одной-двумя RISC инструкциями.
так как вы тем самым жертвуете временем отклика
Верно, время отклика при небольшой нагрузке будет больше. Однако, уже при средней нагрузке ситуация обратная - на ARM время отклика возрастает несильно, а вот на x64 сильно и быстро превосходит таковое у ARM.
С точки зрения архитектуры, теоретически, RISC будет лучше. В СУБД все операции на OLTP не содержат сложных конструкций, поэтому выигрыша от сложных CISC инструкций нет, их попросту негде применять. Плюс у RISC лучше энергопотребление, что позволит работать на бОльшей частоте.
На практике имея то что производят, конечно, мощный EPYC уделает этот процессор (возможно даже в разы) на однопоточных нагрузках. А вот при масштабировании ARM выигрывает с ещё большим отрывом.
Поэтому для 30к обычных пользователей мы выбрали ARM. Но да, для 16 "одарённых" пользователей мы однозначно бы остались на x86.
Как показали исследования, СУБД не имеет особого выигрыша от "мощной" CISC архитектуры x86. Простая RISC выигрывала за счёт большего количества ядер в процессоре.
В ходе тестов мы использовали наиболее типичные для предприятий сценарии, реализующие разные типы нагрузки.
30 000 одновременно активных пользователей
Время работы теста: 10 часов
Количество выполненных операций: 885 000
А можете уточнить - это как ? Каждый "пользователь" выполнил всего 30 операций за 10 часов ? Это какие-то ленивые пользователи ? Или что подразумевается под операцией ?
Мы исходили из требуемого количества введенных данных за время теста, а не из того, сколько операций должен выполнить каждый пользователь.
В реальной жизни, существенная часть пользователей, выполняет небольшое число операций в день (открыть отчет, посмотреть).
Другие вводят много документов.
Мы взяли текущие данные по количеству объектов (документов\справочников\...) в базе и посчитали, сколько их должно быть введено за 1 день.
Примерно прикинули сколько отчетов\обработок запускают пользователи за день. Получились такие числа.
Тест не жестко фиксированный, в нем можно менять интенсивность работы пользователей. Если хотите сделать более интенсивным - пожалуйста. Ссылка на базу теста доступна тем, кто купил 1С:ERP.
Сколько они документов провели ? Там у Вас 9 млн документов - это было до начала теста, или создалось за весь тест ?
9 млн документов – до начала теста.
Проведено документов за тест 136 000
Для сравнения у нас в lsFusion ERP есть сейчас клиенты (с 2К одновременно работающих реальных, а не "виртуальных" пользователей) вот с таким количеством записей в таблицах (и там только документов приобретение товаров и услуг - где-то 15 млн)
Коллеги, мы очень рады, что у вашего продукта хорошая производительность на больших объемах. Приходите конкурировать! Будем улучшать наши продукты в ходе конкуренции.
2.Цитата: "В качестве опорной точки в Apdex выступает целевое (желаемое) время выполнения ключевых операций (это время назначается экспертным путём)" - можно ли уточнить: что ещё за "экспертный путь" такой и как это соотносится с реальными скоростями выполнения самых распространенных задач (проведение документов, создание отчётов)?
Могу ответить так Если у вас есть доступ к 1С.ИТС - то есть статья от 1С более подробная.
А что мешало просто сделать master-slave логическую репликацию
Чтобы не усложнять настройку.
зачем делать многие вещи на уровне PostgreSQL
Чем "ниже" по цепочке клиент-сервер приложений-СУБД делаются оптимизации - тем оптимальнее (извините за тавтологию). Если можно сделать оптимизацию на финальном уровне трехзвенки - СУБД - лучше сделать её там, а не на уровне сервера приложений или тем более на уровне клиента. На мой взгляд, это очевидно.
если потом собираетесь это в основную ветку PostgreSQL залить, но что-то мне подсказывает, что вряд ли такие коммиты туда пройдут.
У нас своя версия PostgreSQL от 1С. Мы не планируем вливать наши правки в основную ветку PostgreSQL .
То, что ip адрес один и тот же - значения не имеет: с точки зрения сервера - клиенты разные, т.к. клиенты адресуются по паре ip-адрес + порт, а порты разные; с точки зрения клиента - на тестах упираемся не в производительность стека tcp/ip, и даже не в пропускную способность сети, а в первую очередь в память и cpu.
Я про то, что в статье - про PostgreSQL.
А изменение "Оптимизирована очистка временных таблиц в MS SQL Server в условиях высокой нагрузки" - оно про MS SQL Server.
Если "в MS SQL Server" - то очевидно не оно.
Потребовалось время для подготовки статьи и для принятия принципиального решения - какие именно детали будем публиковать "наружу".
Пресс-релиз о результатах - это одно, статья на Хабре - совсем другое)
Пока нет, об этом напишем дополнительно.
Конечно, сама по себе операция SELECT невероятно сложна. Но ядро СУБД, выполняя операцию SELECT, оперирует машинными инструкциями x64. При компиляции исходного кода в машинные инструкции "мощные CISC" инструкции практически не используются. Большинство имеют полный аналог в ARM и реализуются одной-двумя RISC инструкциями.
Верно, время отклика при небольшой нагрузке будет больше. Однако, уже при средней нагрузке ситуация обратная - на ARM время отклика возрастает несильно, а вот на x64 сильно и быстро превосходит таковое у ARM.
С точки зрения архитектуры, теоретически, RISC будет лучше. В СУБД все операции на OLTP не содержат сложных конструкций, поэтому выигрыша от сложных CISC инструкций нет, их попросту негде применять. Плюс у RISC лучше энергопотребление, что позволит работать на бОльшей частоте.
На практике имея то что производят, конечно, мощный EPYC уделает этот процессор (возможно даже в разы) на однопоточных нагрузках. А вот при масштабировании ARM выигрывает с ещё большим отрывом.
Поэтому для 30к обычных пользователей мы выбрали ARM.
Но да, для 16 "одарённых" пользователей мы однозначно бы остались на x86.
Как показали исследования, СУБД не имеет особого выигрыша от "мощной" CISC архитектуры x86. Простая RISC выигрывала за счёт большего количества ядер в процессоре.
Официальная новость от 1С.
Тест проводился на платформах 8.5.2 и на специальной сборке платформы 8.3.27. Все изменения, сделанные в платформе, войдут в релиз 8.5.2.
Не замеряли.
Мы тестируем не в попугаях, а в Apdex, Apdex – стандарт индустрии.
В ходе тестов мы использовали наиболее типичные для предприятий сценарии, реализующие разные типы нагрузки.
Мы исходили из требуемого количества введенных данных за время теста, а не из того, сколько операций должен выполнить каждый пользователь.
В реальной жизни, существенная часть пользователей, выполняет небольшое число операций в день (открыть отчет, посмотреть).
Другие вводят много документов.
Мы взяли текущие данные по количеству объектов (документов\справочников\...) в базе и посчитали, сколько их должно быть введено за 1 день.
Примерно прикинули сколько отчетов\обработок запускают пользователи за день. Получились такие числа.
Тест не жестко фиксированный, в нем можно менять интенсивность работы пользователей. Если хотите сделать более интенсивным - пожалуйста. Ссылка на базу теста доступна тем, кто купил 1С:ERP.
9 млн документов – до начала теста.
Проведено документов за тест 136 000
Коллеги, мы очень рады, что у вашего продукта хорошая производительность на больших объемах.
Приходите конкурировать!
Будем улучшать наши продукты в ходе конкуренции.
Могу ответить так
Если у вас есть доступ к 1С.ИТС - то есть статья от 1С более подробная.
Чтобы не усложнять настройку.
Чем "ниже" по цепочке клиент-сервер приложений-СУБД делаются оптимизации - тем оптимальнее (извините за тавтологию).
Если можно сделать оптимизацию на финальном уровне трехзвенки - СУБД - лучше сделать её там, а не на уровне сервера приложений или тем более на уровне клиента. На мой взгляд, это очевидно.
У нас своя версия PostgreSQL от 1С. Мы не планируем вливать наши правки в основную ветку PostgreSQL .
Запускаются тонкие клиенты, работают одновременно в одной терминальной сессии.
Тесты по такой методике проводятся уже много лет на проектах ЦКТП (https://v8.1c.ru/tekhnologii/tekhnologii-krupnykh-vnedreniy/tsentry-korporativnoy-tekhnologicheskoy-podderzhki-tsktp/) и показывают хорошие результаты, принципиальной разницы с реальными клиентами нет.
То, что ip адрес один и тот же - значения не имеет: с точки зрения сервера - клиенты разные, т.к. клиенты адресуются по паре ip-адрес + порт, а порты разные; с точки зрения клиента - на тестах упираемся не в производительность стека tcp/ip, и даже не в пропускную способность сети, а в первую очередь в память и cpu.
Так и задумано - чтобы читателю было видно, что раньше был спинлок.
Вы правы, у нас опечатка.
Поправили.
Спасибо!
Более подробная информация тянет на отдельную статью, как-нибудь подготовим.
На данный момент это можно делать только в поле HTML-документа.
А что вас конкретно интересует?
Архитектурно там всё так же как и в клиент-серверном варианте, с т.з. настроек тоже.
Ссылку на выступления пока не нашли :(
А информацию можно найти тут:
https://illmatics.com/Understanding_the_LFH.pdf
http://illmatics.com/Windows 8 Heap Internals.pdf
ERP - более 12 млн строк.
Сейчас поищем ссылку на доклад. Найдем - разместим здесь.
Довольно давно это было.