Можете ли вы оценить производительность приложения перед тестированием? - PullRequest
5 голосов
/ 14 ноября 2008

Это сложный вопрос, который мне задали на днях ... Мы работаем над довольно сложным приложением телефонии (SIP) со смешанным кодом C ++ и PHP с базами данных MySQL и несколькими компонентами с открытым исходным кодом.

Инженер связи попросил нас оценить производительность приложения (которое еще не готово). Он сказал: «Ну, вы знаете, сколько пакетов может проходить через ядро ​​Linux в секунду, плюс вы можете знать, насколько быстро ваше приложение, поэтому скажите мне, сколько вызовов будет проходить через ваши вещи в секунду».

Мне кажется, что это бессмыслица, поскольку возможны миллионы сценариев (ну, буквально ...)

Однако ... есть ли способ оценить производительность приложения (зная оборудование, на котором оно будет работать, возможность запускать стандартные тесты на нем и т. Д.) До фактического тестирования?

Ответы [ 7 ]

6 голосов
/ 14 ноября 2008

Вы, безусловно, можете связать проблему с верхними (максимальными пропускными способностями) ограничениями. В этом нет ничего глупого. Фактически, незнание этих вещей указывает на довольно случайный подход к проблеме - особенно в мире телефонии.

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

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

EDIT

Чтобы выполнить это упражнение, вам необходимо знать все шаги, которые ваше приложение выполняет для каждого варианта использования. Затем вы можете определить максимальную пропускную способность для каждого варианта использования. Вы должны определенно знать этот материал до релиза и выхода в эфир.

Я игнорирую анализ наихудшего случая, поскольку, как вы указываете, это немного сложнее.

3 голосов
/ 14 ноября 2008

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

Это нелегко, и коммерческие инструменты будут вам стоить. Книга Capacity Planning поставляется с компакт-диском с множеством шаблонов книг Excel и примерами моделей, которые помогут вам быстро начать работу.

Удачи:)

2 голосов
/ 14 ноября 2008

Если вам действительно нужно ответить, вы можете сказать что-то вроде этого:

"Я не знаю, насколько это возможно. Я хочу оценить это для вас, но это займет время. Очевидно, точность моего ответа зависит от того, сколько усилий (то есть времени) я приложил к вычислению своего оценка. Сколько времени я должен уделить вычислению моей оценки? "

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

1 голос
/ 07 октября 2009

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

Потратьте некоторое время на размышления об этом. Проанализируйте важные варианты использования. Подумайте о памяти, которая вам может понадобиться; подумать о доступе к базе данных; думать о доступе к сети (локальный и удаленный). Это повлияет на производительность вашей системы. Соберите всю команду вместе, чтобы сделать это.

Регулярно измеряйте производительность вашей системы во время разработки для этих важных сценариев использования. Макет компонентов / других систем, если вам нужно. Проанализируйте результаты. Как они соотносятся с вашей оценкой? Возможно компоненты связаны с памятью / базой данных / сетью. Может быть, вам нужно больше памяти; меньше доступа к базе данных; более простые запросы; кэширование. Вам не нужно вносить эти изменения сразу. Однако вы знаете, как работает ваша система и что вам нужно делать.

Результат: Меньше неприятных сюрпризов при тестировании системы. Менее паника, так как вырисовывается дата выхода.

1 голос
/ 27 сентября 2009

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

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

  1. С учетом требований к производительности и емкости (т. Е. Аппаратного обеспечения) вы можете рассчитать рабочую нагрузку, с которой вы можете справиться.

  2. Учитывая требования к производительности и рабочую нагрузку, вы можете рассчитать необходимую емкость (т. Е. Аппаратное обеспечение).

  3. Учитывая рабочую нагрузку и емкость, вы можете прогнозировать ожидаемую производительность.

1 голос
/ 14 ноября 2008

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

Помните: прототипы широкие, шипы глубокие.

0 голосов
/ 14 ноября 2008

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

...