Здравствуйте.
Компьютер выделен под файловый сервер. Установлена Win 7 64 Pro (на нем установлена база ТиС, DBF). Имеются 5 рабочих станций, на них установлены Win XP и Win 7. Если в базу заходит один пользователь, даже в разделенном режиме, то всё работает отлично. Стоит другому пользователю зайти, как начинаются тормоза. Причем особенность... Тормоза начинаются если пользователь заходит в ту же базу. Если открывает другую, то проблем не возникает. Описание подобной проблемы было http://kb.mista.ru/article.php?id=136. Особенность в чем... Если пользователь открывает базу на одном компьютере (под разными пользователями), то тормозов не наблюдается. Если база открываются на разных компьютерах, то тормоза есть. Попробовал использовать программный кэш (как указано в статье) прироста скорости не заметил. На SQL переходить нет возможности, всё лицензионное. На терминал денюжки нет. Можно ли исправить ситуацию?

(202) "Могу вам еще десять раз скинуть цитату от 1С с советом использовать нетварь"(с)
Не надо. :-) Когда 1С писала этот совет, мне уже довелось работать с NetWare и клиентом для Windows. Дык, в нем и делают кэширование на стороне клиента при совместной работе с файлами. Работало не очень надежно. Но, быстро... :-)

(202) "Так как вы постоянно ссылаетесь на свой, абсолютно ненужный тест, я так понимаю что согласны."(с)
Очень странный вывод.
(203) "при таком сценарии возможно не отключится кеширование даже на клиенте"(с)
Точно! :-) Как я не догадался. А разное время выполнения теста в трех запусках мне привиделось. И я конечно забыл посмотреть объем переданной информации по сети.

P.S.
Зря Вы кипятитесь. Это мешает Вам думать. :-)

(207) hogik , вы умеете вести диалог? Вы так и не ответили на мой вопрос, насколько я понял что вы уже поняли что не правы, и начинаете вилять.

Давайте по пунктам. Один вопрос сейчас, остальные после того как я выложу ролик.

Вы согласны что при сетевом обращении на чтение к файлу в винде с двух клиентов, кэширование виндой на сервере этого файла отключится? Если нет, то ждем ролика, если да, то какого хрена несете чушь?

(207) "Вы так и не ответили на мой вопрос, насколько я понял что вы уже поняли что не правы, и начинаете вилять."(с)
Где Ваш вопрос?
Это:
"Так как вы постоянно ссылаетесь на свой, абсолютно ненужный тест, я так понимаю что согласны."(с)
Я на него уже ответил вежливо. Могу ответить грубее. :-)
И где Вы нашли моё виляние? Я продолжаю утверждать, что Вы заблуждаетесь. Попутно пытаюсь дать Вам информацию для размышления по ТЕХНИЧЕСКОМУ аспекту нашей беседы. Она до Вас не доходит. :-)

(209) На вопрос вы не будете отвечать? Еще раз его повторю.
hogik , Вы согласны что при сетевом обращении на чтение к файлу в винде с двух клиентов, кэширование виндой на сервере этого файла отключится? Да или нет? Хотя я уже понял что вы на него отвечать не будете, ибо знаете что неправы, и простейший ролик докажет вашу неправоту.

(210)
Я уже Вам сказал. Вы заблуждаетесь. Сказал это с первого сообщения данной темы.
И престаньте давит мне на глаз. :-)

(210)
Нет. Я Вас обманул - не с первого сообщения. С четвертого. Т.к. первые три Вы не осилили... :-)

(211) Заблуждаетесь - это да или нет? Насколько я понял вы так говорите нет, не согласны. Так вот, я выложу ролик, в котором в только что загруженной винде аналогичной (0) - Windows 7 pro x64 (для чистоты эксперимента), запущу диспетчер задач, подключусь двумя сетевыми клиентами, и буду читать один и тот-же файл. При этом значение "свободно" не уменьшится, а значение "кэшировано" не увеличится. После этого отключусь с обоих клиентов, подключусь одним, и поставлю тот-же файл на закачку, и естественно при этом значение "свободно" начнется уменьшаться согласно скаченному объему, а значение "кэшировано" соответственно увеличиваться. И так-же несмотря на повторное скачивание, файл будет читаться с диска. И посмотрим что вы на это скажете.

