Posted: 21 Oct 2002 10:07 Post subject: Гигантская разница в скоростях сетевого и локального БЭСТ-а
Работает пользователь локально с базой - скорость формирования отчёта скажем 10 секунд.
Подключается сетевой пользователь - у него скорость формирования отчёта секунд 15.
Подключается второй сетевой пользователь - отчёт формируется минуты две... Даже при неработающем, только подключенном первом сетевом пользователе.
Не водится у нас 98-ых. Как факта. Проверял на NT4, NT4TSE, w2k. Клиенты NT4Wks, w2k. Фигня творится при любых сочетаниях. Ещё веселее то, что трафик от сервера к клиенту при подключении второго клиента падает до 200-300кб/c, это на 100мегабитной сетке на трикомовских свичах отстроенной...
Joined: 31 Dec 2001 Posts: 1696 Location: Гусев Михаил
Interests: Москва
Posted: 21 Oct 2002 12:10 Post subject:
К сожалению, я не дока по МС сетям.
У меня в качестве сервера стоит Novell и там такого нет. Что один, что 100 разница не велика. Она, бесспорно, есть, но не в разы.
На НТ собирал один раз (давно) и такого эффекта не наблюдал.
Странно, у меня сервак на W2000 а станции на W98 БЭСТ-4 на семь мест, работают все постоянно, ничего подобного не замечал, но на серваке запускать БЭСТ и не пробовали и не думали..
Нужно смотреть сетевые настройки. Так не должно быть.
Чего уже только не проверялось... Разве что кроме клиентов на Win98...
Всё остальное файлсерверное добро то просто летает, песня можно сказать, один БЭСТ дурит как редиска последняя. Да и вообще трудно на сеть грешить то, я ж говорю - скорость падает даже не при совместной работе, второму пользователю достаточно подцепиться к базе и всё становится резко плох
Работает пользователь локально с базой - скорость формирования отчёта скажем 10 секунд.
Подключается сетевой пользователь - у него скорость формирования отчёта секунд 15.
Подключается второй сетевой пользователь - отчёт формируется минуты две... Даже при неработающем, только подключенном первом сетевом пользователе.
Так и должно быть ?
Почти так и должно быть.
Однажды я проводил измерения на своем предприятии по этому поводу. Сеть - 100Mb, сервер W2K SERVER (only TCP/IP), клиенты Win98. Было замечено и проверено, что когда работает один клиент, то отчеты расчитываются в 3-4 (точно значение не помню) раза быстрее, чем в случае с несколькими клиентами, даже если расчет ведется одним, а другие ничего не делают. Причем скорость как в случае 1+1, так и в случае 1+10 была одинакова. Было зафиксировано снижение трафика. Тогда я запустить виндовый сетевой монитор (на серваке), чтобы посмотреть трафик (что за пакеты бегают по сетке) и все сразу стало понятно. Начну с того, что в Win сетях используется smb протокол для доступа к shared ресурсам. В случае подключения одного клиента трафик выглядел следующим образом:
A) клиент - дай 20 байт с позиции 30 из файла 1
A) сервер - на тебе твои байты и больше не приставай - и так тяжко
B) клиент - а ну дай еще 18 байт с позиции 900 из файла 1
B) сервер - на тебе (ты че, сразу не можешь взять все че надо?)
и т.д
В случае, когда есть подключения нескольких клиентов трафик выглядил следующим образом:
A) клиент - хочу 20 байт с позиции 30 из файла 1
A) сервер - можешь взять (я их временно заблокировал)
A) клиент - дай 20 байт с позиции 30 из файла 1
A) сервер - на тебе твои байты
A) клиент - спасибо за байтики, можешь снять с них блокировку
A) сервер - договорились - блокировка снята
и т.д.
Таким образом, при наличии нескольких клиентов, которые открыли файлы используемые другим клиентом для расчета отчетов, схема взаимодействия с сервером усложняется - необходимо сначала блокировать кусок файла, потом получить данные, потом снять блокировку.
Ради дальнейшего эксперимента был поставлен один клиент W2K Prof на тот же комп, где стоял Win98. Замедление оказалось еще больше, после чего я решил отказаться от перевода клиентов на W2K Prof, но после долгих мучений W2K Prof заработал также как и Win98, хотя должен, вроде, быстрее, так как схема взаимодействия с сервером у W2K Prof немного отличается от схемы Win98 (в W2K некоторые запросы-ответы совмещают в себе несколько запросов-ответов W98). Замедление W2K по сравнению с W89 было устранено за счет удаления всех протоколов кроме TCP/IP. Скоро все клиенты будут под W2K работать - администрить проще, можно несколько БЭСТ-ов запустить, при этом нет DOS ERROR (Win98 -config.sys files<250 ), да и вообще система стабильнее.
Если расчет запускать на СЕРВЕРЕ (там же где БД лежит), то скорость формирования отчета НЕ ЗАВИСИТ от числа подключенных клиентов (но неактивных). Этот факт направил мой взор на технологию "сервер терминалов", однако ничего хорошего из этого не вышло, т.к. БЭСТ это DOS приложение, которое страшно тормозит сервак (P2 400MHz) так, что другие пользователи испытывают тормоза даже при простом пролистовании списков документов.
В будующем планируется приобрести 2-х процессорный сервак, чтобы держать на нем файловый сервер + возможность нескольким (2-3) клиентам работать в терминальном режиме для формирования "долгих" отчетов). К примеру, по сети отчет формировался ~30 минут, на самом сервере в терминальном режиме - меньше минуты.
Думаю, что такую производительность не даст даже Nowell. Интересно, а какой механизм запрос-ответов (и блокировок) используется в Nowell?
P.S Разница получалась еще большая при
- сети 10Mb вместо 100Mb;
- недостаче ОЗУ на сервере для кеширования файлов.
У нас уже достаточно давно часть пользователей работает через NT4TSE + Citrix Metaframe. Частично проблему с загрузкой процессора победили с помощью Tame, сейчас 100% загрузки наблюдается только в собственно момент формирования отчёта. То есть даже десятку пользователей можно достаточно нормально работать на одном двухпроцовом сервере. Правда возникла ещё одна проблема, при полной загрузке процессоров сервера (два одновременно формируемых отчёта) впадают в ступор обычные сетевые пользователи БЭСТ.
То есть даже десятку пользователей можно достаточно нормально работать на одном двухпроцовом сервере. Правда возникла ещё одна проблема, при полной загрузке процессоров сервера (два одновременно формируемых отчёта) впадают в ступор обычные сетевые пользователи БЭСТ.
Именно так - все остальных отдыхают, когда кто-то на серваке работает. А всех посадить на сервак, так время расчетов, думаю, сильно возрастет, так как когда используется файл-сервер, расчет ведется локально на клиентских тачках, а когда все на серваке, то все расчеты ведет сервак - даже если 2-х проц, все равно 15 компов CEL400 должны "сделать" сервак.
Можно 10 посадить, но только, если они не будут запускать расчетов, иначе кранты, а сажать для ввода данных на терминал - смысла нет.(только если удаленные пользователи - модем, инет).
А у вас что быстрее - если все 10 запустят отчет на серваке (терминал) или локально (файл-сервер)?
10 одновременно запустивших отчёт не получится. Ибо 1 отчёт - 1 процессор, все остальные будут ждать в очереди.
Я говорил про 10 одновременно работающих, не генерящих отчёты, отчёты - по очереди Тогда плюс-минус на правду похоже, но слабенькую.
Отчеты по очереди - это круто . Один бух другому звонит и говорит "я сейчас отчетик на 20 минут закручу, а вы пока покурите" - так не пройдет.
А вот идею о делении программы на два куска - основной и модуль отчетов я уже предлагал. При этом модуль формирования отчетов - это сервис без интерактивного взаимодействия, принимает запрос от клиента, расчитывает отчет и выдает его клиенту. 32-х битный, многопоточный, с возможностью удаленного администрирования, с поддержкой нескольких клиентских подключений. Еще, если такой сервис устанавливать на несколько тачек, то неплохо бы организовать балансинг нагрузки.
А что, есть алгоритмы формирования отчетов в открытом виде (на основе БД БЕСТ)? А то пока в структуре БД разберешься, крыша может поехать, да даже если разберешься - все не учтешь не имея информации от разработчика. А если структура БД поменяется, пусть даже немного, то свой софт переделывать придется
GaMaK wrote:
Сейчас думаем мысль вообще убрать генерение отчётов с БЭСТ-а. Пускай внешняя програмка мучает dbf-ки, более по умному, нежели чем БЭСТ.
И как вы эту мысль думаете? Свой софт писать будете?
Отчеты по очереди - это круто . Один бух другому звонит и говорит "я сейчас отчетик на 20 минут закручу, а вы пока покурите" - так не пройдет.
Дык пущай кричат, у нас они в одной комнате сидят, здоровой правда... Голосовые связки заодно разовьют А вообще - если попробовать понизить приоритет у БЭСТ-овских задач, запускаемых непосредственно на сервере, чтобы они сетевых пользователей не обижали...
Magistr wrote:
А вот идею о делении программы на два куска - основной и модуль отчетов я уже предлагал. При этом модуль формирования отчетов - это сервис без интерактивного взаимодействия, принимает запрос от клиента, расчитывает отчет и выдает его клиенту. 32-х битный, многопоточный, с возможностью удаленного администрирования, с поддержкой нескольких клиентских подключений. Еще, если такой сервис устанавливать на несколько тачек, то неплохо бы организовать балансинг нагрузки.
Предлагать то легко... А вот насчёт сделать
Magistr wrote:
А что, есть алгоритмы формирования отчетов в открытом виде (на основе БД БЕСТ)? А то пока в структуре БД разберешься, крыша может поехать, да даже если разберешься - все не учтешь не имея информации от разработчика. А если структура БД поменяется, пусть даже немного, то свой софт переделывать придется
Да вроде как у хлопцев наших получается что-то плюс-минус... Да и изрядно намаявшись с этим счастьем по имени БЭСТ, есть страшной силы желание через годик уйти на что-нибудь значительно более другое.
Magistr wrote:
GaMaK wrote:
Сейчас думаем мысль вообще убрать генерение отчётов с БЭСТ-а. Пускай внешняя програмка мучает dbf-ки, более по умному, нежели чем БЭСТ.
И как вы эту мысль думаете? Свой софт писать будете?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
), да и вообще система стабильнее.
Тогда плюс-минус на правду похоже, но слабенькую.
А вообще - если попробовать понизить приоритет у БЭСТ-овских задач, запускаемых непосредственно на сервере, чтобы они сетевых пользователей не обижали...
