Как быстрее работает 1С: в терминальном режиме или локально у кажд пользователя #148248

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

Конечно через терминал быстрее. Сам подумай - не будут файлы каждому юзеру качаться по сетке

Интересно,кто нить встречался со случаем,когда терминал работал медленее чем локал?

Конечно, когда терминальный сервак целерон 400 и памяти 64мб, а клиентские машины П4 3Ггц

и когда ЛОКАЛЬНЫЕ базы на таком сервере РАСШАРЕНЫ ПО СЕТИ и подключены КАК СЕТЕВЫЕ ПАПКИ %о)))И такое было

При правильной кривизне рук можно и сетевую заставить работать быстрее, чем терминале...

Терминал предпочтительнее, но бывают исключения согласно

если раб станции слабые - без вопросов поднимаем терминал после усиления терминального компа...Если раб станции средненькие (проц от 600, память от 128 под 98 и от 256 под 2000/ХР) - поднимаем нормальную сетевую....оба варианта при правильной настройке и использовании правильных рук и мозгов - одинаковы по скорости.

от количества рабочих станций в сети еще сильно скорость зависит. В сетевом варианте слабое место - это пропускная способность сети (иногда помогает сгладить проблему путем установка в сервер нескольких сетевых адаптеров и разбиение сети на сегменты). В терминальном - скорость работы процессора, объем оперативной памяти, скорость дисковой подсистемы. Слабое место по скорости - дисковая подсистема. Но сравнивать скорость работы сети и винчестера - не корректно, так как разница - 2 порядка! (В терминале желательно не забыть установить время ожидания захвата таблиц в 0). Так что при прочих равных условиях, правильно настроенный терминал будет работать быстрее. (Хотя полемика здесь бессмысленна, можно создать для проверки математическую модель поведения шарообразного коня в вакууме.)

до 30-40 раб станций в сети - влияние тормозов сети есть, но не критично (на чисто сетевой версии)....Новеловский сервер + средние рабочие станции - скорость достигается за счет работы кеша. Даже самый медленный кеш на 2 порядка быстрее самых быстрых дисков. Сеть вносит тормоза....Виндовый сервер + терминал - кеша нет, вся нагрузка на дисковый канал и процы... Сетка некритична....В целом все весьма сравнимо при 20-25 юзерах по скорости ....а вот если соединить достоинства технологий...

Недавно проводил сравнение. Результат - от покупки сервака под терминал отказались.зы Нужно сравнивать. Для разных случаев - различные варианты.

"Виндовый сервер + терминал - кеша нет, вся нагрузка на дисковый канал и процы... " - ты чего курил на новый год? Как это у диска в виндах кэша нет? В Вин95 он уже был. Даже под ДОС смартдрайв есть.

Я давно уже не занимался плотно терминалами...Но, даже при отключенном кеше, на рейд-массиве скази, на дисках 1500рпм - всё летает... мммм... просто сказочно...Да ещё если темповые файлы терминальных юзеров 1С вынести на рамдрайв...

Есть, есть... В локальном режиме.

: Ты не прав.Кеш дисков (скази-рейд) есть в любом режиме.Другое дело, что его рекомендуется отключать, что влечёт за собой некое снижение скорости.Но это снижение (для 1С) ДЕСЯТИКРАТНО можно компенсировать рамдрайвом.

Умный сильно, да? Тебе череп не жмёт? Хоть бы в суть вопроса вник!В терминале все приложения запускаются локально на сервере терминалов! Файлы по сети не гоняются. В этом и заключается выигрыш по скорости.

