Оценка требований к ресурсам рабочей схемы

Оценка необходимых ресурсов является одной из наиболее трудных задач в процессе планирования производительности. Исключение составляет лишь случай, когда был приобретен пакет программ, в документации к которому есть подробный перечень всех необходимых ресурсов.

При решении этой задачи возникают следующие трудности:

Любую задачу всегда можно решить несколькими способами. Например, можно написать программу на языке C (или на любом другом языке высокого уровня), сценарий оболочки, сценарий perl, сценарий awk, сценарий sed, многооконную программу AIX и т.д. Некоторые способы, которые кажутся особенно эффективными с точки зрения разработки алгоритма и создания программы, могут в будущем привести к значительным затратам при эксплуатации программы.
В общем случае закономерность такова закономерность: чем выше уровень абстракции, тем сложнее гарантировать, что не возникнет никаких неожиданных проблем с производительностью. Необходимо всегда учитывать реальный объем данных и число итераций, скрытых в безобидных на вид конструкциях.
Ресурсы, используемые конкретным процессом, определить довольно сложно. Это не только техническая, но также и методическая трудность. Если разные экземпляры данной программы, запущенные несколькими пользователями, совместно обращаются к одним и тем же страницам текста программы, то к какому процессу нужно относить использование этих страниц памяти? Операционная система хранит в кэш-памяти страницы файлов, использованные недавно, чтобы программы могли повторно обращаться в этим данным. Если программа несколько раз обращается к одним и тем же данным, то следует ли учитывать тот объем памяти, который использовался для хранения этих данных? Точность некоторых измерений, например, показаний системных часов, может привести к сложностям при оценке времени использования CPU последовательно запускаемыми экземплярами одной и той же программы.
Существует два подхода к анализу неоднозначных данных, содержащихся в отчете об использовании ресурсов. Первый основан на том, что неопределенности игнорируются, а изменяющиеся величины исключаются из рассмотрения до тех пор, пока в результате измерений не начнут поступать согласованные данные. При втором подходе по возможности измеряются реальные параметры, а для описания результатов применяются статистические методы. Второй подход позволяет получить результаты, которые больше соответствуют реальным условиям.
Случаи, когда в системе выполняется только одна программа, очень редки. Обычно в системе выполняются несколько демонов, обслуживаются активные соединения и одновременно работают несколько пользователей. При этом зависимость объема занятых ресурсов от числа выполняемых операций не линейная. Например, увеличение числа экземпляров программы может привести к использованию только нескольких новых страниц текста программы, поскольку большая часть программы уже была в памяти. В то же время, новый процесс может усилить конкуренцию за использование кэш-памяти процессора. Следовательно, он не только увеличивает конкуренцию за процессорное время, но и приводит к тому, что увеличивается время, затрачиваемое на выполнение одной команды. Это связано с возрастанием числа промахов в кэше, и в итоге приводит к снижению скорости выполнения всех процессов.

При оценке параметров производительности программы постарайтесь быть как можно ближе к реальным условиям, руководствуясь следующими рекомендациями:

Если программа уже существует, то выполните измерения в условиях, максимально приближенных к исходным требованиям. Для этого лучше всего воспользоваться специальным средством для планирования объема необходимых ресурсов, например, планировщиком BEST/1.
Если подходящей системы нет, то установите программу в любой другой системе и попробуйте искусственно создать в ней похожую среду.
Если похожую среду создать не удается, то измерьте отдельные параметры программы и используйте полученные результаты для моделирования.
Если программа еще не создана, то найдите похожую программу с аналогичной структурой, написанную на том же языке программирования, и измерьте ее параметры. Не забудьте, что чем абстрактнее язык, тем осторожнее нужно подходить к вопросу подбора подобных программ.
Если похожую программу найти не удалось, создайте прототип программы с основными алгоритмами на используемом языке программирования, измерьте его параметры и смоделируйте рабочую схему.
Только в том случае, если невозможно сделать никаких практических измерений, можно ограничиться теоретическими оценками. Если объем необходимых ресурсов необходимо определить на стадии планирования, то особенно важно протестировать программу на самых ранних этапах ее разработки.

Обратите внимание, что независимые разработчики программного обеспечения (ISV) часто приводят рекомендации по определению объема ресурсов, необходимых для работы их приложений.

При оценке необходимого объема ресурсов вам должны интересовать четыре параметра:

CPU time: Показатель использования процессора рабочей схемой
Доступ к диску: Частота, с которой рабочая схема генерирует запросы на чтение с диска или запись на диск
Нагрузка на LAN: Число пакетов, генерируемых рабочей схемой, и число байтов, передаваемых при обмене данными
Физическая память: Объем оперативной памяти, необходимой для рабочей схемы

В следующих разделах описано, каким образом можно определить значения этих параметров в различных ситуациях.