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

Хочу уточнить. Как работает клиентский кэш в данном случае?
То есть что помещается в клиентский кэш при запуске ИБ на рабочей станции?

Спрашиваю, потому что порой трафик зашкаливает на рабочие станции с сервера. И соответственно, имеют место огромные тормоза как при запуске, так и при работе.

Варианты оптимизации имеются, но насколько они будут действенны, смогу для себя решить только тогда, когда узнаю, как работает кэш на 8.2 (база файловая, обычное приложение, количество пользователей 3-6, размер базы 4 гига за счет изображений - и это не предел).

А, блеа, забыл, всех с Новым Годом и бабла побольше))

Ниче не поможет.

Уменьшайте изображения (за счет качества, разрешения).

(0) терминал

Погодь, я туплю.
Файловая по сети?
Тут не в картинках проблема, вернее в них тоже.

1) Перейти на клиент-серверную.
2) Перейти на терминал
3) Перейти на вебсервер и УФ.

Серверная стала тупить в два раза больше

Это уменьшит траффик, но не за счет картинок, а за счет работы с данными которые не картинки.
В случае с терминалом - вообще монопенисуально, есть там картинки или нет.

(6) что за конфигурация?

(6) Скорее всего - серверная пытается поток данных сжать, думается что deflate-ом, который вполне бесполезен для уже сжатых картинок (jpg к примеру), но время отнимает для больших данных.

(0) удалить картинки, 1с здесь не причем.
Для ускорения можно поставить винты пошустрее и 2-4 канала(сетевых карты) оптикой с сервера к маршрутизатору

Какие у меня мысли.

Если я пойму, как работает кэш, тогда можно будет выбирать.

Сейчас ситуация такая.
Конфа самописная.
Хранение изображений сводится к хранению двоичных данных в реквизитах ХранилищеЗначения в табличной части каждого элемента справочника.

Если я организую хранение картинок по-человечески, в одном справочнике, а в тч помещу ссылки (т.о. так, как в ЗУПе например). Как будет работать кэш?

бестолково. в этом релизе кэш работает так, а в следующем сяк. не вариант

(10) лезвие не XEONах, 16ГБ оперы, RAID10 SATA II.

Да при чем тут кеш?
Если все грузится одной перекачкой картинок.
Лучше уж тогда создай каждому пользователю по РИБ локальную

с железом нет проблем

(14) не смешно

сеть какая от сервера к маршрутизатору?

кстати, кэш можно организовать самому. вот это вариант. локальное файловое хранилище на клиенте + md5, при условии, конечно, что требования безопасности это позволяют

(12)

реквизитах ХранилищеЗначения в табличной части каждого элемента справочника.

КАКОГО справочника то?
Учитесь свои проблемы формировать правильно.

(12) Вот я и прошу объяснить, как он в принципе работает? каким образом кэшируются объекты, что попадает в КЭШ из данных?

(18) Захватить картинку для редактирования, отпустить картинку в базу. Так?
Не сильно муторно и ненужно?

(19) -> (11)

(18) Кстати да, картинки из 1С убрать, оставить только пути, и всем на комп картинки скопировать и синхронизировать в станд.путь

(19) Справочник Справочник1, у него есть тч ТабличнаяЧасть1, у нее есть реквизит Реквизит1 с типом ХранилищеЗначения, куда фигачится картинка.

(23) И руки оторвать.

(24) Где тормоза возникают, в какой момент?

Запуск ИБ, отборы

надо отойти, 15 минут, мужики, буду признателен за любой совет.

(24) Какой смысл у этого справочника.

Ты не теории тут давай, ты конкретно практику.

"У меня при работе со справочником Серии номенклатуры возникают тормоза"

(27) Это ИМЕННО проблема "файловая, по сети, несколько пользователей". В поиск, это с 2003 года трется.

Все варианты в (5).

(21) ну, типа, при записи элемента спр. пишем картинку + md5. на клиенте, перед тем, как считываем - смотрим в локальном хранилище по GUID - если ли уже такая, и совпадает ли md5. если есть - грузим её, если нет, стягиваем с сервера, ложим локально картинку и её md5

+(31) если безопасность жмёт, можно локальные базы натянуть на всех клиентосов, например, на mysql

(31) Долго и лениво. Да и не потянет автор скорее всего.

(32) Бугага.

Даже я бы такое делать не стал. Нуегона, пусть медленней, зато без геммора и надежнее.

Единственное - какойнибудь электронный документообормот сканов документов, специализированное че.

ну да, гемору много.

как вариант, на серваке заюзать SSD-диск + ЧАСТЫЕ бэкапы

(36) И ты Брут.
Проблема с изображениями - это проблема с сетью.
но у автора скорее всего не то.
У него - "файловая, по сети, несколько пользователей", связано не с изображениями, а с особенностью кэширования сетевых файлов в WinNT

(37) кто сказал, что именно с сетью? где это доказано?
а я вот подозреваю RAID10. даже на 100 мегабитах скорость закачки файлов очень приличная, а если ещё на серваке 1 гигабит, то вообще эту сторону можно откинуть

(39) это не доказательство.

вот просто ради прикола можно попробовать разместить временно копию БД на компе с SAS, или, на худой конец, SATA диском вне рэйда, и посмотреть, как это скажется на производительности сабжевой нетленки

100 мб / 5 юзеров = 20мбит (маловато будет)
1Гбит/с / 5 = 200Мбит/с = 25Мб/сек (уже более-менее)

Тем более что базу в 4гб, сервак должен! кешнуть в память.

Хотя интересно сколько одна картинка вести у ТС? може юзери сканы по 100мб bmp-шные вносят :)))

Ради интереса почитайте

http://www.1c-pro.ru/index.php?showtopic=16176

Не могу найти развернутый ответ, был на хабре, тот же Пит (Улю427) в 2003 году на мисте писал развернуто.

кстати, а автор не боится с таким числом изображений на файловой работать?

и ещё вопрос: дисковый кэш включен?

(11) ...Хранение изображений сводится к хранению двоичных данных в реквизитах ХранилищеЗначения в табличной части каждого элемента справочника. ...

Тут зло!

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

всё-таки, дисковую систему тоже стоит посмотреть поподробнее.
что за контроллер, чей кэш (контроллера или винды) задействован, и задействован ли вообще.

и не стоит забывать, что отдельный диск вне рэйда всегда будет работать быстрее, чем рэйд.

но лично я бы, для начала, загнал всех в терминал

Какая разница какой справочник, я не могу понять?

Справочник Номенклатура, в табличной части хранятся 100 изображений этой номенклатуры.

Никакого редактирования не выполняется.
Просто просмотр.

Тормоза при запуске базы, отборах.

При открытии в режиме рабочего стола разворачивается форма этого справочника с определенным отбором.

Я думаю, что тормоза вызваны тем, что кэшируется этот справочник со всем его содержимым в виде картинок.

Если картинки вынести в отдельный справочник, в этот поместить ссылки, то как поведет себя кэш?

Конечно, вариант с хранением картинок вне базы хорош, это был второй вариант решения проблемы.

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

Я просто еще не пробовал сделать, нет пока возможности, клиенты на каникулах.
Думал, кто-то может конкретно обрисовать суть работы кэша.

(46) Да вроде не считывается весь объект при работе в форме списка.
1) Убрать эту формы с раб. стола и посмотреть быстродействие
2) Профайлером глянуть запрос в SQL в клиент -серверном и все встанет на свои места.

(46) Но вообще хранить ХЗ в тч. номенклатуры - зло.
Храни в отдельном регистре, либо справочнике.

(47) спасибо