в сетевом варианте (а терминал - использование сетевого принципа без пересылки данных по сети) кеш отваливается....Первая рекомендация от МС - ставьте скази диски на сервер... т.е. они не мыслят иного. Новеловский прекрасно живет на ИДЕ, на скази - просто взлетает.... даже если ты сделаешь 30000 - самая медленная оперативная память под кешем будет все равно быстрее ... Увы...И темповые файлы в раме не спасут - выборка идет с основной базы на диске..У скази есть свой аппаратный кеш прямо на диске. Весьма существенно сказывается на скорости. Насчет рейдов не силен, спорить не буду, но скази одиночки юзаю.... "Виндовый сервер + терминал - кеша нет, вся нагрузка на дисковый канал и процы... " - ты чего курил на новый год?.ничего не курил... А вот чтобы говорить такое - надо неслабо покурить...Причем проверить сей факт элементарно.... "Для разных случаев - различные варианты".... Абсолютно правильно. Единого рецепта нет....Так что давно известный постулат - для более быстрой работы экономических приложений важны в первую очередь-1. Скорость доступа к данным-2. Объем ОП.Частота проца не столько существенно сказывается на скорости, только в некоторых режимах (в 7.7 - формирование таблицы для показа).P.S. 8-ка и здесь отличается нетривиальностью - влияние частоты проца при прочих равных условиях очень сильное...

Щас придёт BorisG и разгонит всю шайку-лейку нах...

"В терминале все приложения запускаются локально на сервере терминалов! Файлы по сети не гоняются. В этом и заключается выигрыш по скорости.".Не уверен - не обгоняй... Это не так - и есть тесты, подтверждающие это...Опять таки, к сожалению. Иначе выигрыш терминала был бы очень существенным, а этого нет.

: В терминалах - меня трудно чем-либо новым уже поразить...Но постом - ты меня просто убил!Подробнее можешь развернуть свою мысль, с доказательствами?

14 - не уточнишь ЗАЧЕМ отключать кеширование на дисках?Впервые слышу такую рекомендацию для дисков с рабочей инфой...

18 - шутите?

Кэш отключается не из-за сети, просто M$ не умеет решить проблему грязного чтения при обращении к файлу от разных задач. По сообщениям про 2003 - сумели.Это и для .

: Он не шутит. Это он так пиарит нетварь новелловскую.: Не помню, зачем. Сорри. Я ВСЕГДА отключаю.

23 - Ты упосмянул про кеш на рейде, я именно про него толкую. Не вижу смысла его отключать никакого - несколькократное как минимум снижение производительности обеспечено. Если отключать - то на дисках с логами БД например - там это оправдано :)

: Я тоже не вижу. Но всегда отключаю. И буду отключать. ;-)

25 - а я наоборот :)) Если нужна производительность а не тормоза - то беру нормальный контроллер, BBU, и write back сразу в енайбл :)) Иначе смысл тратиться на шустрые винты, когда обычный IDE-шный диск со включенным виндовом кешем будет шустрее.Однако, мы отошли от темы :))

