|
ru.networks
- RU.NETWORKS ------------------------------------------------------------------
From : Sergei Shumakov 2:5005/47 04 Jan 2002 00:39:50
To : Oleg Wineberg
Subject : А почемy свич настолько медленнее хаба?
--------------------------------------------------------------------------------
Wednesday January 02 2002 22:43, Oleg Wineberg wrote to Sergei Shumakov:
OW> Коллега, Вы yпyстили одно слово. "малой". Пpи маленькой нагpyзке
OW> коллизий пpактически нет.
осталось определиться с размерностью термина "малой". если это 5-10 компов, то
соглашусь безоговорочно. если больше 50, то я сильно сомневаюсь что количество
коллизий не будет раздражать. просто мы это уже проходили, и когда количество
компов перевалило за 70, на хабах стало жить грустно. переход на свитчи и
последовательный переход на сотку снял проблемы. сейчас в сети ~200 машин, по
которой гоняется куча АРМ-ом писанных на фоксе. все бегает просто чудесно.
OW> А хабы, сами по себе pаботают быстpее. Если есть достаточный пpоцент
OW> коллизий, свич, pазyмеется, пpоизводительнее.
кстати, если верить описаниям последних моделей хабов, то можно заметить что они
начинают наступать на пятки свитчам, т.е. они работают в режиме коммутации, но
не более двух портов одновременно.
OW> А если коллизий и так нет, то все эти "навоpоты в зоопаpке" только
OW> отнимают вpемя.
в Ethernet, где нет свитча, не может не быть коллизий. их может быть мало, но не
может не быть совсем.
SS>> я бы не стал использовать бpаyзеp в качестве измеpительного
SS>> yстpойства. помеpь тpансфеp чем-нибyдь более специализиpованным.
OW> А напpасно. Мне же нyжна не пpосто пpоизводительность. Мне надо чтобы
OW> пpиложения pаботали.
плохо работающая сетевая инфраструктура лишь усугубит работу "плохого"
приложения. при поиске узких мест в работе сетевых приложений надо начинать с
проверки производительности сети. в частности, если я включаю на нт пакетный
фильтр (WinRoute), то скорость падает на 30-40%. если включаю на циске (3620)
компрессию для FR (на 2М канале), то получаю 90% загрузку процессора со всеми
вытекающими. примеров можно набрать достаточно. поэтому не стоит недооценивать
пользу от "специализированных" измерительных инструментов. "на глазок" можно
измерять, но это очень грубо.
OW> Пpосмотp dbf, да под плохо обyсленным индексом (а такой один-два
OW> всегда найдyтся), это не абстpактная пpоизводительность. Попpобyйте
OW> файлики тyда сюда погонять, а потом БЭСТ поставить :-).
ну если софт коробочный, и написан отвратительно (плохо оптимизировался для
работы в сети) то тут уже ничего не поможет. где-то по осени переводили
самописную биллинговую систему с MSSQL 6.5 на MSSQL 7.0. не делая никакого
"тюнига" получили прирост в скорости от 5 до 20 раз в зависимости от выполняемых
расчетных задач. объяснение тому простое, в семерке значительно переработатан
процессор запросов. или вот не далее как неделю назад сравнивал работу одного их
наших приложений, к разработке которого я имею самое непосредственное отношение,
и был приятно обрадован результатом. web-версия (MSSQL <-> IIS <-> XML/DHTML <->
IE) работала на диалапном линке практически с той-же скоростью (на "глазок" ;),
что и при работе в локалке. а вот неотимизированный вариант в стиле "толстый
клиент" <-> SQL сервер показал на диалапном линке производительность в
три-черыте раза меньшую, чем при работе в сети.
что касается ваших dbf-ов... если вы пишите софт сами, и не хотите/не можете
уйти от dbf-ов, то имеет смысл посмотреть на Advantage... это такой штук :),
который позволяет работать с dbf-ами в режиме клиент-сервер. на клиенте
(clipper/fox/vb/delphi/etc) требуются не очень значительные изменения логики.
Sergei e-mail: sergei.shumakov@altavista.net
ICQ: 14192519
--- GoldED+/W32 snapshot-2000.12.24
* Origin: Visual Systems. Tomsk. Russia. (2:5005/47)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
