Отцы, такой вопрос.
Есть файловая типовая УНФ, в которой работает 16 человек
Все бы ничего, но периодически бывают тормоза, когда документ открывается по минуте
Сделал замер производительности, вот результат: http://prntscr.com/sndjs8
Вот запрос, который 26 секунд выполнялся: http://prntscr.com/sndkao
Я бы понял, если бы проблема была в записи данных в базу, все-таки файловая и 16 человек. Но тут то получение данных простым запросом. Поможет ли тут переход на клиент-сервер? Есть ли способ ускорить выполнение запросов "малой кровью"?

(0) говорят что если файловую опубликовать и работать через "веб" то будет лучше

Файловая через сеть? Переходи на веб-сервер.

(0) ну и цифры без конфиги железа - ни о чем, может таам у вас целерон300 с 512 Мб памяти

(1) клиент-сервер для бедных :)

(2) через РДП, ога
(1) Спасибо, надо попробовать
(3) http://prntscr.com/sndnkx

(4) потому что пишут код платформы с туевой хучей ненужной хрени, наверняка. всяких ооп. кучей библиотек и прочей хрени где а+б выполняется наверное через копенгаген в ротердам.

(6) Это общий тренд. Числодробилки, именуемые компьютерами, должны справляться.

Нагрузка: http://prntscr.com/sndpmy
http://prntscr.com/sndpyi

В общем, веб, если не поможет, то клиент сервер. Спасибо!

(9) в догонку http://catalog.mista.ru/public/239498/

(10) Эту ссылку я дам админу, так не на 1Сном языке :)

на 16 пользователей - однозначно клиент сервер...

даже на 2...3  пользователя и то клиент сервер нужен (минисервер на 5 юзеров).

проблема в том, что файл базы ОДИН, и в нем системная область где размещены указатели на страницы с данными блокируется вся целиком при ЛЮБОЙ записи в базу, и текущие конфы постоянно чего-то пишут, версии, нумераторы, настройки и т.д.

файловая база реально только в монопольном режиме шустро работает, все остальное только клиент сервер.

откуда инфа про блокировку базы?
вроде табличная блокировка

(0) 16 человек на сундук мертвеца в файловой ?
как же он у вас в очистке работал? ....

>> файловая... 16 человек
дальше мог бы не продолжать
то, что есть 1С-севрер МИНИ на 5 подключений - уже одно это должно натолкнуть на определенные мысли

(13) корневая root область блокируется всегда при добавлении или освобождении одной страницы в базе. Кроме того механизм транзакций в 1с построен то-же на страничной модели (то есть делаются копии страниц а потом при фиксации записывается несколько байт в root области), так вот на время транзакции то-же блокируется root области таблиц (это и есть блокировка таблицы), но если таблице нужно добавить страниц - блокируется вся база

(15) Если эти 16 человек неспешно заносят полтора документа в час, а остальное время пьют чай и изредка сформируют какой-нибудь отчетец..

(0) запрос переписать ещё не предлагали?
он конечно работает, но мягко говоря неоптимально.

(0)
публикуйте через веб
если лучше не будет (что вполне вероятно при 16 пользователях), то вариант:
1. Переход на клиент-сервер (рекомендуется от 8-10 пользователей)
2. Сделать вручную несколько публикаций (5-10) и раздать каждому пользователю "свою" ссылку. Не рекомендуется, так как геморрой с поддержкой, да и не факт что будет быстрее.
3. Попробовать "автономный сервер 1С" - это бесплатное серверное приложение, "умеющее" в файловую базу, но при этом не требует сервер 1С. Не рекомендуется, так как бета-версия)

(19) 3. для автономного сервера вроде лицензия нужна при более 3 соединениях. Зачем этот фрукт нужен до сих пор не понял.

(20)
да точно, нужна серверная лицензия. Тогда п.3 не подходит.

Проверь, индексируемое ли поле "Контакт", например.

(20) домашний клиент-сервер для разработчиков, например.

Господа, спасибо за советы, но УНФ полностью типовая, я не хочу там переписывать запросы или добавлять индексацию полей. Правильно, все же, будет купить клиент-сервер, если публикация не поможет. Это, с перспективой обновлений, дешевле, чем обновлять дописанную (пусть даже через расширение) конфигурацию

(0) RLS есть?

(25) точно не скажу пока, доступа нет. РЛС в файловой базе как-то особенно тормозит?

(26) То, что на SQL требует 1 секунду, в файловой может минут на 15 подвесить.

(27) благодарю. Тут отключать РЛС не вариант, так что буду придерживаться ранее озвученного плана)

РЛС на файловой? Извините, коллеги, вы у психиатра давно были?

(23) Это практика или предположение?
Там столько ограничений, что имхо как раз для разработки он крайне не удобен.

(30) непреодолимых ограничений вроде нет? благо до практики дело не дошло, но как резервный план вполне.