Цитата... Апрель 2002......начало ....."Эти выводы можно проиллюстрировать примером. Не далее как 14-15 марта 2002 года вопрос в очередной раз был поднят на "Территории 1С". Мною было предложено провести ряд тестов и вот результаты, полученные одним из участником форума.Тесты производились по следующей методике – тестовый отчет выполнялся при подключении к базе одного пользователя и при подключенном втором, который сам ничего не выполнял (важен сам факт подключения)."Итак, краткий отчет: имеем две одинаковые базы, обе лежат на сервере Windows 2000 Server. Больше к серверу никто не обращается. К одной из баз подключен один пользователь (это я), ко второй – два пользователя (я и просто еще одна включенная машина, за которой никто не работает).Обе базы подключены в разделенном режиме для чистоты эксперимента. Затраченное время:Действие 1 user >1 user ЗамедлениеРасчётный листокна 1-го сотрудника 2.5 сек 16 сек 6.4Построение расчведомости попредприятию 10 сек 35 сек 3.5Проведение доку-ментаКонецМесяца(1220 проводок) 5 сек 32 сек 13Используется конфигурация "Расчет зарплаты" фирмы КАМИН для компоненты "Бухгалтерский учет". Ни в коем случае не хочу бросить тень на фирму КАМИН – другие бухи используют доработанную типовую бухгалтерию от 1С – те же проблемы. Основное время при двух пользователях тратится на выполнение запросов по бух. итогам – видно даже визуально при построении отчета.При расчете зарплаты приходится выгонять кадровика – иначе тормоза и расчетчик начинает протестовать. Кстати, кадровик на скорость не жалуется – она не использует документы и отчеты по бух. итогам."..........скип.....(Тесты для терминала).....Тесты выполнялись следующим образом: первый – при монопольном подключении, второй – разделенный режим и один пользователь, третий – разделенный режим и два пользователя, второй просто подключен.Конфигурация сервера: PIII-933х2512SCSI 18,3х3 (RAID-5)Конфигурация клиентв: PII-350128IDEСетка: switch 100-MbОтчет "Обороты между субконто Контрагенты и Договора"....................Терминальный режим Обычный режимМонопольно 2:09 (129 сек) 11:11 (671 сек)Разделённый 1:18 (198 сек) 11:10 (670 сек)Разделённый 5:13 (313 сек) >1 ч 20 мин.......конец цитаты.......P.S. тесты под терминалом проводил mszsuz....Как видно - те же проблемы, что и обычной сетевой....P.S. реализация работы терминальных сессий через эмуляцию сетевой работы вполне логична с точки зрения МС. Основная цель терминала по их мнению - снижение трафика на медленных линиях...    Имитация некоей "виртуальной" машины, в которой ведется работа пользователя и организация взаимодействия этих машин через сетевые интерфейсы вполне логична и требует меньше затрат за счет того, что сетевые интерфейсы в сервере уже есть... Всеж таки винда, даже серверная - это не многопользовательская ОС с интерактивной работой пользователей...    Кстати, в терминальной сессии не только не видится локальный ключ, но есть ограничения на прямое использование оборудования (при организации работы со своим ПП в терминале ребята налетели на это)....P.S. Скорее всего терминал - некая "виртуальная машина" для каждой сессии с преимущественной реализацией через сетевые интерфейсы... Скорее всего использованы некие гибридные механизмы...Сказанное не касается родного терминала в 2003 сервере - я просто его не смотрел и не знаю....Очень похожая ситуация (заблуждение) в ответе на вопрос - "Во сколько раз возрастет скорость копирования файлов по сети при переходе с 10 Мбит на 100 Мбит" - наиболее частый ответ - в 10 раз... Хотя реально всего в среднем в 2-2.5 раза на больших файлах. Просто увеличена скорость на участке, который занимает малую часть временной диаграммы при копировании файла.   Аналогично и терминал - физическое выполнение программы на железе сервера не означает, что эта программа подчиняется правилам для локально запущенных программ...   Аналогичное различие есть и в методах обеспечения доступа программы к данным. На уровне системы есть отличия, которые не видит программа.Отсюда тоже заблуждения. Кстати, вот вопрос - есть 2 программы - локальная (на сервере) и сетевая (на раб станции).Сколькими методами можно организовать доступ к файлу на диске сервера- от локальной программы- от сетевой программы

я не пиарю новель... Пиарить это бесполезно... Да, кстати, и спецов то по нему мало нормальных....Интересное наблюдениеУ трех последних клиентов - торговые базы на скуле, а базы бухии - все ДБФ, причем есть и более 1 Гб - обязательно на нетвари...Все новеловские сервера - древней гуана от мамонта, и все не затыкаются по производительности и не тормозят. У одного - все бух базы в терминале, но у бухов машины очень слабенькие...

с 28 согласен, правда не очень понятно как это соотносится с сабжем :) Новелл умеет терминал, просвятите плиз? Или там отдельные решения под него есть, типа цитрикса?А 27 просто не понял :)

