Имитация запросов больших представлений для целей бенчмаркинга - PullRequest
Новая
       11

Имитация запросов больших представлений для целей бенчмаркинга

0 голосов
/ 31 августа 2008

Приложение Windows Forms извлекает записи из представления на SQL Server через ADO.NET и веб-службу SOAP, отображая их в сетке данных. У нас было несколько случаев с ~ 25 000 строк, что работает относительно гладко, но потенциальный клиент должен иметь много раз больше в одном списке.

Чтобы выяснить, насколько хорошо мы сейчас масштабируемся и как (и насколько) мы можем реально улучшить, я хотел бы реализовать симуляцию: вместо отображения фактических данных SQL Server отправляет вымышленные, случайные данные. Клиентская и транспортная сторона будут в основном одинаковыми; представление (или, по крайней мере, базовая таблица), конечно, будет работать по-другому. Пользователь указывает количество вымышленных строк (например, 100 000).

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

Что я пытаюсь выяснить, так это: как заставить SQL Server отправлять такие данные?

Должен ли я:

  1. Создать хранимую процедуру, которую нужно запустить заранее, чтобы заполнить фактическую таблицу?
  2. Создать функцию, на которую я указываю, чтобы сервер генерировал данные «вживую»?
  3. Каким образом реплицировать и / или рандомизировать существующие данные?

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

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

Кроме того, я не уверен, как создавать эти строки, если не использовать цикл или курсор. Я могу использовать SELECT top <n> random1(), random2(), […] FROM foo, если foo действительно содержит <n> записей, но в противном случае (очевидно) я получу только столько строк, сколько в foo. GROUP BY newid() или аналогичный, похоже, не сработает.

Ответы [ 4 ]

2 голосов
/ 11 октября 2008

Для данных по тестированию таблиц типов CRM я настоятельно рекомендую fakenamegenerator.com , вы можете получить 40000 поддельных имен бесплатно.

1 голос
/ 19 октября 2008

Вы не упомянули, используете ли вы SQL Server 2008. Если вы используете 2008 и используете сжатие данных, имейте в виду, что случайные данные будут действовать совсем иначе (медленнее), чем реальные данные. Случайные данные сжать намного сложнее.

Quest Toad для SQL Server и Microsoft Visual Studio Data Dude имеют тестовые генераторы данных, которые будут помещать в записи ложные «настоящие» данные.

0 голосов
/ 31 августа 2008

Данные, как правило, похожи на CRM, т.е. контакты, проекты и т. Д. Было бы хорошо просто дублировать данные (например, если у меня всего 20 000 строк, я скопирую их пять раз, чтобы получить желаемые 100 000 строк ). С другой стороны, слияние будет работать только в том случае, если мы никогда не развернем инструмент тестирования производительности публично по очевидным причинам конфиденциальности (если, конечно, я не применяю функцию к каждому столбцу, которая делает исходные данные неразборчивыми и не подлежит восстановлению? Похоже на функцию хеширования). , только без слишком большого изменения размера значения).

Чтобы заполнить строки, возможно, что-то подобное будет делать: 

WHILE (SELECT count(1) FROM benchmark) < 100000
  INSERT INTO benchmark
  SELECT TOP 100000 * FROM actualData
0 голосов
/ 31 августа 2008

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

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

...