(213)
Блин. Ну, Вы чего? Посмотрите (145) сообщение. Там дан конкретный ответ.

(214) Ничего конкретного там нет.
Речь идет о двух видах кэширования - на клиенте, с которым вы согласны что он отключится, и виндовый на сервере, с которым вы не согласны. Все конечно не отключатся, ибо я неоднократно говорил что кэш жесткого диска естественно работать будет. Но уже почти 150 последних постов речь идет только о виндовом кэше на сервере.

Так вот - тест в (213) наглядно докажет что при доступе к файлу на чтение с двух клиентов виндовый кэш на сервере не работает.

(214) Ну так и скажи просто поговорить хочется :)
Это тему отключения кэширования уже обсасывали и пытались обойти (безрезультатно) уже больше 15 лет, нечего тут уже спорить по большому счету, все известно, все пути обхода известны, но коли у ТС нету денег на терминал (на 5 юзверей там получится то 10 тыщ наших рублей), то и денег на SSD у него тоже не будет, так как он тоже не меньше этих 10 тыщ стоит.

(217) ДБФ базы маленькие, а SSD на 64 гига со скоростями 500/500 стоят меньше 3 тыров рублей. И дбф база любая на такой SSD влезет с запасом.

(218) Ну чтобы получить 500/500 это как минимум SATA3 должен быть, а не факт что в сервере он есть, так что вероятно еще планка PCI-ная нужна с ним, да еще не факт что встанет, вообщем вопросов много :)

(215) "Ничего конкретного там нет."(с)
Чего у Вас с логикой? ;-)
Как я мог увидеть работает или не работает аппаратный кэш диска.
Моя фраза: "Во втором и третьем тесте обращения к HDD на сервере нетУ."(с).
Вы из этого можете сделать вывод, что я говорю НЕ о системном I/O кэше (в Вашей терминологии - "виндовый на сервере") ?

(219) Можно взять и медленней SATA2.
Для случайного доступа пакетами в 1Кбайт расчет был выше приведен.
Пусть есть HDD на 100 IOPs при таком пакете, и медленный SSD на 10000 IOPs. Суммарные задержки - сеть максимум 1мс (у меня такую задержку дает WiFi при 10 подключенных клиентах на пакете в 1024 байта). HDD 10мс. (кэш HDD при случайном доступе работать не будет, так как он в 100 раз меньше базы) SDD 0.1мс.
Итого задержки на случайном доступе с пакетом в 1024 байта HDD+сеть 11мс. SSD+сеть 1.1мс.

(220) Видео приведите, как после совместно чтения с двух клиентов файла с виндового сервера, при повторном чтении не идет обращения к диску. Я видео (213) вечером выложу.

(220) Жду кино. И покажите, что идут обращения к диску сервера при запуске двух читающих справочник сессий 1С-а. Ага? :-)

(206) "довелось работать с NetWare и клиентом для Windows. Дык, в нем и делают кэширование на стороне клиента при совместной работе с файлами. Работало не очень надежно."

Вообще удивительно, что оно в принципе работало. Первый клиент  хочет прочитать файла, и при этом не знает, что второй его уже изменил и на сервере уже лежат другие данные. Как при этом реализовать блокировку данных и транзакции? НИКАК! Единственным вариантом могут быть некие дополнительные расширения протокола работы с файлами по сети, когда клиент при изменении данных в файле анонсирует через сервер эти изменения всем остальным клиентам, у которых открыт этот же файл. Как минимум на уровне "файл изменен - кэш на чтение сбросить". Но тут получаем лишнюю нагрузку на сеть.. хотя, наверное нужна экспериментальная проверка.