Не понял, через какие еще сетевые интерфейсы в терминале 1с обращается к данным? Для каждого пользователя терминала все ресурсы сервера, в том числе и диски - локальны. И путь к базе указывается локульный. Для сервера терминалов просто запускаются несколько экземпляров 1С, и не важно, от имени разных пользователей или одного. То, что ключ не видится на сервере терминалов (причем алладиновский драйвер его прекрасно видит, не видит только приложение 1С) - результат маркетинговой политики 1С. С распространением терминальных технологий, стало возможным работать с ДБФ базами бОльших объемов (на типовых до гигабайта без проблем). Поэтому продажи SQL версий (которые использовались для сокращения трафика между сервером и рабочей станцией при больших объемах данных) сократились. Терминальное решение оказалось технически проще и выгоднее.

"Терминальное решение оказалось технически проще и выгоднее."- Да как бы для того и существует. А я что-то не заметил особого уменьшения трафа при использовании СКЛ vs сетевого доступа. И у него есть еще куча плюсов, не только скорость. Равно как и у СКЛ.Что до ключа - не наблюдал с ними проблем, обощел бог меня стороной :))

Не видится на 2000 и 2003 серверах при поднятой службе терминалов.

32 - на 2000 видится однозначно, т.к. пользую его.На 2003 вроде тоже, в режиме админского терминала запускал 1С.Буду на работе - проверю с 2003.

: Я тоже не понял , но мне было стыдно в этом признаться.Респект тебе, за то что озвучил.

"Для каждого пользователя терминала все ресурсы сервера, в том числе и диски - локальны".Бред.... Путь к базе, прописанный через примапленное устройство, тоже выглядит как локальный... напрмер, D:BasesBase1.... но является сетевым....С ключом пример неудачный... Согласен...."Поэтому продажи SQL версий (которые использовались для сокращения трафика между сервером и рабочей станцией при больших объемах данных) сократились".Скульная 77 таскает по сетке не меньше данных, чем ДБФ-ная... Ибо она использует скуль только как хранилище....Терминальное решение не проще. Просто новель и .никс системы использовать - нужно иметь грамотных спецов.... Которых мало.

"Бред.... Путь к базе, прописанный через примапленное устройство, тоже выглядит как локальный... напрмер, D:BasesBase1.... но является сетевым..."- Это почему еще???

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

Мдя... наверное, в нескольких словах....При подключении к одной базе более одного юзера по сети и в терминале наблюдается одинаковый эффект торможения из-за сброса кеша... что демонстрируют замеры с сетевой и терминалом при 2-х юзерах - второй просто подключен.1 юзер в терминале немонопольно - выполняется отчет 198 сек2 юзера в терминале немонопольно - выполняется отчет 313 сект.е. и при сетевом доступе, и при терминале второй и последующие пользователи (сам факт их подключения) вызывает торможениеПри сравнении 2000 как файлового сервера и в режиме терминала - терминал однозначно рулит....На новеловской сети при одном пользователе немонопольно отчет будет тоже выполняться 198 секунд, НО ПРИ ПОДКЛЮЧЕНИИ ВТОРОГО НЕ БУДЕТ ЯВНОГО ПРОВАЛА и отчет так и будет выполняться 198-210 секунд.    Вот это и есть сравнение возможностей....И даже ПРИ ОДНОМ пользователе в терминале под 2000 и одном сетевом пользователе на нетвари время выполнения отчета будет достаточно близким... Ибо кроме кеширования в нетвари есть еще ряд механизмов ускорения, не реализованных в МС сервере в роли файлового сервера

: Спасибо, всё понятно.Продолжайте продвигать новелл-решения для своих клиентов.Я же буду - внедрять терминальные решения. Удачи!

38, 39, и что самое интересное - будете делать это с одинаковым успехом :)))Кстати, про стоимость ОС и лицензий мы почему-то умалчиваем..

: ;-)Жму руку.Хороший у тебя юмор, и посты твои - всегда по делу. Респект.

