Если для проведения измерений существующая система не доступна, часто оказывается возможной примерная оценка, основанная на предполагаемом использовании системы. Выполнение такой оценки требует понимания того, каким объемом данных будет манипулировать клиент. Этот метод достаточно точен, если приложение попадает в категорию систем с интенсивным использованием данных. Некоторая разумная оценка обычно может быть также сделана и для среды с интенсивным использованием атрибутов, но множество факторов делает такую оценку несколько менее точной.
Первый шаг для получения такой оценки заключается в определении полностью активного запроса типового клиента. Для этого необходимо понимание поведения клиента. Если нагрузка интенсивная по данным, то имеет смысл просто просуммировать количество предполагаемых операций чтения и записи и взять это число в качестве нагрузки для каждого клиента. Операции с атрибутами обычно являются несущественными для рабочей нагрузки, в которой доминируют операции с данными (с одной стороны, они составляют лишь небольшой процент всех операций, а с другой стороны, эти операции задают серверу минимальное количество работы по сравнению с объемом работы, который необходимо выполнить для выборки данных).
Например, рассмотрим клиентскую рабочую станцию, выполняющую приложение, которое осуществляет поиск областей с заданной температурой в некотором объеме жидкости. Типовой набор данных для решения этой задачи составляет 400 Мбайт. Обычно он читается порциями по 50 Мбайт. Каждая порция проходит полную обработку прежде, чем приложение переходит к следующей. Обработка каждого сегмента занимает примерно 5 минут времени ЦП, а результирующие файлы, которые записываются на диск имеют размер около 1 Мбайта. Предположим, что в качестве сетевой среды используется FDDI. Максимальная нагрузка на NFS будет возникать, когда клиент читает каждую порцию объемом 50 Мбайт. При максимальной скорости 2.5 Мбайт/с клиент будет полностью активным примерно в течение двадцати секунд, выполняя 320 операций чтения в секунду. Поскольку каждый запуск программы занимает примерно 40 минут (или 2400 секунд) времени, и на один прогон требуется (400 + 1) Мb х 125 ops/Mb = 50,125 ops, средняя скорость равна примерно 20 ops/sec. Сервер должен будет обеспечивать обслуживание пиковой скорости запросов (320 ops/sec) в течение примерно 20 секунд из каждых 5 минут, или примерно в течение 7% времени. Из этого упражнения можно извлечь три порции полезной информации: среднюю скорость активных запросов (20 ops/sec), пиковую скорость запросов (320 ops/sec) и вероятность того, что пиковая скорость требуется. На базе этой информации может быть сформирована оценка общей скорости запросов. Если в конфигурации системы будет 10 клиентов, то средняя скорость запросов составит 200 ops/sec. (Эту скорость не следует сравнивать с результатами теста LADDIS, поскольку в данном случае смеси операций очень отличаются). Вероятность того, что два клиента будут требовать работы с пиковой скоростью одновременно составляет примерно 0.07 х 0.07 = 0.049, или примерно 5%, а три клиента будут требовать пикового обслуживания только в течение 0.034% времени. Таким образом, из этой информации разумно вывести следующие заключения:
Заметим, что при выборе конфигурации системы для приложений с интенсивным использованием данных вообще говоря не очень полезно сравнивать предполагаемые скорости запросов с рейтингом предполагаемого сервера по SPECsfs_097, поскольку смеси операций отличаются настолько, что нагрузки нельзя сравнивать. К счастью, такая оценка обычно оказывается достаточно точной.
В предыдущем примере предполагалось, что нагрузка NFS от операций с атрибутами была пренебрежимо мала по сравнению с операциями с данными. Если же это не так, например, в среде разработки программного обеспечения, необходимо сделать некоторые предположения относительно предполагаемой смеси команд NFS. В отсутствии другой информации, в качестве образца можно принять, например, так называемую смесь Legato. В тесте SPECsfs_097 (известной также под названием LADDIS) используется именно эта смесь, в которой операции с данными включают 22% операций чтения и 15% операций записи.
Рассмотрим клиентскую рабочую станцию, наиболее интенсивная работа которой связана с перекомпиляцией программной системы, состоящей из исходного кода объемом 25 Мбайт. Известно, что рабочие станции могут скомпилировать систему примерно за 30 минут. В процессе компиляции генерируется примерно 18 Мбайт промежуточного объектного кода и двоичные коды. Из этой информации мы можем заключить, что клиентская система будет записывать на сервер 18 Мбайт и читать по крайней мере 25 Мбайт (возможно больше, поскольку почти треть исходного кода состоит из файлов заголовков, которые включены посредством множества исходных модулей). Для предотвращения повторного чтения этих файлов включений может использоваться кэширующая файловая система. Предположим, что используется CFS. Во время "конструирования" необходимо передать 33 Мбайт действительных данных, или 33 Мb х 125 ops/Mb = 4125 операций с данными за 30 минут (1800 секунд), что примерно соответствует скорости 2.3 ops/sec. (Здесь предполагается, что каждая операция выполняется с данными объемом 8 Kb, поэтому для пересылки 1 Mb данных требуется 125 операций). Поскольку эта работа связана с интенсивным использованием атрибутов, необходимо оценить существенное количество промахивающихся операций с атрибутами. Предположив, что смесь операций соответствует смеси Legato, общая скорость будет примерно равна:
Объем читаемых данных * 125NFSops/sec = или
22%
Объем записываемых данных * 125
NFSops/sec = .
15%
В данном случае скорость равна: (25 Мb по чтению х 125ops/Mb) / 22% / 1800 секунд, или 7.89 ops/sec. Для проверки мы также имеем (18 Мb по записи х 125 ops/Mb) / 15% / 1800 секунд, или 8.33 ops/sec. В данном случае соотношение операций чтения и записи очень похоже на смесь Legato, но это может быть и не так, например, если были открыты файлы программы просмотра исходного текста (размер файлов программы просмотра исходного текста (source brouser files) часто в 4-6 раз превосходит размер исходного кода). В этом случае у нас нет способа оценки пиковой нагрузки.
Если имеются двадцать рабочих станций, работающие в описанном выше режиме, мы можем составить следующие заключения:
Таблица 4.3. Показатели LADDIS для различных NFS-серверов Sun под управлением Solaris 2.3. Немного (на 5%) более высокие скорости достижимы при использовании FDDI,
немного меньшие скорости - при использовании 16 Мбит Token Ring.