Поэкспериментировал... Получил интересные результаты. ТиС, ведомость по контрагенту за месяц. В "монопольном режиме" 15 секунд, в "сетевом" (два пользователя):
- "без вмешательств" 90 секунд
- "RAMDisk", "SuperCache" 90 секунд
- "MS SQL" 75 секунд
- "DBEng32" 60 секунд

+(225) Попробую на РАМ перенести папки пользователей...

(225)
О чем и говорили.
Еще попробуй примитивный отчет на 1с++ FoxPro или sqlLite

(227) Ну так то тоже верно. NS не совсем прав, что от 1С++ не будет никакого толку. В частности, если знать, как работает запрос к регистру остатков и "Рассчитать регистры на", когда оно перекладывает данные из таблицы регистра в локальный каталог пользователя, а потом еще раз оттуда получает данные. И все это по тормозному каналу "с отключенным кэшем винды". Тогда как при нормальном запросе через 1С++ данные считаются лишь один раз в небольшом объеме.

(223) при чем тут 1с? при любом чтении.
(228) это не говорит о том что не надо решать возникшую проблему.

Хотя я увидел пост, где 1с++ в плюс к SSD имеется в виду - (38). Я его чесслово не видел :)

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

(229) Решать надо, решаться может по разному. Например у нас для старой базы NAS Synology немного поработал в качестве файлового сервера.
(230) ;-)

Да вроде каждый прав по своему.
способ 1 : Есть как бы путь улучшения сетевой файловой системы
способ 2 : это использовать 1с++ - уменьшаем колво (кардинально) передаваемых данных по сети и избавляемся
от лишних сортировок на клиенте.

Как бы можно использовать оба этих способа вместе или только один из них.

(231) а лучше отчет с большой выборкой (без запроса). так же одновременно.

А если поставить виртуальную машину и на неё положить базу?

(206) Основной совет всегда был отключать кэширование на клиентах NetWare (File Cache Level = 1) при открытии файла несколькими пользователями. В противном случае база просто умирала.

А выигрыш в производительности получали как раз за счет кэширования на сервере.

(237) А интересно, идею с синхронизированной иерархией клиентских кэшей в каком-нибудь протоколе доступа к файлам реализована?

(220) я смотрел твой тест. ИМХО, он некорректен для данной ситуации, так как у тебя последовательное подключение пользователей и чтение, а здесь разговор именно об одновременном.

(201) "во втором и третьем чтении обращений к серверу нетУ" - ну и неудивительно, работает локальный кэш на клиентской машине.

(238) Это как?

(241) это он имеет ввиду, наверное, механизм аналогичный которому реализован в DNS, когда повторный запрос на то же имя не уходит дальше кэша

(241) Чтобы кэширование на клиентах было, но при изменении файла одним клиентом сервер бы оповещал других клиентов об этом факте, чтобы те обнулили свои кэши для этого файла (или сегмента файла) как устаревшие. То есть, во взаимодействие клиента с сервером собственно чтению данных должен предшествовать запрос к серверу "данные модифицированы?", если ответ отрицательный - брать данные из кэша, если нет - получить их с сервера. Таким образом, на любом клиенте на момент выполнения запроса от прикладной программы кэш будет соответствовать данным на сервере.

(243) Так это и есть Oplocks level 2. Только в винде он отключается, а в нетвари, если включен - вызывает крах базы.

(225) а почему не хочешь dbnet попробовать? я сколько раз ставил - проблем не было, цена вопроса всего 1тр, до 3 пользователей вообще бесплатно

(244) "в нетвари, если включен - вызывает крах базы"
А почему?

В теории есть кеш на клиенте, с флагами об изменении.
Если версия файла неактуальна, то сетевой координатор обращается напрямую к виндовому кэшу, и только если файла там нет, то идет обращение к диску.
На практике, при совместном доступе и кэширование на клиенте, и кэширование серверной виндой отключается.