Только что проверил. Запустил в терминале под разными пользователями три экземпляра 1С с одной и той же базой. Сравнил по скорости формирования отчета в монопольном режиме. По пять раз запускал и втом, и в другом случае. В монопольном чуть-чуть быстрее: Разница в 3 сек. при длительности формирования отчета 55 сек в разделенном режиме. (Сервер правда у меня 2003 и диски скази рейд 5 - 6 дисков). Никакой дисковый кеш при разделенном доступе не вырубается. Что я делаю не правильно?

мдя ... пора идти учиться... но не мне... это твои измышления... насчет локальности... Сделанные на основе того, что внешне путь выглядит как локальный...Ну тогда на пальцах...Пусть сервер СЕРВ имеет расшаренный ресурс БАЗЕК нему можно обратиться через написание СЕРВ:Базеимяфайла (способ1 - указание уникального сетевого имени ресурса, там в синтаксисе две палки указать надо) или примапив диск в сетевом окружении (правой клавишей на Базе - меню Подключить сетевой диск, будет окошко с выбором буквы для сетевого диска). Это способ 2 и путь к файлу выглядит как Буква:Имяфайла, где буква - Д,Е,Ф,Ж,... и до буквы Z.....Программа открывает файл по способу1. И обращается к системе с указанием пути в виде СЕРВ:Имя. Система по синтаксису определяет обращение через уникальный сетевой идентификатор ресурса и в блоке управления файлом прописывает ссылку на программу обслуживания файла через URL. Через эту программу и будет осуществляться обмен с файлом и блокировки....Программа открывает файл по способу2. И обращается к системе с указанием пути в виде Д:Имя. Система по синтаксису определяет обращение ЯКОБЫ локальное имя и отдает вызов в файловый процессор, который делает доп проверку и обнарудивает, что Д - это имя примапленного устройства. В зависимости от того, является ли Д именем локального устройства или примапленного - подключатеся либо локальный файловый процессор, либо удаленный файловый процесссор. Локальные запросы выполняюся локально, удаленные транслируются на СЕРВ и выполняются файловым процессором машины СЕРВ. И этот факт в большинстве случаев программа НЕ РАЗЛИЧАЕТ. Но фактически в системе работает именно доступ к сетевому файлу. Сделано это было по разным причинам - одна из них - программе пофиг, где лежит файл, она работает с ним как с локальным, вся разница в обслуживающих программах самой ОС. Но при всей похожести имен локального и удаленного - это разные модули ОС....В способе1 и способе2 доступа к ресурсу используются разные модули ОС (доступ через URL и через удаленный файловый процессор). Вот тут есть маленькое свинство - блокировки отрабатывают по разному + немного разные методики корректировки данных на диске, когда они лежат в разных кластерах/блоках... Отсюда - для одной базы не рекомендуется смешивать оба доступа. Либо способ 1 (URL - его проще администрировать), либо способ 2 - он быстрее, но проблемы с тупостью юзеров...

"Хороший у тебя юмор, и посты твои - всегда по делу. Респект."Спасибо :)) день сегодня такой - юмор весь день по TV :))"Запустил в терминале под разными пользователями три экземпляра 1С с одной и той же базой. Сравнил по скорости формирования отчета в монопольном режиме"Это интересно как??И еще, уважаемый topasha, не забываем про конфиг. Сервер считай однопроцессорный, т.к. 1С SMP не умеет. А значит весьма возможно что проц у клиента мощнее. Далее сеть - если юзер один - тормозить она вряд-ли будет. Потом - память. То же вопрос... В результате на серве могет быть только дисковая шустрее ("Сервер правда у меня 2003 и диски скази рейд 5 - 6 дисков" - Вы не указали марку контроллера, а при отключении всех кешей, скорость локального диска может быть и больше). так вот с какой радости терминальнику работать быстрее? Не будет. А вот теперь ставим сервак на конфиг клиента, настраиваем терминал, и подключаем к нему человек 15. И уже после этого делаем новые выводы.Про что хочу сказать - навернутый серв это как карьерный самосвал. быстрее жигулей ездить не будет. Однако когда надо перевезти тонн 15 груза из пункта А в пункт Б - сравниваем скорость :)))

