1C файловое с разными серверами

[skoltogyan]

На одной и той-же тачке с 512 мозгов и IDE 10 G
ставили последовательно:
W2KSrv (настроеный для работы как файл-сервер, прописывалось еще и в регистре сколько под файловый кеш), NW6(NSS, где 90 % ram под кеш отдано) и samaba2.2.2 on asp7.2.

Работали с 4-х тачек, NW клиента от NW нествили негде.

Быстрее остальных справлялось при построении отчетов на всех 4-х тачках:
1. W2k , работая по netbeui
2. Потом по ipx шла NW (на 10 % хуже чем номер 1)
3. Потом по ipx шла W2k ( на 15 % хуж чем номер 1)
4. Потом по netbios over Tcp/ip шла samba (В 2 раза хуже чем номер 1)

[skoltogyan]

Собсвтенно при сравнении производительности с W2K как файловой помойкой неследует забывать, что NW c NSS позмоляет очень просто восстанавливать файлы и ПОДКАТАЛОГИ самому пользователю, чего нет ни в W2k(Надо докупать отдельный продукт) ни в samba2.2.2.
Плюс - действительно удобная система раздачи прав, что особенно заметно и чувствуется при работе с большим количеством пользователей и директорий+файлов.

[Станислав Дронкин]

ПО моему надо было все таки поставить клиента NW. И еще раз протестировать....

[skoltogyan]

Oportunistic Locking всеравно тут не пойдет. так, как файлы используются одновременно всеми. И Кеш локальный - то-же в этом случае..

Клиент дает управляемость и nds ориентированые фичи + возможно
установить некоторые фичи, повышающие (теоретически) надежность и понижающие (безусловно) производительность.

Резюме дал бы такое:
1. Ненадо охайно хаять W2K, что так уж сильно медленнее чем NW
или хвалить NW, что так уж сильно быстрее.
2. И.. Неужели кто-то реально использует 1С файловый вариант с одновременным доступом к одной и той-же базе > 20 машин ??
3. Что вы говрите заказчикам, или сами как заказчики, когда понимаете, что вам нужен УДАЛЕНЫЙ ДОСТУП к Вашй 1С файловой с удаленой площадки по dial_up ???

[Сергей Дубров]

ПО моему надо было все таки поставить клиента NW. И еще раз протестировать....

Да, очень верное замечание. Со своей стороны скажу, что на схожих тестах (пять клиентских машин), только для БЭСТа, Новел 5.1 с установленными клиентами32 уделал всех (естественно, на одном и том же железе). Уделал и при работе по IPX-у и по IP. Что интересно - там, где было много мелких чтений/записей - выигрывал IPX, где требовалось работать большими пакетами - IP. Оно, в общем-то и понятно.

Точную цифру превосходства NW как файл-сервера в процентах уже не помню, было съэкономлено что-то в районе 8-10 минут на фоне 45-50 минут. Что ещё интересно - Win2000 Adv Server специально тьюнился на роль файл-сервера приглашённым спецом, без этой подстройки 2К проигрывал новелу более, чем вдвое. Новел был поставлен по дефолту (те самые победные цифры были получены именно в установке по умолчанию). Тьюнить NW уже просто было неохота да и некогда - микрософтовский спец ушёл в больших растройствах и без этого . На следующий день из любопытства подкрутили у 5.1 некоторые параметры (рекомендации по ТИДам) и отыграли ещё почти 6 минут! Вот так вот. Заметное отличие от тестов Сергея Колтогяна - диски были сказёвые, как положено на сервере, IDE на многозадачке - нонсенс.

[skoltogyan]

У нас долго использовался БЕСТ-4.
Одновременно на сервере было открыто до 5700 файлов от Беста.
И у клиентов, то-же был БЕСТ.
У нас не пробовал, а уклиентов пробовал - Да, С NW клиентом БЕСТ БЕСТ работал быстрее, чем с MS клиентом for NW.
Но как оно себя ведет на W2K уже недовелось увидеть

Что касается 1С..
У клиента пробовал тоько так:
Cервер так и оставался NW, а клиента пробовал либо от NW либо MS client for NW , все это на W98 SE RUS.
Вот тут, как ни бился.... При одновременной работе, пусть ну 3..5 % но было быстрее, когда клиент был MS client for NW.