Я сейчас точно не вспомню при каких условиях кэширование на сервере отключается (при совместном доступе отключается просто гарантированно, но отключается и при других условиях), но прикол еще и в том, что пока клиенты не закроют файлы (а 1С держит файлы открытыми) кэш обратно не включается.

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

(246) Это уже слишком глубоко для меня. В 99-ом и 2000-ом был вал клиентов с умершими базами именно на нетвари с включенным level 2. В подробности никогда не вдавался. Только всегда знал что это нужно отключать.

+(225)
Установил "V7DBNet". Результат по скорости как в монопольном режиме :-) Вопрос только в покупке "лицензии".

(249) Кто-нибудь юзал V7DBNet - решает «проблема второго пользователя» в DBF базе
http://www.wirth.ru/forum/9-11-1
Если не вызывает смерти базы, то конечно это лучший вариант.

Интересно, как один из людей причастных (по его словам) к настолько крутой разработке, не в курсе даже общеизвестного глюка винды с кэшированием при двух сетевых обращениях к файлу?

(247) Теперь включается:
http://technet.microsoft.com/en-us/library/ff625695(v=ws.10).aspx
Теперь они придумали, что клиент может получать блокировки "в аренду", то есть на время, и попытки этого будут делаться перед обращением к каждому файлу.

Также, если ключи реестра, которые позволяют вообще отключить блокировку на клиенте (то есть, чтобы один работал как два).

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

Если у кого есть Windows 2012 server и клиенты на Windows 8, то можно попробовать включить SMB3.0 и посмотреть, что там реально изменилось (к сожалению, на более "мелких" версиях 3.0 не работает).

(252)  По тексту похоже что речь про запись, а не чтение.

(250)
Там же даже график показан честно
http://www.wirth.ru/publ/test_1_v7dbnet/1-1-0-1
с скллайт 10 сек супротив 196
Аналогичные будут и с фокспро
Правда непонятно зачем тогда   V7DBNet - и без него все хорошо

(254) Не совсем понимаю что ты имеешь в виду под фокспро. На сервер ставится СУБД подменяющая файловый доступ? Если не ставится, то не будет аналогичного результата.

+ (255) Ибо все проблемы с кэшированием вытекают из винды на сервере, и никакими изменениями клиента кардинально эти проблемы не решить.

(254)
Вы несколько о разном говорите.
Понятно, что если грамотно переделать запрос через фокс или sqlite, то выиграть можно много. Вопрос как оптимизировать работу, не изменяя базу и запросов.

(257) Речь идет естественно об ускорении без переписывания кода. Только установкой компонент. Иначе это слишком дорого в контексте (0).

(257)
У него автоматом переделывается ?

У Вирт ру

(44) если б не пробовал, не советовал бы.
набор софтин примерно такой:
FreeNX - сервер терминалов
Etersoft Wine - для работы 1С
Samba - в целом необязательный компонент. нужна только для типа выгружаемых из 1С документов.

(260) Ничего переписывать не надо насколько я понял.
Ставится на сервер СУБД, подменяющая файловую базу прокладка, и подменяются dll на клиенте. При этом с самой базой работает прокладка локально на сервере (при этом работает кэширование на сервере, так как нет сетевых подключений к файлам базы), и работает локальный кэш на клиенте.

То, чего установка 1С++ на клиенте естественно не сделает.

и да - 10-20 пользователей одновременно на обычной машинке с AMD Phenom x4, soft RAID-10, 6 GB. Вот как-то так оно и было

(258)
Тогда имхо, самое лучшее решение это поставить V7DBNet - уже ускорит и решит проблему второго пользователя. Другое решение - терминал. Но если делать по-честному, то дороговато. Третье решение - эксперементировать с другими серверными осями - NetWare, попробовать самбу линуксовую.
После выполнения одного из этих пунктов дальнейшего ускорения можно добиться, применяя 1С++, 1sqlite, FoxPro путем переписывания "узких" мест на прямые запросы.
Помимо этого, просто загрузка 1С++ уже несколько ускорит работу интерпретатора 1С, за счет включенной в него TurboBL и еще нескольких трюков.
Далее немного шаманства с каталогами юзеров на рамдрайвах.
После этого семерка превращается в убийственно скоростной болид. Однако рулить им смогут только шумахеры.
Для руления поможет накатить опенконф с плюшками, и заполировать TurboMD.

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

