Какой совет можно дать мне для записи значимого сравнительного теста?
Хотя я и согласен с замечаниями о том, что вопрос сформулирован недостаточно хорошо, я дам вам решение. Не стесняйтесь добавлять дженерики, чтобы сделать его более красивым.
public class Car {
static class CarConfig {
int x;
int y;
CarConfig(int x, int y) {
this.x = x;
this.y = y;
}
}
private final Engine engine;
public Car(int x, int y) {
this(new CarConfig(x, y));
}
Car(CarConfig config) {
this.engine = createEngine(config);
}
protected Engine createEngine(CarConfig config) {
return new Engine(config.x ,config.y);
}
}
Тогда в вашем подклассе:
public class FastEngine extends Engine {
public FastEngine(int x, int y, double a, double b) {
super(x, y);
// (...)
}
// (...)
}
public class FastCar extends Car {
static class FastCarConfig extends CarConfig {
double a;
double b;
FastCarConfig(int x, int y, double a, double b) {
super(x, y);
this.a = a;
this.b = b;
}
}
private final double a;
private final double b;
public FastCar(int x, int y, double a, double b) {
super(new FastCarConfig(x, y, a, b);
this.a = a;
this.b = b;
}
@Override
protected Engine createEngine(CarConfig config) {
if (config instanceof FastCarConfig) throw new IllegalStateException("You messed up!");
FastCarConfig c = (FastCarConfig) config;
return new FastEngine(c.x, c.y, c.a, c.b);
}
}
B O O M!
5 ответов
Ваш вопрос довольно широк, поэтому к сожалению, мой ответ не будет очень конкретен также.
Во-первых, сравнительное тестирование трудно. Не недооценивайте усилие, необходимое для создания значимый, повторяемый, результаты высокой уверенности.
Во-вторых, какова Ваша цель производительности? Это - пропускная способность (транзакция в секунду или операции в секунду)? Это - задержка (время, которое требуется для выполнения транзакции)? Вы заботитесь о средней производительности? Я забочусь о худшей производительности случая? Вы заботитесь об абсолютном худшем случае, или я забочусь, что 90%, 95% или некоторая другая процентиль получают соответствующую производительность?
В зависимости от которой цели Вы имеете, затем необходимо разработать сравнительный тест для измерения против той цели. Так, если Вы интересуетесь пропускной способностью, Вы, вероятно, хотите отправить сообщения / транзакции / вход в Вашу систему на предписанном уровне и видеть, поддерживает ли система на высоком уровне.
Если бы Вы интересуетесь задержкой, Вы отправили бы сообщения / транзакции / вход и имели бы размеры, сколько времени это берет для обработки каждого.
Если Вы будете интересоваться худшей производительностью случая, то Вы добавите загрузку в систему до до того, что Вы считаете "реалистичными" (или независимо от того, что проектирование системы говорит, что должно поддерживать.)
Во-вторых, Вы не говорите, будут ли эти модули зависящими от ЦП, связанный ввод-вывод, если они могут использовать в своих интересах несколько центральных процессоров/ядер и т.д. Поскольку Вы пытаетесь оценить различные аппаратные решения, можно найти, что приложение извлекает выгоду больше из большой подсистемы ввода-вывода по сравнению с огромным количеством центральных процессоров.
В-третьих, лучший сравнительный тест (и самое твердое) должен создать реалистическую нагрузку в систему. При значении Вы записываете данные из продуктивной среды и проводите новое аппаратное решение через эти данные. Получение сделанный более тверд, чем он, звучит, часто, это означает добавлять все виды точек меры в системе, чтобы видеть, как это ведет себя (если у Вас уже нет их), изменение существующей системы для добавления записи/возможностей воспроизведения, изменение воспроизведения для выполнения на различных уровнях и получении реалистического (т.е. подобный производству) среда для тестирования.
Самый значимый сравнительный тест должен иметь размеры, как Ваш код работает при повседневном использовании. Это, очевидно, предоставит Вам самые реалистические числа.
Выберите несколько реальных наборов данных и проведите их посредством тех же процессов, Ваш org использует каждый день. Для дополнительного кредита говорите с людьми, которые используют Вашу платформу и просят, чтобы они обеспечили некоторый "лучший случай", "нормальный", и данные "худшего случая". Анонимизируйте данные, если существуют проблемы конфиденциальности, но пытаются не изменить что-нибудь, что могло бы влиять на производительность.
Помните, что Вы сравниваете и сравниваете два набора аппаратных средств, не Вашу платформу. Рассматривайте все программное обеспечение как черный квадрат и просто измерьте аппаратный уровень.
Наконец, полагайте, что сохранение наборов данных и использование их так же оценивают любые более поздние изменения, которые Вы вносите в программное обеспечение.
Если Вы - система, как, предполагается, может обработать несколько клиентов весь вызов одновременно, то Ваш сравнительный тест должен отразить это. Обратите внимание, что некоторые вызовы не будут играть хорошо вместе. Например, наличие 25 потоков отправляет тот же бит информации, одновременно мог привести к, соединяет конец сервера, таким образом скашивая Ваши результаты.
С основной точки зрения я использовал Perl и его модуль Сравнительного теста для сбора информации, о которой я забочусь.
Если Вы сравните отличающиеся аппаратные средства, то измерение стоимости на транзакцию даст Вам хорошее сравнение торговли offs аппаратных средств для производительности. Одна конфигурация может дать Вам лучшую производительность, но стоит слишком много. Менее дорогая конфигурация может дать Вам соответствующую производительность.
Важно эмулировать "худший случай" или "час пик" загрузки. Также важно протестировать с "типичными" объемами. Это - уравновешивание для получения хорошего использования сервера, которое не стоит слишком много, которое дает необходимую производительность.
Тестирование через аппаратные конфигурации быстро становится дорогим. Другой жизнеспособный вариант состоит в том, чтобы сначала иметь размеры на конфигурации, Вы имеете, затем моделируете то поведение через виртуальные системы с помощью модели.
Если Вы можете, попытаться записать некоторых операционных пользователей (или процессы) делают с Вашей платформой, идеально с помощью клона реальной системы. Это дает Вам самые реалистические данные. Вещи рассмотреть:
- Какие функции чаще всего используются?
- Сколько данных передано?
- Ничего не принимайте. Если Вы думаете, что "это будет быстрым/медленным", не держат пари на нем. В 9 из 10 случаев, Вы неправы.
Создайте лучшие десять для 1+2 и работа от этого.
Это сказало: при замене старых аппаратных средств новыми аппаратными средствами можно ожидать примерно на 10% более быстрое выполнение в течение каждого года, который передал, так как Вы купили первый набор (если системы в других отношениях симпатичны равный).
Если у Вас есть специализированная система, числа могут полностью отличаться, но обычно, новые аппаратные средства не изменяются очень. Например, добавление полезного индекса к базе данных может уменьшить время выполнения запроса с двух часов до двух секунд. Аппаратные средства никогда не будут давать Вам это.