Скорость доступа через шару VS напрямую

[ack]

На сервере есть база (dbf-файлы) 1С Предприятия. К файлам организован доступ с терминалки (которая стоит, как полагается, на том же сервере). Доступ организован через шару.
Пути к базе прописаны как UNC: т.е. \\server\baza$\dir
Т.е. в процессе работы пользователя с терминалкой сервер через UNC путь обращается к самому себе.
Вопрос: насколько это медленнее (и медленнее ли вообще) чем обращение к файлам локально/напрямую (т.е. через обычные пути C:\db\baza\dir) ?
Есть ли смысл менять UNC-пути на локальные ?

[Unit]

А сам то как думаешь?

[ack]

А сам то как думаешь?

[snapback]825[/snapback]

Сам думаю, что возможно медленнее, хотя не уверен
Вопрос: если медленнее, то на сколько?
Если меньше чем на 10 процентов, то смысла менять пути нет, т.к. задача трудоемкая (баз и пользователей много - придется новый шаблон групповой политики писать и отменять старую политику).
Т.е. смысл вопроса, повторяю, в том: есть ли смысл чесаться или нет

[DrDeath]

нарушаешь первую заповедь "работает - не трожь!" ? (;

[ack]

нарушаешь первую заповедь "работает - не трожь!" ? (;

[snapback]834[/snapback]

пытаюсь отыскать компромисс между этой заповедью и приказом начальства "чтоб усе летало"

[SinClaus]

На приказ начальства есть простой ответ: Быстрее в два раза стоит в десять раз дороже.

[ack]

На приказ начальства есть простой ответ: Быстрее в два раза стоит в десять раз дороже.

[snapback]839[/snapback]

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

[Unit]

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

[Terminator]

Может не совсем по теме, но около того  

Знакомый делал какую-то хрень на 1C, очень сильно удивлялся почему она так медленно ворочается на его могучем компе.
Для смеха создал ramdisk и положил базу туда, получил примерно стократный прирост производительности

[Unit]

У 1с очень громоздкая база. Понятное дело, что на ramdisk она будет шустрее.

[AdVv]

У 1с очень громоздкая база. Понятное дело, что на ramdisk она будет шустрее.

[snapback]860[/snapback]

Сейчас модно 1С раздавать через терминал сервер. А если еще и на рам диск свалить базу ... Думаю летать будет просто со скоростью света. Главное чтоб свет не выключали

[stranger]

Сейчас модно 1С раздавать через терминал сервер. А если еще и на рам диск свалить базу ... Думаю летать будет просто со скоростью света. Главное чтоб свет не выключали

[snapback]872[/snapback]

Летать-то будет а вот как с резевированием быть... Нет это только себе проблемы со временем искать...

А что мешает поставить 5-ый или 1-ый рэйд?    Скорость общения с диском возрастет.
В первом случае еще и защита  будет не плохая, а во втором только скорости прибавится и бэкапы придется делать самому и почаще... Так как накрывание одного диска приводит к большим проблемам...

[ack]

Сейчас модно 1С раздавать через терминал сервер. А если еще и на рам диск свалить базу ... Думаю летать будет просто со скоростью света. Главное чтоб свет не выключали

Кому модно, а кому другого выхода нет.
На рам - это ИМХО перебор. Если памяти достаточно, то виндовозного кэша должно хватать, чтобы операции выполнялись более или менее шустро.
Дело немного не в этом.
Предприятие тормозит не из-за медленной скорости чтения или записи, а из-за частоты и продолжительности с которой отдельные приложения, запущенные у пользователей, обращаются к общим ресурсам, блокируя их. Особенно когда запускается сложная обработка.
Поэтому тут непоследнюю роль играют железки, на которых запускаются предприятия.
Отсюда и идея терминал-сервера.