(265) Этого ничего не требуется. Достаточно связки SQL + терминал, и нормально переписать код без внешних компонент.

(259)
Там хитро и прозрачон перехватываются запросы движка 1С на работу с файлами, заменяя на свой механизм.
Так что ничего переписывать не надо, укололся и забылся.

(265) Samba почти никакого выигрыша не даст. пробовал. только сервер терминалов

+ к (265) А может ms sql exspress в качестве серверной оси?
но как бы из 0 не ясно какая 1с купленна.

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

(265)
Уважаемый orefkov, я вот заинтересовался использованием 1sqlite для 1Сv7, погуглил с целью найти какую-нибудь документацию и не нашел ничего, что помогло бы начать полноценное использование этой компоненты с нуля (есть отдельные статьи, на инфостарте пример отчета, но сложно понять принципы использования без вводной информации). Вы не подскажете, как лучше начать изучение компоненты 1sqlite? Возможно какие-то ссылки с описанием (кроме того, что выдает гугл), файлы с документацией и т.п.?

(271) doc.chm в архиве с вк, более чем достаточно.

(271)
Собственно, использование самой компоненты расписано в документации. Дальше надо просто разбираться в структуре данных семерки - что где лежит. Знать язык sql.
Ну и знать, что хочешь получить.
Да, так будет проще - поставить для начала конкретную задачу - сделать к примеру такой-то отчет, и с помощью мисты и форума 1С++ решать ее.

(273) Спасибо за ответ. Я изначально невнимательно просматривал сайт с компонентой и не заметил, что там есть файл с документацией. Начну с ее изучения.

ветку не читал, но осуждаю!(с) )))

а по теме, да - размещение базы, каталогов пользователей и tmp файлов на RAM диске + терминал = делают клюшки убийственно быстрой! лично экспериментировал с различными вариантами.
но для базы в продакшене это очень рискованный вариант.. RAM диск можно использовать для регламентных работ, например перепроведение или закрытие какого нибудь периода.. или для отчетов.. кактотак

..придешь бывало к клиенту, а восстановление последовательности в ТиСе может занять пару часов, а ты ррраз, и на нетбуке перепровел всю базу за 20 минут!))) это с выгрузкой/загрузкой..

на нетбуке у меня 16 Гб памяти, SSD и целерон 1.5

(221)
"Итого задержки на случайном доступе с пакетом в 1024 байта HDD+сеть 11мс. SSD+сеть 1.1мс."(с)

Подобные рассуждения не имеют никакого отношения к работе с DBF файлами по сети.
При отключенном кэшировании на стороне "клиента" (более одной сессии), для получения каждой записи таблицы по сети передаётся несколько пакетов в обе стороны. Кроме этого блоки индексного файла читаются многократно одни и те же. А еще и с эксклюзивной блокировкой всего файла на время поиска записи по ключу и при последовательном движении по индексу.
А с учетом латентности это делается со скоростью ниже 30 МБ/сек (для сеть 1Gb).
Именно уменьшением количества пакетов и увеличением их размера путем чтения файлов большими блоками достигается высокая скорость при выполнении запросов на FoxPro.

(272) который давно устарел, и там нет всех последних фишек

(277) Мы еще с кэшированием не разобрались.
Сейчас перекушу, и убедимся что вы как минимум четыре раза сказали чушь.

(227)
Не утруждайтесь. Ваш метода "поиска" кэша - полный бред.
Тестируйте, как я Вам сказал...

(280) -> (279)

(280) И что не так в этом методе? Когда повторное чтение опять читает с диска?

Правда сейчас в отличии от вчерашнего дня не вышло, первая попытка чтения одновременно с двух устройств закэшировалась.

