информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Страшный баг в WindowsПортрет посетителя
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / sysadmin
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
... несколько но 15.10.03 12:19  Число просмотров: 1328
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 15.10.03 12:21  Количество правок: 1
<"чистая" ссылка>
> довольно трудно будет синхронизировать все эти действия -
> начать одновременное копирование с нескольких клиентов+на
> других начать генерацию отчетов+загрузить запросами БД
Если тестовая задачка будет выполняться несколько десятков минут, то "неодновременность" в пределах одной минуты сильно на результаты не повлияет.
В минуту вложиться легко, если расстояние между рабочими станциями будет порядка нескольких метров, а не километров.
Можно привлечь "сообщника" в помощь.
Если сеть размеров малого предприятия (до сотни РС), достаточно параллельно загрузить тестированием в пределах десятка РС.
Можно батник запустить (циклические ожидание появления/удаления файла на общем ресурсе, потом запуск теста).
Глобального роста производительности ждать не следует, поскольку можно просто упереться в пропускную способность "железа", поскольку любой "свежий" сервак под любой ОС и так спокойно отработает трафик стомегабитной сети. Затыки будут не в серваке. А если это ЭсКуЭЛь сервер, и одним запросом он должен перелопатить гигабайт информации, то все упрется в винт. А если у него море ОЗУ, то в скорость процессора.
Я еще лет пять назад слышал, что Самба (маленькая, простенькая, бесплатная) легко делает родную ВинНТ.
По субъективным ощущениям я просто плююсь от тормознутости Вин2000 и, думаю, от этого тошнит многих, кто перед тем, как попробовать Вин200, поработал с другими сетевыми ОС. Причем тормознутость Вин2000, по-моему, заключается в НТФС, поскольку без сети аналогично тормозит. Или Джава там тормозная, а точнее распределение/высвобождение памяти в ней (это для локальных операций).
<sysadmin>
Чем сравнить быстродействие samba3 и wink2srv? 14.10.03 18:52  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
Вопрос возник после прочтения этого http://www.vnunet.com/News/1144289. Захотел проверить - на одной тачке с w2ksrv подниму linux. Каким бы тестом померять (чтобы серверная часть была и под linux и под форточки)? NetBench ведь тока под форточки :-((
Чем сравнить быстродействие samba3 и wink2srv? 15.10.03 12:03  
Автор: Cyril <sc> Статус: Member
<"чистая" ссылка>
> Вопрос возник после прочтения этого
> http://www.vnunet.com/News/1144289. Захотел проверить - на
> одной тачке с w2ksrv подниму linux. Каким бы тестом
> померять (чтобы серверная часть была и под linux и под
> форточки)? NetBench ведь тока под форточки :-((
Может я чего то не правильно понял, но что почему ты решил, что NetBench
под форточки

The NetBench test environment

NetBench's test environment requires:(требования)

A File Server. The file server provides the shared file storage facilities to the clients. NetBench's clients create their test files on the file server.
(файл сервер. Предоставляет доступ к файлам клиентов, насколько я понял никаких программ от из пакета NetBench устанавливать не надо)

The Controller. The controller is a PC running Windows NT or Windows 2000. NetBench doesn't run tests on the controller or count the controller as a client in the tests. Instead, you use the controller to select the test suites NetBench will execute, start the test run, monitor how the tests are going, and view the test results. (Просто комп который управляет тестами)

The Clients. Clients are Windows 95/98, Windows NT, or Windows 2000 PCs that send requests for network file operations to the server. The clients run the tests. You can have up to 1,000 clients, but because NetBench uses stress tests, you can get accurate results with just a few clients. NetBench's standard test suites use a maximum of 60 clients. (Клиенты, тачки с виндами)

The Network Protocol. The network protocol (or protocols, if you use more than one) is the piece of NetBench's test environment that connects the different machines used in the benchmark tests. The NetBench clients and controller require TCP/IP to communicate. The NetBench client will also use whatever protocol your server requires for file services - for example, IPX or NetBIOS.
даже не знаю что сказать... 15.10.03 12:16  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
невнимательно прочел описание :-(( Действительно - NetBench Controller всего лишь управляет клиентами, т.е. тесты проводятся на другом файл сервере.
ЗаЧем сравнивать быстродействие samba3 и wink2srv? 15.10.03 10:37  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 15.10.03 10:43  Количество правок: 1
<"чистая" ссылка>
> Вопрос возник после прочтения этого
> http://www.vnunet.com/News/1144289.
Ведь можно просто поверить тем, кто это уже делал.
Если же это не для чисто "спортивного" интереса, а возникло желание что-то поменять на более производительное, то нужно тест погонять соответствующий.
Например.
Если Вы этот сервак под базу заряжаете - то надо базу и погонять на нем. Причем, если конкретно 1С, то именно 1С и гонять. Если под хранилище документов - надо покидать на него и подергать с него много маленьких файлов.
Если комплексный тест говорит, что производительность систем одинакова, то это еще ничего не значит, поскольку 1С может работать быстрее раза в три, а копирование файлов во столько же раз тормозить.
Абстрактные тесты тоже мало чего говорят (время доступа, задержки, время поиска...).
Формируем тестовую задачу. Создаем маленьких файлов на несколько гигабайт или достаем многогигабайтную 1С базу. Качаем файлы туда-сюда или генерим отчет по 1С. Засекаем время по наручным часам. Чтобы минимизировать погрешность измерения тест должен идти долго (десятки минут) и в сети никто из пользователей не должен работать, кроме тестовых компьютеров (ни на этом сервере, ни просто в сети).
одно но... 15.10.03 11:17  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
довольно трудно будет синхронизировать все эти действия - начать одновременное копирование с нескольких клиентов+на других начать генерацию отчетов+загрузить запросами БД

> Формируем тестовую задачу. Создаем маленьких файлов на
> несколько гигабайт или достаем многогигабайтную 1С базу.
> Качаем файлы туда-сюда или генерим отчет по 1С. Засекаем
> время по наручным часам. Чтобы минимизировать погрешность
> измерения тест должен идти долго (десятки минут) и в сети
> никто из пользователей не должен работать, кроме тестовых
> компьютеров (ни на этом сервере, ни просто в сети).
... несколько но 15.10.03 12:19  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 15.10.03 12:21  Количество правок: 1
<"чистая" ссылка>
> довольно трудно будет синхронизировать все эти действия -
> начать одновременное копирование с нескольких клиентов+на
> других начать генерацию отчетов+загрузить запросами БД
Если тестовая задачка будет выполняться несколько десятков минут, то "неодновременность" в пределах одной минуты сильно на результаты не повлияет.
В минуту вложиться легко, если расстояние между рабочими станциями будет порядка нескольких метров, а не километров.
Можно привлечь "сообщника" в помощь.
Если сеть размеров малого предприятия (до сотни РС), достаточно параллельно загрузить тестированием в пределах десятка РС.
Можно батник запустить (циклические ожидание появления/удаления файла на общем ресурсе, потом запуск теста).
Глобального роста производительности ждать не следует, поскольку можно просто упереться в пропускную способность "железа", поскольку любой "свежий" сервак под любой ОС и так спокойно отработает трафик стомегабитной сети. Затыки будут не в серваке. А если это ЭсКуЭЛь сервер, и одним запросом он должен перелопатить гигабайт информации, то все упрется в винт. А если у него море ОЗУ, то в скорость процессора.
Я еще лет пять назад слышал, что Самба (маленькая, простенькая, бесплатная) легко делает родную ВинНТ.
По субъективным ощущениям я просто плююсь от тормознутости Вин2000 и, думаю, от этого тошнит многих, кто перед тем, как попробовать Вин200, поработал с другими сетевыми ОС. Причем тормознутость Вин2000, по-моему, заключается в НТФС, поскольку без сети аналогично тормозит. Или Джава там тормозная, а точнее распределение/высвобождение памяти в ней (это для локальных операций).
Было бы очень интересно узнать результаты тестирования... 15.10.03 06:29  
Автор: alien <Андрей> Статус: Member
<"чистая" ссылка>
..., особенно такие параметры, как объемы ОЗУ и количество процессорного времени, которые кушает Samba. Ну и конечно же разницу в скорости файловых операций между W2k и Samba.
http://www.itweek.co.uk/ITWeek/itw_graph_1144289.jsp не смотрел? 15.10.03 09:31  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
> ..., особенно такие параметры, как объемы ОЗУ и количество
> процессорного времени, которые кушает Samba. Ну и конечно
> же разницу в скорости файловых операций между W2k и Samba.

Ндя. После того, что я увидел по ссылке, есть горячее желание остановить службу сервера на Win2k и установить порт самбы под винды, но таково в природе нету, к сожалению ;-)

А ещё там говорится, что тюнинга никакого не делалось в этих тестах. Но если учесть, что включен QoS и Reservable Bandwidth и Limit Outstanding Packets и прочая, что включено по умолчанию в 2003 сервере, то может не всё так плохо...
Самопальный метод 14.10.03 20:20  
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
<"чистая" ссылка>
Взять какую-нибудь БД типа Paradox (чтобы таблицы в отдельных файлах хранились), положить на шару, запустить огромный запрос, который использует таблиц 50-100 и много записей. И замерить время.
Самопальный метод 14.10.03 21:32  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Файл-серверную 1С поюзать на обеих и посмотреть разницу.
хотелось бы 15.10.03 10:29  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
проэмулировать работу 20-30 клиентов одновременно
кроме того в предложенных методоах сравать быстродействие придется на глаз, что увеличит поргешность измерений
хотелось бы 15.10.03 12:45  
Автор: Book Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> проэмулировать работу 20-30 клиентов одновременно
> кроме того в предложенных методоах сравать быстродействие
> придется на глаз, что увеличит поргешность измерений
насчет эмулятора не знаю, но если есть 20-30 машин, то на них можно запустить из шедулера в одно время скриптик, который пишет время начала тянет файло с сервера и пишет время конца (сделать это для обоих серверов и сравнить времена)
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach