Лучшая методология для оценки архитектуры программного обеспечения / тестировать атрибуты программного обеспечения, такие как «масштабируемость» без каких-либо подробностей?

Question

Я хочу оценить программное обеспечение, не выполняя детальное тестирование системы.Например: я не хочу тестировать, может ли мое программное обеспечение выдерживать максимальную задержку в 20 мс.Я хочу доказать, что производительность моего программного обеспечения является масштабируемой (по своему замыслу).Какая методология будет подходящей?

Answer 1

Масштабируемость - это способность программного обеспечения продолжать работать приемлемым образом, когда система продолжает увеличиваться с точки зрения различных факторов. Например:

• Данные: увеличение размера данных, которые система сохраняет или обрабатывает.

• Трафик: увеличивается объем входящего / исходящего трафика

• Пользователи: рост числа активных пользователей и, следовательно, одновременных подключений

• Новые функции / операции. Увеличение числа функций / операций, поддерживаемых системой. Хотя этот фактор может попадать в расширяемость, он иногда может влиять на масштабируемость.

Насколько я понимаю, вы хотите доказать, что программное обеспечение является масштабируемым, но вам не нужно доказывать конкретные показатели, которые система сможет поддерживать. Одним из подходов может быть выявление ВСЕХ потенциальных узких мест, которые могут возникнуть, когда система станет больше, документировать эти узкие места, а затем задокументировать / продемонстрировать, что программное обеспечение сможет преодолеть эти узкие места. Сбор метрик может быть более трудоемким, что, как вы упомянули, не требует больших усилий, но выполнение высокоуровневого нагрузочного теста и наглядная демонстрация того, что система способна справиться с нагрузкой, может быть одним из способов. Не уверен насчет вашей конкретной ситуации, но надеюсь, что это поможет.

Answer 2

Масштабируемость - это все о теории ограничений. Нахождение дроссельных точек системы и понимание того, что требуется, чтобы ослабить эти дроссельные точки. Очень сложно понять масштабирование производительности системы без глубокого понимания всей функциональности, чтобы проанализировать эти ограничения.

Обычно ограничения связаны с состоянием и его перемещением из одной части системы в другую. Чем более атомарно и централизованно управляется это состояние, тем больше вероятность того, что оно станет ограничением. Для большинства систем это какая-то база данных, но для некоторых это могут быть другие ресурсы, такие как часть состояния в памяти или другой ресурс. Если это стало децентрализованным, и ограничение снято, оно становится в большей степени ограничением, перемещающим состояние во внешние части системы (например, в браузер или приложение).

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