(282)
А давайте заканчивать нашу беседу?
Мы изложили в теме свои противоположные мнения.
Пускай теперь другие специалисты делают выводы...

(283) У меня только что опять получилось прочитать без кэширования, сейчас еще раз попробую снять.

(283) Похоже ты прав. Используют фичу сетевого (клиентского) кэширования чтоб не отжирало память, вынося данные которые использует программа на быстрое сетевое хранилище. А не фичу отключения локального кэширования.
Мне давали статью с глюком отключения локального кэширования, но я её пока не нашел, и нормально повторить глюк не смог. Из десятка попыток один раз не закэшировалось, и один раз при последовательном чтении с двух клиентов одновременно пошло два потока чтения файла с диска (файл небольшой, места свободного навалом, читали примерно синхронно, одно и то же место).

вы оба дятлы. специалистов тут кроме вас не особо много. вместо конструктивного диалога и попыток понять друг друга начали свои идеи продвигать. хрень полная. я так и нихрена не понял пробежав наискось. вынес одно - дружески "посrались" два специалиста. для пользователей заинтересованных - так осталось и непонятным где правда, и вообще про что речь. вдобавок все перемешивается несполедосательностью и стремительностью излоджжения и перексоками наперекрест к ранее упорминавшемуся. форум, блин линейный. утрясите один маленький шажок и переходите ко второму - а то фигня полная

(286) Короче локальный кэш точно сбрасывается, но не при чтении с двух сетевых устройств. Я никак не могу найти статью в которой четко описан баг, хотя я её точно видел, но вспомнить не могу как это происходит. Мне в голову уже лезет бред что при чтении каталога со второй машины. Но не факт что это именно так.

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

(287) написали бы статью, где обощили бы опыт дискусии и разжевали... а то читать вас - еще то приключение...
.
резюме-то какое если кратко..?
.
почему при включении вторго пользователя по сети всеначинает тормозить?

(288) Из-за отключения кэша. Точно отключается кэш на клиенте, и wildhare писал по этому поводу, и 1С, и мне точно давали ссылку на Майкрософт что ошибка до сих пор не исправлена - возникают какие-то проблемы с кэшированием на сервере. Но мне сегодня нормально воспроизвести ошибку не удалось.

(289) итого: при подключении второго юзверя локально - отключается кэш на клиенте и что-то там с кешем на сервере?

(290) Да. Могут быть еще проблемы с сетью, так как работа идет малыми пакетами. Но тут рекомендации не поменялись с 2000-го года. Оставляем из протоколов только TCP/IP, поднимаем домен, ставим умные роутеры, делаем быструю сеть.

Кстати, у кэша есть еще один глюк  - если копировать большие объемы информации (например бэкапы в сотни гигов) на удаленный сервак, то он тоже ложится. Причем если для похожего глюка при локальном чтении есть куча программ для очистки кэша, которые проблему устраняют, то для этого случая я ничего не нашел. Всякие CacheSet и аналоги тут не помогают.

(290) Там не кеш отключается, а исключается объединение пакетов записи в один, то есть в случае, когда к одному файлу обращаются два клиента, то каждая попытка записи заканчивается передачей блока записи на сервер (и отработкой его там). Соответственно, чтение уже записанных данных приводит к отправке запроса на чтение данных с сервера, то есть те данные, которые были переданы в сеть, будут потом переданы обратно.
Есть ли кеширование на сервере, в данном случае, не столь важно, так как запись в dbf-файл обычно занимает 2-3 сектора диска.

Что касается решение проблемы кеширования, то Microsoft и не собирался её решать - у них был придуман замечательный алгоритм работы с автономными файлами, который позволяет получать актуальные версии автономных файлов на клиенте, сохраняя их на случай Offline-доступа (когда сервер недоступен) - самое главное - в Microsoft предполагали, что нужно отслеживать версии файлов и предотвращать запись в один файл с нескольких рабочих мест - то есть они хотели вообще отказаться от многопользовательского доступа к файлам, так как это снижает количество покупок SQL-сервера.