Во всех случаях работы с NW32Clientoь всегда убирал ВСЕ КЕШИ (запрещал, в 0), запрещал truу commit, reconect level=1). Это с целью снижения вероятности поломки баз.

А по поводу сравнения, что написал... Написал то, что увидели.
И на том железе, что было пробовали.

Хочу отметить, что эксперимент был читсым в том плане, что машины (рабочие станции и сервер) были в отдельном от всех свиче 3COM 100 Mb. И для каждой ОС, делали один и тот-же тест , практически не реконфигурируя станции, только меняли сервера. Станции были одинаковой конфигурации

Если возможно, не переходить в плоскость Отстой и Куул.
Интересно, а какие настройки на клиенте NW32 on W98SE вы делали (что меняли от того, что по умолчанию)?
Какой именно клиент NW?
Были-ли на станции другие клиенты ?
По какому протоколу работали с NW сервером ?
ТОМ NSS или традиционный ?
Пробовали запускать одновременно один и тот-же отчет?
Что меняли в настройках сервера ?

Мое мнение, для приложения класса БЕСТ, ключевое место, не производительность КАНАЛА или насколько оптимально настроен файловый сервер (исхожу из того, что сети сейчас восновном 100-ки и достаточно мощное коммутационое оборудование, на сервере много памяти и быстрая подсистема ввода-вывода), а производительность самой станции.
Быстрее всего БЕСТ у нас бегал на DOS6.22 чистой, когда снесли винду. При этом, когда работали с традиционным томом, LRU было 20..25 минут и каналы (сеть) забита небыла..

Еще я встречал одно уникальное ПО (dbf ориентированое на FoxPro).
Оно начинало работать (визуально при построении отчетов) быстрее, когда сменили свич 100 на хаб 100... А при постороении отчета не в монопольном режиме оно так работало (для базы размером 300 MB):
Найти запись
Заблокировать запись
Считать
Разблокировать запись...
и так до одури..
Все это строилось 35 минут.. Когда переводили в режим МОНОПОЛЬНО СТРОИТЬ ОТЧЕТ, то делалось так:
Заблокировать файл
Найти запись
Считать
запись
Опять найти...
И тоько в конце разблокировать..
При этом время выполнения падало до 9 минут....
В обоих режимах утилизация сервера не подымалась выше 10..15 %,

Вот такие наблюдения...

[Мещеряков Андрей]

Спасибо уважаемым за информацию. Я раньше воздерживался от комментариев по поводу NSS, а теперь заведу на нее карточку с буквой Х. Тварь на томах классического образца (теперь я категорически не вижу смысла изменять им) стабильно делает любой МС -сервер. За исключением криминальных случев, когда находящиеся в работе данные умещаются в оперативный кеш. А МС клиент твари действительно действует быстрее: НВ-клиент мало того, что инородный костыль в винде, так еще и написан мини-тварью, где в своей среде крутятся *.nlm Зачем так устроено - не пойму, приходится есть то, что дають.

С уважением, and

[Сергей Дубров]

А МС клиент твари действительно действует быстрее: НВ-клиент мало того, что инородный костыль в винде, так еще и написан мини-тварью, где в своей среде крутятся *.nlm

На БЭСТе (досовском) радостные тётеньки аж подпрыгивали от удивления, когда после замены мелкомякгого клиента на новеловского 3.21 (вин95/98 ) всё начинало просто летать. Отчёты и реиндексация просто в разы быстрее работали - и на глаз и по измерениям. Сервер и железо рабочих станций не менялись, естественно. Hint: мелкомягкий клиент для Netware - 16-ти разрядный, для работы с другими подсистемами (ДОС, 32-х разрядная) используются thunk-и (промежуточные слои-конверторы, да ещё и через mutex), а это не есть быстро. Кроме того, M$ клиент абсолютно не в курсе про packet burst, новеловский его и за счёт этого тоже делает.

[skoltogyan]

Pburst Никак не ускорял работу Беста у меня.
Хм. Работали через switch 3com
SuperStackII 3300 XM

