Тормоза реально есть. Проблема проявляется и на 8.3.22 и на 8.3.23. База файловая БП3, опубликованная через веб-сервер apache x64.

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

Тестовый пример - поиск ссылок на объект. Когда пользователь один, то первый поиск медленный, при этом видно через диспетчер задач, что идет плотное чтение с диска. При повторных запусках поиска диск не загружен, короткий пик загрузки процессора - и результат готов за секунду.

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

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

При запуске клиентов без веб-сервера, напрямую к файловой базе, та же самая ситуация. Как только появился второй подключившийся - всё, кэш аннулируется.
ф
Пока проблема решилась откатом на последнюю 8.3.21, там кэш чтения работает и при многопользовательском доступе.

Но непонятно, как с этим бороться дальше. Ведь рано или поздно придется повышать версию платформы без вариантов.

переходить на SQL

(1) Ну это очевидный ответ, он денег стоит, и бедным местным бюджетникам очень сложно их получить

Пользователям не надо искать ссылки по всей базе. Это должен делать отдельный процесс в фоновом режиме, ближе к серверу.

(3) Это просто тестовый пример, иллюстрирующий отключение кэша. Повторное обращение к одним и тем же данным - типичный сценарий. И если он замедляется, то замедляется вся работа в целом.

(4) Поиск ссылок на объект — это нетипичный пример. По сути, это скан всей базы.

(5) Интерактивная работа тоже ускорилась после отката на 21 версию, и нагрузка на диск снизилась на порядок.

(0) напрямую без Apache уже проверяли? Если быстро работает, то проверить на IIS если на Windows сервере.

(7) Да, при работе в обычном файловом режиме то же самое. Кэширование перестает работать при подключении второго клиента к базе. Даже локально, не по сети.

(0) Да это и на более старых версиях платформы было. Один пользователь на тех же сетевых дисках еще как-то работает. Заходит второй - и всё ложится.

(9) На сетевых да, было всегда - это особенность реализации SMB в винде. Речь сейчас о локальном доступе.

(10) Ну так унифицировали - не впервой же.

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

(12) попробуй Автономный сервер

по сути то же самое (веб-публикация по http), но внутри зайдествован кусок сервера1с

а причина то в чем?

Файлобазоюзеры должны страдать?)

(0) Кэширование чтения при современных SSD это глупость
Особенность новых платформ что там в случае веб-сервер файловый вариант оно в двух потоках (и более) работает а не в одном как ранее
Т.е. наоборот более приближено к сервер 1С

Так что ставим MSI SPATIUM M570 HS или хотя бы ADATA LEGEND 960 и вперед

(18)+ вот у меня raid0 на трех ADATA LEGEND 960 1Tb
https://i2.paste.pics/6286f852ae5a39f25a1da25a721203b4.png

(19) Все в режиме PCI 4.0 x 4 ? На какой материнке?

(17) А работе в нескольких потоках никак кэширование ОС не мешает, тем более, кэширование чтения. Если процесс обратился к блоку данных какого-то файла, то этот блок попадает в файловый кэш, и последующие к нему обращения уже не вызывают чтения с диска. Даже при конкурентном доступе разных приложений. Но приложение может использовать специальный флаг при открытии файла "не кэшировать", тогда системное кэширование отключается. Обычно это делают всякие торренты, чтобы не засорять кэш мусором при раздаче файлов. Но вот для 1с это явно вредительское решение. То есть, на ровном месте на порядок падает производительность.

(17) Т.е для веб сервера (iis) + файлового варианта базы будет ускорение в одновременной работе нескольких пользователей на новых платформах ?

(22) емнип, для файловой и на более старых было ускорение с веб-сервером

(20) да
мамка уже старенькая GIGABYTE Z690M AORUS ELITE AX DDR4

(22) должно, надо тестировать
там еще должны (не знаю сделали ли уже) место исполнения фоновых изменить для веб-сервер, файловый вариант

(19) Круто, чтение 80 метров в секунду на RND4K Q1T1, я предполагаю что это и есть типичная нагрузка чтения у 1с без кэша.

(26)Да, круто, хочешь Бухню на 5 юзеров чутка ускорить при помощи апача, собирай рейд из 3х SSD :)

(26) да ADATA LEGEND 960 не очень подходящие для RAID 0
там lba только 512 bytes, 4096(4k) нету
https://filers.blogspot.com/2018/12/how-to-format-nvme-drive.html

да и raid0 я сделал 16к

В (0) и сказано - вырубает кэш. На рам диске, представим что это примерно призводительность кэша, вместо 80мб/с, 2гб/с, или выше раз в цать.
Какого лешего при 2х пользовалятелях через одно соединение вэб-сервера дропается кэш?
Это действительно не нормально. Тут ssd не помогут, даже в рейде.

(28) Забудь ты про это, даже на hdd это все уже полная ерунда, а на sdd тем более.
Везде уже внутренняя трансляция неизвесно чего, неизвестно во что.
Если получится что-то подобрать с секторами с профитом в 5% то уже счастье.

P.S. По твоей ссылке написано 4к Best, что не так?

nvme id-ns /dev/nvme1n1 | grep LBA
LBA Format  0 : Metadata Size: 0   bytes - Data Size: 512 bytes - Relative Performance: 0x1 Better
LBA Format  1 : Metadata Size: 8   bytes - Data Size: 512 bytes - Relative Performance: 0x3 Degraded
LBA Format  2 : Metadata Size: 0   bytes - Data Size: 4096 bytes - Relative Performance: 0 Best  (in use)
LBA Format  3 : Metadata Size: 8   bytes - Data Size: 4096 bytes - Relative Performance: 0x2 Good
Explanation

Each format has an id: 0, 1, 2, 3 in this example.
There are two data sector sizes - 512 bytes and 4K. Typically the 4K formats provide the best performance and endurance.
Metadata - some drives provide the capability to add a few bytes for additional metadata for each sector. This is typically used for T10/DIF CRC.


(30) по ссылке есть выбор
на моих ADATA LEGEND 960 только одна строчка с 512

(31) Это без разницы, ssd всегда проиграют кэшу. На текущий сомент, если это не оптан, конечно...

(0)А что на счёт IIS? Тож самое?

(33) Думаю, разницы не будет, но я ИИС не пробовал, предпочитаю апач, который работает везде независимо от системы

(34)Я как-то давно юзал Апач, у меня он чёт подвисал, с ИИС проблем как-то меньше, да и работает мне кажется даже быстрее.