43 - я люблю учиться и нисколько не обижаюсь, но ГДЕ Вы видели на терминальниках расшареные каталоги с БД????

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

:"Ну тогда на пальцах...Пусть сервер СЕРВ имеет расшаренный ресурс БАЗЕК нему можно обратиться через написание СЕРВ:Базеимяфайла (способ1 - указание уникального сетевого имени ресурса, там в синтаксисе две палки указать надо) или примапив диск в сетевом окружении (правой клавишей на Базе - меню Подключить сетевой диск, будет окошко с выбором буквы для сетевого диска). Это способ 2 и путь к файлу выглядит как Буква:Имяфайла, где буква - Д,Е,Ф,Ж,... и до буквы Z...." -Ржу. Нимагу. Под столом.Согласен с автором .

46 - далее Вы упомянули работу монопольно еще одного клиента, вот этого я и не понял :))43 - Вы прикалываетесь, я так понимаю? :)

(39,40) Все верно - новель или терминал - это решается по конторе. Но спецов по новелю меньше..Терминал рулит при удаленном доступе по медленной линии...Год назад лицензия на 50 юсеров на новель+сервант стоила дешевле 50 лицензий на терминал + сервант от МС....Во первых, я специально оговорился, что это проверялось на 2000... а у тебя 2003. Это разные серванты... и 2003 я не смотрел....Во вторых, а ты кеш в 2003 не забыл включить? Ибо по умолчанию он выключен и ты, естеВственно, не увидишь разницы....В третьих, ряд наворотов НТФС + навороты АД на практике приводят к отключению кеша, даже если стоит птиса ВКЛЮЧИТЬ кеш...2003 сервер - штука еще та...

: Да конечно прикалывается.Читай посты (3-5) в этой ветке.

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

49:1. Год назад юзали сервер и клиентов Win2k. Где лицензия на терминальный доступ не стоила НИЧЕГО.2. Полситни юзеров по 100-мегабитке то же может быть медленной линией :)2. Про кеш - так и есть. Но не забываем про аппаратный кеш нормальных рейдов, который виндам выключить не под силу.

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

" Где доказательство того, обращение С:Базе отрабатывается как локальное... и что работа ведется как с локальным диском..."- Если это примапленный сетевой диск - работа ведется как и с сетевым диском. Вы правы. Однако разговор-то про терминал :)"В описана процедура подключения к серверу с рабочей станции... а не терминал.."- Я так и понял. Вот только при чем тут терминал?

В какой то момент времени дискуссия действительно пошла не в том направлении и скатилась к доказыванию того, что при определенных условиях терминал дороже и не быстрее... и что терминал работает по тем же самым принципам, что и сетевая.... Аппаратный кеш скази винды не могут отключить, но к сожалению, это немного не то... Нет дополнительных программных способов типа хеширования или оптимизации пролета головок, или упреждающего чтения...Хотя действительно дает существенное ускорение. Размер его пока на современных винтах уступает реализованному программно....P.S. индексация одной и той же базы на ИДЕ - чуть больше 8 мин, скази с кешем - 1 мин 40 сек, тот же диск с выключенным кешем (специальной утилитой из комплекта винта) - порядка 7 мин... Скази - древний, адаптер АНА-2940 с буковкой какой то (тож ровесник мамонта), ИДЕ - новый 80....Надо прогнать тест еще на САТА диске...

"и что терминал работает по тем же самым принципам, что и сетевая..."- Вы же не хуже меня понимаете что это не так?"Нет дополнительных программных способов типа хеширования или оптимизации пролета головок, или упреждающего чтения..."- Аппаратные есть :) А вот почему уступает реализованному программно (которое ОС могет и отключить)?Не нада сравнивать древнее железо с современным. Хотя бы уже потому, что древнее Вам никто не привезет.. Давайте может сравнивать адекватное железо?И что это за утиль из комплекта ВИНТА что может отрубить кеш контроллера?

