Определение SLA для сервисов WCF

Question

Мне нужно протестировать производительность / нагрузку кучей взаимозависимых сервисов. Все они используют net.tcp и большинство используют дуплексные контракты и внутренние очереди. [управляемый класс очереди POCO с использованием блокировки (syncRoot) {if (queue.Empty) Thread.Wait (); }] * * Тысяча одна

Вот подход, который я придумал:

1. Определение служб WCF для тестирования производительности
2. Определите соответствующие счетчики производительности для каждой из услуг
3. Определите логическую начальную точку, которая будет выполнять выполнение через тестируемые сервисы
4. Автогенерация модульных тестов с использованием VS.Net для каждой из служб
5. Написание конкретных функциональных тестов (например, я могу взять пример использования - «Разместить заказ» - и написать тесты, которые выполняют все вызовы к соответствующим службам и, как правило, выполняют практически все необходимые функции)
6. Используйте файлы трассировки из # 5 для генерации модульных тестов [с использованием нагрузочного теста WCF из CodePlex] (мне как-то кажется, что это идеальный инструмент для воссоздания пользовательских ошибок в рабочей среде / поле в среде отладки. Отказ от ответственности: инструмент. Впечатления от прочтения проекта desc)
7. Тесты, приведенные выше, можно настроить для выполнения вызовов с автоматически сгенерированными входными данными
8. Ввести варианты ввода, чтобы различные пути кода были учтены
9. Регистрация данных от счетчиков производительности
10. Анализ и выявление узких мест

Вопросы:

1. Есть ли лучший подход?
2. В случае служб, использующих внутренние очереди, измерение производительности с использованием стандартных счетчиков производительности является проблемой. Может мне понадобятся нестандартные счетчики?
3. Если # 1 верно, есть ли способ ввести счетчики клиентов без изменения кода тестируемых сервисов?
4. Должен ли я заботиться о результатах моих функциональных тестов?
5. Есть ли способ [ненавязчиво] внедрить SLA для служб WCF? (Я думаю, что если у меня достаточно данных с моих счетчиков, таких как обслуживаемые запросы, возникшие исключения, время ответа и т. Д., Я смогу проверить мой SLA - обработать 200 000 запросов в течение 5 минут с временем ответа 2 секунды для каждого запроса - против этих цифр. Мой вопрос, возможно, заключается в том, могу ли я просто указать свой SLA, а продукт / инструмент может выполнить всю сантехнику за сценой и получить мне табличный ответ? Я знаю ... Я знаю ... Я мечтал день :))
6. В сторону: Каков наилучший метод для внутренней очереди запросов в службе WCF?

Answer 1

Ого ... название определенно было верхушкой айсберга! Надеюсь, я не оторвусь от своих ответов здесь! :)

1. тестирование производительности сервисов WCF может быть выполнено многими различными способами: с помощью инструментов тестирования, таких как Microsoft Team Test, Borland Silk Performer, Mercury LoadRunner, или чего-то подобного LoadGen или специального тестового жгута. Я предпочитаю использовать подход, который вы использовали при создании своего рода функционального модульного теста, а затем вводить данные в этот тест, в то же время используя инструмент тестирования для ускорения нескольких одновременных экземпляров этого теста (виртуальные «пользователи»). , Инструменты большинства коммерческих инструментов тестирования действительно облегчают этот тип тестирования, поэтому здесь сложно ошибиться. Самая большая проблема обычно возникает из-за поддержки тестовых случаев и тестовых данных для поддержки тестирования приложения.

2. WCF не имеет встроенных счетчиков, связанных с производительностью. Это на самом деле слепое пятно. Конечно, вы можете видеть, сколько подключений выполняется к серверу, но это грубая информация, и вы, вероятно, хотите знать, какие службы обслуживают эти запросы. По слухам, Microsoft «Дублин», как часть обеспечения богатой среды размещения для WCF / WF, будет включать счетчики производительности для размещенной службы. Нам придется подождать и посмотреть, что на самом деле вытряхивает.

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

4. Да. Я хотел бы заботиться о результатах (имеется в виду производительность?) Функционального теста. Предостережение заключается в том, что существует вероятность запуска (JIT), который можно игнорировать. Я бы, вероятно, посмотрел в профиль выполнения функционального теста, чтобы получить метрики выполнения - но я не включил профилирование кода во время выполнения производительности.

5. Для SLA снова пользовательское поведение может быть ответом. Вы можете записать операционные показатели в базу данных, а затем сообщить об этом. Коммерческие продукты, такие как Amberpoint и SOA Software, также обеспечат поддержку (включая счетчики производительности).

6. Очередь запросов к сервису wcf? Я сразу думаю о связывании net.msmq, особенно если вы хотите, чтобы запрос был длительным.