Тестирование производительности - сколько данных я должен создать - PullRequest
3 голосов
/ 16 февраля 2010

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

Я работаю в системе клиент-сервер, которая использует серверную часть SQL. Приложение представляет собой огромное налоговое приложение, которое требует тестирования производительности при пиковой нагрузке. Это означает, что в системе должно быть около 10 миллионов налоговых деклараций, когда мы запускаем сценарии, связанные с созданием и подачей налоговых деклараций. Тогда будет также пропорциональное количество пользователей, которые должны быть созданы.

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

Когда говорят о создании меньшего набора данных и экстраполяции планирования производительности, я слышу очень распространенный ответ: нам нужно 10 миллионов записей, потому что мы не можем определить из меньшего набора данных, как будет вести себя база данных или сеть. *

Итак, как можно планировать емкость и тестировать производительность в крупных корпоративных приложениях, не создавая пиковый уровень данных или не выполняя пиковое число сценариев?

Спасибо.

Ответы [ 6 ]

3 голосов
/ 16 февраля 2010

Лично я бы выбрасывал как можно больше данных и трафика. Забудьте, какой трафик вы «считаете нужным обработать». И просто посмотрите, сколько трафика вы МОЖЕТЕ обработать и идти оттуда. Знание границ вашей системы более ценно, чем просто знание того, что она может обрабатывать 10 миллионов записей.

Возможно, он справляется с 10 миллионами, но при 11 миллионах умирает ужасной смертью. Или, может быть, это хорошо написано и будет масштабироваться до 100 миллионов, прежде чем он умрет. Существует очень четкое различие между этими двумя, даже если оба они проходят "тест 10 миллионов"

2 голосов
/ 16 февраля 2010

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

Почему ты так думаешь?

Конечно, вы можете (и должны) проводить тестирование с ограниченным количеством данных, но вам также действительно действительно нужно тестировать с реалистичной нагрузкой, что означает тестирование с количеством (и типом) данных. что вы будете использовать в производстве.

Это всего лишь частный случай общего правила: для системного или интеграционного тестирования вам необходимо выполнить тестирование в сценарии, максимально приближенном к производственному; в идеале вы просто копируете / клонируете живую производственную систему, данные, конфигурацию и все остальное и используете это для тестирования. Это именно то, что мы делаем (если мы технически можем, и клиент соглашается). Мы просто запускаем несколько сценариев SQL, чтобы рандомизировать личные данные в наборе тестовых данных, чтобы избежать проблем с конфиденциальностью.

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

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

Короче говоря:

Укусите пулю и ( после , выполнив все тесты с «игрушечными данными»), получите реалистичный набор данных для тестирования. Если у вас нет оборудования, чтобы справиться с этим, то у вас нет подходящего оборудования для ваших тестов: -).

1 голос
/ 16 февраля 2010

Я бы взглянул на Redgate Генератор данных SQL . Он хорошо генерирует репрезентативные данные.

0 голосов
/ 16 февраля 2010

Чтобы сгенерировать данные, взгляните на ruby ​​faker и perl data faker. Мне повезло с этим в создании больших наборов данных для тестирования. Генератор SQL от Redgate тоже хорош.

0 голосов
/ 16 февраля 2010

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

0 голосов
/ 16 февраля 2010

Посмотрите "Искусство тестирования производительности приложений / Ian Molyneaux, O’Reilly, 2009".

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...