Я не буду доказывать, по сетевой или нет - но последствия на морде лица...."Не нада сравнивать древнее железо с современным. Хотя бы уже потому, что древнее Вам никто не привезет.. Давайте может сравнивать адекватное железо?".Можно и адекватное сравнить... Если на имеющееся новое железо с аппаратными средствами ускорения работы навернуть еще старые методы оптимизации, поддерживаемые в современных версиях ОС типа новеля и .никсов - получим соответствующие преимущества...При работе с ДБФ МС сервера работают медленнее за счет отсутствия оптимизации на уровне ОС, при работе под MS Sql - последний имеет свои механизмы кеширования и оптимизации, которые сглаживают неостатки самой ОС от МС..P.S. советы "поднимать Sql и терминал при работе 3-4-5 пользователей" - это создание лишних сущностей там, где они не требуются... Зачем переусложнять систему? И удорожать ее? Если все покупать официально...

Уважаемый pit, извините но я осмелюсь утверждать, что Ваш Новель уступит терминалу. И вообще, складывается впечатление, что вы видели терминал только у соседей и через окно... Я утверждаю, что при хорошем серванте и приемлимом количестве пользователей на нем, терминальное решение УДЕЛАЕТ Ваш уважаемый Новель. (К новелю действительно отношусь с уважением)

терминал - не уделает....Просто это конкурирующие по скорости решения для систеты из 10-20 юзеров в одной базе. При разных начальных условиях.Решение через новель дешевле и работает быстрее, если раб станции все не ниже среднего уровня (проц - от 600, память 98-128 метров, 2000/ХР - от 256 метров).Терминал дешевле и выгоднее, если раб станции слабые.Терминал рулит при удаленном доступе к линии (в новеле есть уд доступ, но медленный). И конкуренции териминалу здесь нет вообще...Это - общие критерии разделения....Так что общей рекомендации нет..P.S. Связка терминальный сервер, соединенный гигабитным линком с сервером под новелем - недостижима по скорости. Плюсы обоих решений соединяются. Но большой вопрос со спецом, способным поднять такое решение...

Не буду голословной. 4 года сидели на Новеле.Сервер со скази, 22 юзера, база 1,2 гиг , дбф.Самая слабая клиентская машина - Целерон 1800. Но вот в последнее время тормоза стали очень напрягать и все чаща и чаще база слетала. и это могло повторяться по 5-6 раз за день. Уже полгода стоит терминал под win2003, сервак 2*Оптерона, 2 гига памяти, SATA RAID 0+1. ЗНАЧИТЕЛЬНЫЙ прирост в скорости отметили абсолютно все. Про надежность я уже молчу. Про администрирование тоже. Цена решения возможно дороже, не приценялись к Новелю уже давно. Но и плюсы очевиднее. И потом, за комфорт и скорость нужно платить. И это понятно всем. А вот в предложенной вами связки для дбф вообще смысла не вижу. Решения же для скуля логичнее делать на МС. А вот в чем соглашусь с вами, так это что a файл-серверной роли Новел действительно шустрый.

