Может я не нов но вот что подумалось..
Уже пол года бьемся над увеличением скорости работы базы.
Примерно 70 пользователей, 5 on-line касс, база SQL, все модули проведения переписаны под прямые запросы...

Возник ряд идей:
1. Вынести все расчеты итогов и их обработку из модуля документа в модуль формы или куда-то еще... Результаты расчета в виде таблицы передавать в процедуру Провести(<ТаблицаДвижений>), в которой осуществлять только запись в базу.
Проблемы: Актуальность расчета. Думаю победить с помощью флагов или каких нибудь признаков.
Для каждого документа задать перечень зависимых регистров, и если в зависимых регистрах во время расчета таблицы движений были какие то изменения - (а это мы узнаем по флагам), перезаполним таблицу движений и повторим всё заново.
Плюсы: При проведении независимых документов будет достигнут эффект "паралелизма", т.к. запись в базу уже подготовленных движений- дело мгновенное и вылетов "блокировок" не будет. "Маленькие документы"(обычно чеки) будут проводится быстрее больших и тяжелых.
Минусы: При стечении обстоятельств возможен не однократный расчет итогов для тяжелых документов. Но это и не страшно...
2. Проведение документов производить не на локальной машине а на выделенном сервере. Реализовать систему приоритетов. Например Документ "Чек" должен иметь наивысший приоритет, а "Отчет филиала" с несколькими тысячами строк - самый низкий. При нажатии кнопочки "Провести", документ ставится в очередь на сервере, порядок в очереди выстраивается в соответствии с приоритетом документов. Думаю реализовать это при помощи TCP сервера и асинхронных событий...

Прошу поделится своими соображениями на этот счет..

Очень интересный ряд идей!
А если программное проведение, групповое перепроведение?
Что значит независимые документы в контексте _1sjourn? 

(0) (Ихмо) Абсолютно неправильная постановка задачи.
На кассах должен быть back office. В конце дня переносите данные
в учетную программу.
Скажи что будешь делать сейчас с кассами если сломается сервер и/или сетевое оборудование  часа на 3-4.
Опять же из-за блокирок долгое проведение чека - неприемлеммо долго для ПОКУПАТЕЛЯ.
А если кто-то днем запустит суперсложный отчет  или перепроведение прошлых документов - кассы вообще умрут ( тем более 70 пользователей ).
Если Вам все же необходим кассовый online то все равно это должна быть отдельная программа ( не 1с ) - либо ищите готовое, либо напишите что-то свое.

Roman писал(а) 22. Июня 2007 :: 15:03:


В таком случае НАВЕРНОЕ применима схема разделения оплаты и отгрузки

1. Продажа (менеджер) - Основная функция в базе - Подбор товара в заказы, документы продажи и т.д.
2. Оплата (Кассир) - Основная функция в базе фиксация принятых денег от покупателя за конкретный товар оформленный менеджером...

Ну тогда у тебя все равно торговый зал это отдельный склад.
Выписывай счет и счет резервирует товар по складу торговый зал.
К счету кассир привязывает приходнокассовый ордер ( чек ) - только деньги от Клиента и
никакого рассчета остатков товара.
Кладовщик привязывает к счету Расходную накладную ( которая отменяет резерв ).
Основная мысль кассир отвечает только за деньги.
Кладовщик только за товар.

Насчет Идеи 2:

1. Многие работаю в терминале, так что ВыполнитьНаСервере(), не так актуально... а вот приоритеты - мысль интересная.

PS Интересно как с блокировками борется Phoenix при его то 800-ах пользователях.

lustin писал(а) 22. Июня 2007 :: 15:22:


а никогда не задумывались почему в 1С не так все устроено?

Pelmen писал(а) 22. Июня 2007 :: 15:37:


Очень даже задумывались... А что ты прикажешь делать? Какие ты видишь методы оптимизации проведения?

1. Либо Готовить ТаблицуПроведения до ОбработкиПроведения
2. Либо изменять структуру Регистров, так чтобы алгоритм построения вышеуказанной таблицы занимало как можно меньше времени, соответственно и алгоритм оптимизировать тоже.

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

Тут однозначно, лично я еще не знаю всех возможных вариантов.

P.S. Мне на днях предложили воспользоваться платной компонентой которая
- борется с ситуацией бесконечного цикла в момент одновременного проведения.
- выставляет приоритеты на процессы 1С, которые схватили "блокировку"
- организует автообмен через cокеты между базами в рамках локальной сети.
Стоимостью 18.000 рублей 9000 рублей с документацией и закрытым программным кодом.
Называется компонента  msmail1c.dll, но мне стало как то подозрительно... и я отказался с ней работать.