(292) Речь не про запись, а про чтение (отчеты).
Без кеширования, когда много запросов в очереди, получается случайный доступ к диску. При этом максимальные пакеты по 64К. Это ограничение SMB. То есть упираемся даже не в скорость диска, а в время доступа к диску, что медленней  прохождения пакетов по нормальной сети.

(292) То есть как не собирались? У них новый протокол SMB 2.1, который улучшил кэширование на клиентах.

(261) Поддерживаю. На ubuntu и w@e 5 лет так 7.7 работает. Проблем в производительности нет.

А по теме: 5 рабочих станций это вообще ни о чем.

Весело было недавно:
Купили тут дурики сервер за лям, ага, круто!
А вот батарейку для рейда с гиговой памятью забыли!
Рейд перешел в режим сохранения данных и усе накрылось.
Ну из 1С еще и печатают... Странно да?
И вот так совпало, что еще и дрова для принтера не подобрали, поэтому в спулер полетели гигабайты...
Все! Финиш! 32гига оперативки засраны спулером (ну не успевало все это записываться), 16 процессоров думали как и куда этот хлам девать, рэйд-контроллер наверное готов был застрелится ;)

(294) Я писал, что вышел даже 3.0, но это так - улучшения поднятием максимальных ограничений - теперь пакет не будет не более 64К.

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

Добавь виртуальной памяти везде до 2100. Опять же делай отдельный сервер для пользователей программ 1С. Следи за свободной памятью ПЗУ.

(285)
Сергей (NS).
Вот, не могу найти объяснение - на ЧТО уходят 63 секунды (замеры 4, 5).
Какое Ваше мнение по этому поводу?

Провожу такой тест:

Последовательное чтение справочника по наименованию из одной сессии.
Второй пользователь (сессия) бездействует. На каждом ПК по одной сессии.
Шесть запусков без перезагрузки сервера и без перезапуска первой сессии.

Один пользователь.
1) 2 сек, нагрузка сети 99%, диск на сервере читается.
2) 1 сек, нагрузка сети 0%, диск на сервере НЕ читается.
3) 1 сек, нагрузка сети 0%, диск на сервере НЕ читается.
Запущен второй пользователь.
4) 233 сек, нагрузка сети 23%, диск на сервере НЕ читается.
5) 170 сек, нагрузка сети 23%, диск на сервере НЕ читается.
6) 170 сек, нагрузка сети 23%, диск на сервере НЕ читается.

тупо как ламер - м.б. перекидка заданий на сервере пр процессорам как-то на это влияет..?

(299)
Не. Тут, думаю, лучше говорить - не на ЧТО они уходят, а откуда они берутся (улучшается) на 5-ом запуске. Т.е., типа, еще один кэш образовался. А где и какой?

(285)(299)
Повторил замеры. Посмотрел внимательнее.
В 4-ом замере загрузка сети, больше похоже, на 17%.
Т.е. время исполнения НЕтупо поменялось. :-)

(298) Может посмотреть счетчики кэша?
Я не в курсе как это происходит, но в качестве версии - если страница есть в кэше, но система считает её неактуальной, то обновление её с диска не показывается как обращение к файлу.

(302)
Не. Полное, реальное время чтения с диска меньше двух секунд. Это мы наблюдаем в замерах 1, 2, 3. А тут разница в десятки секунд. Да, и обращения к диску я смотрю на самом нижнем уровне, что позволяет сделать ОС. Вот... :-(

(303) Тут только если tcpdump-ом словить пакеты 4 и 5 и сравнить diff-ом

Ситуация, когда кеш на сервере выключается - это когда один пользователь по сети, а другой - локально. В этом случае, к файлу имеет доступ драйвер сети и процесс локального клиента - а они между собой кеш поделить не могут и тупо его чистят при каждом обращении.
То есть, два по сети к третьему будут быстрее, чем один по сети, а другой локально - много раз проверено.
P.S. можно локально заходить в базу через шару на машине, тогда кеширование ещё как-то работает.