"Решения же для скуля логичнее делать на МС.".Хм... Если ты подскажешь, КАК решения для скуля реализовать на новеле....У клиентов базы от 0.8 до 1.5 гектара. Тормоза периодически возникают, причина - шаловливые неумелые ручки копаются в новеловском клиенте... Идиоты... Слетов баз нет, есть только одно - если клиент стоит старый (ниже 3.31) , то возможны проблемы. В факах новеля это было. Совет там был - просто взять клиента новее. Кстати, на ИТС клиент до сих пор болтается 3.30...   Похоже, просто никто не разбирался. Почти на 100% - сменили раб станцию, сдуру сунули клиента от новеля, не вырубив сетевой кеш на нем - вот она и начала укладывать базу... Это на ИТС описано....В обычной жизни у терминала и новеля есть похожий глюк - слетание принтеров в терминале и зависание диспетчера печати в новеле. Это достает.Если перешли на терминал без проблем - значит, спец квалифицированный был...   У клиента сделали производство, надо было выбросить 6 машин в цеха... Сразу планировали терминал для простоты (там сетка 10) - так админы его больше месяца поднять не могли. После разговора - или мы ставим за денюжку или ищете спеца сами - клиент нашел человека сам, чел поднял терминал и машины встали без проблем... В условиях производства терминал дает возможность спихнуть в цеха самое .уано - оно все равно там быстренько помрет...   Не везде наша рекомендация - новель. Небольшая контора, до 10 юзеров - да гори они пропадом париться с ними. Пусть ихний админ поднимает 2003 в роли ФС и вперед...

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

"В общем каждому свое..." и это правильно...Реально сетка на хабах/коаксиале затыкается при интенсивной работе 15-40 юзеров... Использование свичей повышает пропускную способность и думать о ней при 30 активных юзверях - не стоит... Хотя реально перед глазами сеть на хр... сколько машин, общие серванты - 3 новеловских по 250 юзеров, 4 МС, + терминальные сервера в подразделениях.... Правда, там 1С только в бухии, и она выкинута в отдельный сегмент... чтобы опоросы ключей в 8-ке не гадили везде...   Сейчас посчитал - у клиентов на новеловских серверах реально висит по 15-20 человек, в терминалах - тоже по 15-20. Т.е. сравнимо по числу юзеров. Скорость в общем то одинаковая...В терминалах есть удаленная работа и контора, где раб станции - пни первые и вторые....ЗиК на сетке в момент расчета... Это отдельный цирк...

"... сетка заткнется."Да ну? При сегодняшних технологиях сетка явно не самое узкое место. По краней мере, в ценовом аспекте.

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

"да и технически не сможет 100 мегабитный канал обслужить райд скази в страйпе."Кто сказал, что на сервер должен быть 100 Мб канал? Сервера то почти все имеют по две гигабитные карты.."если гигабит метров на 400 по улице кинуть..."А... в чем проблема?Оптика для внешней прокладки от 2-3 зеленых за метр, конверторы, если коммутаторы оптических портов не имеют, чуть больше 100.Отстальное должно быть по месту, с учетом особенностей монтажа. Спецов чтоли нет?

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

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

Ну не спорьте вы. ДЕШЕВЫХ решений не бывает по определению, поскольку потом такое решение влетает в куда большие деньги. Вы можете сэкономить сейчас, но это единовременное решение к которому придется еще вернуться и опять влаживать деньги. Дык наверно проще сразу вложиться и потом "не париться". Это касается как сетевых так и терминальных решений. А вообще нужно нанимать спеца который все сделает.

На счет сат5 прав, но кабель кабелю рознь. у нас, например, гигабит, частенько падал до 100 мегабит, пока новый кабель не кинули. По второму моменту... при монопольных манипуляциях (индексация, перепроведение, тестирование и исправление) кабель на клиенте пропустит только 1/6 реальной скорости дисковой подсистемы. а индексацию зачастую делают пользователи со своей рабочей машины. предполагается наличие админской, весьма неслабой машины с отдельным гигабитным каналом для подобных целей? и когда пользователей меньше чем шесть опять же получаем неполную отдачу от винтов... Терминальная модель лишена этих недостатков.

"но кабель кабелю рознь."Ну ну. Это если только кабель покупать, не соответствующий стандарту.Вообще-то я не понимаю этой фразы, поскольку и качество прокладки, и самого кабеля измеряю прибором, а не смотрю, что написано на кабеле, и как получится ;)ps: Это беспредметный разговор.