карточки в станциях былиL RL100
В сервере Intel Pro 100/s

[Аркадий Глазырин]

2. И.. Неужели кто-то реально использует 1С файловый вариант с одновременным доступом к одной и той-же базе > 20 машин ??
3. Что вы говрите заказчикам, или сами как заказчики, когда понимаете, что вам нужен УДАЛЕНЫЙ ДОСТУП к Вашй 1С файловой с удаленой площадки по dial_up ???

2. У нас в Екатеринбурге таких сотни. Поверь на слово. Если не веришь, то приезжай. Десяток за день успеем объехать. И везде ты услышишь одни и те же всхлипывания. По части медленности работы.
3. А Заказчикам он не нужен. Они даже не предполагают зачем это надо. Прикинь? Тем паче, что скорее к тебе конкуренты или свои же обиженные залезут прежде чем эта фича кому-то на самом деле понадобится.

[skoltogyan]

И непонимаю, зачем используют, когда так медленно работет.
А про удаленный доступ.. Например по диал_ап или выделенки.. Тут , наверное, просто разные запосы у людей

[Сергей Ефремов]

На форуме Соколова уже обсуждали почему 1С c NW Client работает медленнее чем с MS Client, оказывается у NW Client по умолчанию отключен кеш, а у MS включен.

[skoltogyan]

Включены Кешы, но и включено
recconect level=3, который существенно тормозит (в разы).
При работе с файл-серверным приложением , если оно написнао без использования транзакций от NW, следует отключать все кеши на станции, для повышения живучести (станция может вырубиться, подвистнуть или свич отрубиться и как следствие - поломка базы).

Но, на мой взгляд, ушло время файл серверных приложений, в таком виде как было. Т. е: на сервере свалка файлов dbf-ок и индексов, а станции с приложением работают и ганяют данные по сети.

Применение 1С файловой, если больше 10 одновременно нерационально и следует уже присмотреться к 1С SQL версии или к другим продуктам.
Но , надо отдать должное Постановщикам задачив 1С - они это делают неплохо. А вот реализация (работа писателя) - неахти...

Кстати, а кто знает какие существуют альтернативы 1С (неважно на какой платформе) и какое используют более тяжелые продукты?

[Мещеряков Андрей]

Мне из потенциальных конкурентов 1с известны следующие:

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

2 Инфо-бухгалтер. Здесь имеет место быть Борланд датабэйс инжин (БДЕ) Тоже хорошо работает с блокировками именно Твари. Бухгалтерам нравится, но SQL -версии нет.

3 Инфософт со своими "интегральными" продуктами. SQL версия только под Оракл, по моему Эн-Тевый. Инфософту не верю, ибо в свое время поддерживал его продукты! Эти ,,,,.....))) несколько лет кормили народ бета-версиями (за деньги) а смысл консультаций по горящей линии состоял в сентенциях типа "неправильная У ВАС Тварь" Видите ли, ИНТЕГРАТОРУ нужна ВЫДЕЛЕННАЯ сеть!!! Но если удается отладить, бухгалтерам нравится.

4 Парус. Ранние версии писаны на Клиппер тоолз 3 , так что глюки те же, что и в Интеграторе: не может определить свободное пространство на томе, проблема с псевдокорневыми дисками и т.д. Новый писан на чем-то визуальном. Точных данных нет.

Прошел интересный слух, что ранние версии 1С SQL использовали Oracle, а не МС сервер. И у него была генерация для Твари...

С уважением, Мещеряков А.

[Сергей Дубров]

Применение 1С файловой, если больше 10 одновременно нерационально и следует уже присмотреться к 1С SQL версии

Вот как раз 1C SQL не надо - это "чудо" работает абсолютно в том же стиле, что и файл-серверная версия - select *, всё затаскивается к клиенту и вся обработка делается на клиенте же. Результат - нужен существенно более мощный и дорогой сервер (sql ведь "используется"), сеть забивается точно так же, как с файл-серверной версией. Скорость работы (по определению) - не выше, чем у всё того же файл-серверного варианта. Фактически 1C sql только поменяла способ, которым всю базу гоняет по сети, а идеология - всё делает клиент - осталась.