Здравствуйте,
есть проблема такого рода:
приложение проверяется на тестовой небольшой базе данных (до 1 Гб). Вроде как все работает: скрипты на базу накатываем, приложение запускается, данные обрабатываются.
Но вот на реальных базах в несколько десятков-сотен гигов иногда начинаются проблемы: скрипты очень долго "вгоняются", приложение может упасть после новых скриптов и т.д.
Существуют какие-то методы тестирования работоспособности того же приложения, но на больших базах? Или это возможно проверить только практикой (на реальной базе, имея "мега" сервер клиента)?
Дополнительно: работаем с InterBase, приложение написано на Delphi
Заранее спасибо за ответы:)
Реальные объемы данных
Автор firefly, 30 мая 2006 02:44
Сообщений в теме: 13
#1
firefly
-
- Members
-
- 10 сообщений
Новый участник
- ФИО:Svetlana
- Город:Новосибирск
Отправлено 30 мая 2006 - 02:44
#3
SALar
-
- Members
-
- 2 298 сообщений
Профессионал
- Город:Москва
Отправлено 30 мая 2006 - 07:08
Существуют.
Это объемное тестирование. Посмотрите в моем блоге. Там немного написано о таком виде тестирования.
Это объемное тестирование. Посмотрите в моем блоге. Там немного написано о таком виде тестирования.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#4
Guriy
-
- Members
-
- 316 сообщений
Опытный участник
- Город:Киев, Украина
Отправлено 13 июня 2006 - 19:20
...
Но вот на реальных базах в несколько десятков-сотен гигов...
...работаем с InterBase...
Кх-Кх - может метров?
#5
firefly
-
- Members
-
- 10 сообщений
Новый участник
- ФИО:Svetlana
- Город:Новосибирск
Отправлено 15 июня 2006 - 02:14
с сотнями я погорячилась - у страха глаза велики:)
предельное значение как раз сотня, но именно гигов
к сожалению, продукт уже давно в коде, так что объемное тестирование до кодирования отменяется:(
а готовый продукт нельзя как-нибудь и чем-нибудь проверить на работоспособность с большими объемами данных до того, как от клиентов поступят жалобы?
предельное значение как раз сотня, но именно гигов
к сожалению, продукт уже давно в коде, так что объемное тестирование до кодирования отменяется:(
а готовый продукт нельзя как-нибудь и чем-нибудь проверить на работоспособность с большими объемами данных до того, как от клиентов поступят жалобы?
#6
SALar
-
- Members
-
- 2 298 сообщений
Профессионал
- Город:Москва
Отправлено 15 июня 2006 - 06:46
Не "можно", а "нужно".с сотнями я погорячилась - у страха глаза велики:)
предельное значение как раз сотня, но именно гигов
к сожалению, продукт уже давно в коде, так что объемное тестирование до кодирования отменяется:(
а готовый продукт нельзя как-нибудь и чем-нибудь проверить на работоспособность с большими объемами данных до того, как от клиентов поступят жалобы?
Выбор инструмента проверки зависит от вашей системы. Судя по тому, что увас тормозят скрипты, лучше всего подойдет использование связки "среда выполнения скриптов" + "профайлер".
PS. Сотня гигов это маленькие объемы. Как говорят ораклисты 10-20 гиг это размер игрушечной базы.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#7
firefly
-
- Members
-
- 10 сообщений
Новый участник
- ФИО:Svetlana
- Город:Новосибирск
Отправлено 15 июня 2006 - 15:16
ну, оракл все таки немного другое...
а можно уточнить как мне поможет профайлер? встроим мы в свою "среду выполнения скриптов" (у нас спец.апдейтер для этих целей есть), будем получать время выполения скриптов, только на маленькой базе выдаст время маленькое, а на большой сутки будет ставиться - у клиентов стоит мощный сервер, который на тестирование мне никто не одолжит. Вопрос в том как мне "предугадать" приемлемое ли время будет ставиться скрипт на большую базу на мощном сервере, имея в наличии обычную машину?
...дали самолет тестировать, а я его могу только по асфальту за веревочку покатать
а можно уточнить как мне поможет профайлер? встроим мы в свою "среду выполнения скриптов" (у нас спец.апдейтер для этих целей есть), будем получать время выполения скриптов, только на маленькой базе выдаст время маленькое, а на большой сутки будет ставиться - у клиентов стоит мощный сервер, который на тестирование мне никто не одолжит. Вопрос в том как мне "предугадать" приемлемое ли время будет ставиться скрипт на большую базу на мощном сервере, имея в наличии обычную машину?
...дали самолет тестировать, а я его могу только по асфальту за веревочку покатать
#8
SALar
-
- Members
-
- 2 298 сообщений
Профессионал
- Город:Москва
Отправлено 15 июня 2006 - 17:08
Профайлер покажет узкие места. На вашем стенде.ну, оракл все таки немного другое...
а можно уточнить как мне поможет профайлер? встроим мы в свою "среду выполнения скриптов" (у нас спец.апдейтер для этих целей есть), будем получать время выполения скриптов, только на маленькой базе выдаст время маленькое, а на большой сутки будет ставиться - у клиентов стоит мощный сервер, который на тестирование мне никто не одолжит. Вопрос в том как мне "предугадать" приемлемое ли время будет ставиться скрипт на большую базу на мощном сервере, имея в наличии обычную машину?
...дали самолет тестировать, а я его могу только по асфальту за веревочку покатать
Интерпретация на боевой стенд... Боюсь, моих знаний не хватит, чтобы в форуме дать правильный ответ. Я стараюсь пользоваться правилом:
Тестовый стенд должен соответствовать боевому.
Перенос результатов тестирования на реальных данных, но на сильно отличаюшемся железе далеко нетривиальная задача. Увы.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#9
DrVal
-
- Members
-
- 230 сообщений
Постоянный участник
- ФИО:Drozdov V. V.
Отправлено 16 июня 2006 - 11:32
В принципе, найти узкие места можно и на менее мощной машине.
Скажем, если есть квадратичная зависимость времени выполнения от объема данных, то никакая быстрая машина это не компенсирует (скажем, объем базы больше в 100 раз, машина быстрее в 10 раз, время выполнения больше в 1000 раз).
Т.ч. можно проанализировать несколько зависимостей - от объема данных при фиксированной конфигурации, от количества памяти и частоты ЦПУ (или их количества) при фиксированном объеме и т.д.
Результат это, конечно, не гарантирует, но выявить проблемы с масштабированием может.
Скажем, если есть квадратичная зависимость времени выполнения от объема данных, то никакая быстрая машина это не компенсирует (скажем, объем базы больше в 100 раз, машина быстрее в 10 раз, время выполнения больше в 1000 раз).
Т.ч. можно проанализировать несколько зависимостей - от объема данных при фиксированной конфигурации, от количества памяти и частоты ЦПУ (или их количества) при фиксированном объеме и т.д.
Результат это, конечно, не гарантирует, но выявить проблемы с масштабированием может.
#10
firefly
-
- Members
-
- 10 сообщений
Новый участник
- ФИО:Svetlana
- Город:Новосибирск
Отправлено 20 июня 2006 - 05:40
хорошая мысль:)
спасибо большое!
буду хоть так статистику набирать...
спасибо большое!
буду хоть так статистику набирать...
#11
Гость_@Alex_*
Гость_@Alex_*
-
- Guests
Отправлено 13 сентября 2006 - 12:17
Quest Software хвалится что его BenchMark Factory "меряет" БД хорошо.
Вообще-то скрипты должны прогоняться на тестовых БД которые соизмеримы с боевыми. Тогда можно делать прогноз. Кроме того, по опыту можно установить что 10 000 строк обрабатываются столько-то и объединяются столько-то, 100 000 строк обрабатываются столько-то и объединяются столько-то.
Периодическая визитация клиентов с вашими продуктами и сбор разного рода статистик и их накопление, тоже дают много информации для последующих прогнозов.
Опять же важен не размер самой БД а размер отдельных сегментов данных с которыми вы работаете. Увеличить несколько сегментов для тестов - это допустимо. только оговорюсь что увеличение сегментов должно быть осмысленным
Вообще-то скрипты должны прогоняться на тестовых БД которые соизмеримы с боевыми. Тогда можно делать прогноз. Кроме того, по опыту можно установить что 10 000 строк обрабатываются столько-то и объединяются столько-то, 100 000 строк обрабатываются столько-то и объединяются столько-то.
Периодическая визитация клиентов с вашими продуктами и сбор разного рода статистик и их накопление, тоже дают много информации для последующих прогнозов.
Опять же важен не размер самой БД а размер отдельных сегментов данных с которыми вы работаете. Увеличить несколько сегментов для тестов - это допустимо. только оговорюсь что увеличение сегментов должно быть осмысленным
#12
Гость_drcoor_*
Гость_drcoor_*
-
- Guests
Отправлено 14 сентября 2006 - 14:29
У Вас десятки-сотни гигов именно под Interbase??? Причём у каждого из Ваших клиентов? Да как же вы их бекапите и вообще обслуживаете? 
Или всё-таки какой-то клон, например, FB?
А по теме - мы в нашей ситуации всё-таки закупили сервер, по возможностям похожий на пользовательский, правда дешевле, и гоняем на нём. Правда, всегда проверяем время выполнения скриптов 2 раза - на маленькой базке и на в 10 раз большей, чтоб примерно знать зависимость времени от размера - прямая или квадратичная (обе базы - боевые, присланы с мест).
Хотя по моему опыту, под клонами ИБ скрипты выполняются независимо от размера БД. Если проблема с прокруткой скриптов - значит, либо в них трабл, и он и на мелкой БД вылезет, либо база убитая (например, перед установкой обновления не был вполнен бекап-рестор БД и количество структурных изменений превысило 256).
Или всё-таки какой-то клон, например, FB?А по теме - мы в нашей ситуации всё-таки закупили сервер, по возможностям похожий на пользовательский, правда дешевле, и гоняем на нём. Правда, всегда проверяем время выполнения скриптов 2 раза - на маленькой базке и на в 10 раз большей, чтоб примерно знать зависимость времени от размера - прямая или квадратичная (обе базы - боевые, присланы с мест).
Хотя по моему опыту, под клонами ИБ скрипты выполняются независимо от размера БД. Если проблема с прокруткой скриптов - значит, либо в них трабл, и он и на мелкой БД вылезет, либо база убитая (например, перед установкой обновления не был вполнен бекап-рестор БД и количество структурных изменений превысило 256).
#13
firefly
-
- Members
-
- 10 сообщений
Новый участник
- ФИО:Svetlana
- Город:Новосибирск
Отправлено 21 мая 2007 - 09:46
У Вас десятки-сотни гигов именно под Interbase??? Причём у каждого из Ваших клиентов? Да как же вы их бекапите и вообще обслуживаете?
не у всех, но есть несколько "больших" клиентов и у них именно такие размеры. Работа с ними почти индивидуальна. Моя задача минимизировать проблемы, но, к сожалению, не убрать их полностью...
сервер никто так и не хочет закупать:(
выбрала также несколько (пока хватает 6) "боевых" баз разных размеров и ставлю все обновления на них - картинка в целом получается приближенная к реальной, по крайней мере можно увидеть когда стоит бить тревогу...
если проблема в скрипте, то, конечно, ее можно заметить на мелкой базе. Но если скрипт верный, но не оптимизированный (н-р, последовательный перебор строк одной из таблиц), тогда на больших базах могут возникнуть сложности - перебрать 10 строк или, допустим, 1 000 000 займет разное время. Другое дело окажется ли среди моих тестовых баз база именно с этой большой таблицей... По крайней мере стралась выбирать среднестатистические базы.
...а убитые базы клиентов - это уже проблема сопроводагеров, в моем случае:)
#14
P_R
-
- Members
-
- 16 сообщений
Новый участник
- Город:Киев
Отправлено 20 сентября 2007 - 11:07
...статистика и прогнозирование.
Обязательные пунктики:
1) схема тестовой полностью совпадает с продуктивной;
2) количество записей для проверки скрипта градуируем (пр., 10, 100, 10 000, 100 000) .
Проводим испытания - следим за производительностью. Для определения графика зависимости производительности БД (системы) от нагрузки по данным, необходимо создать набор тестовых баз данных, которые имеют разный объем (мощность <= P продуктива). Это позволяет оценить изменение параметров производительности тестируемого продукта. Логарифмическая шкала позволяет оценить скорость роста времен отклика и обнаружить узкие места.
Если есть статистика по различным профилям нагрузки - значит можно прогнозировать, следовательно определить законы изменения измеряемых параметров в зависимости от нагрузки, а значит составлять ТС наиболее оптимально.
Обязательные пунктики:
1) схема тестовой полностью совпадает с продуктивной;
2) количество записей для проверки скрипта градуируем (пр., 10, 100, 10 000, 100 000) .
Проводим испытания - следим за производительностью. Для определения графика зависимости производительности БД (системы) от нагрузки по данным, необходимо создать набор тестовых баз данных, которые имеют разный объем (мощность <= P продуктива). Это позволяет оценить изменение параметров производительности тестируемого продукта. Логарифмическая шкала позволяет оценить скорость роста времен отклика и обнаружить узкие места.
Если есть статистика по различным профилям нагрузки - значит можно прогнозировать, следовательно определить законы изменения измеряемых параметров в зависимости от нагрузки, а значит составлять ТС наиболее оптимально.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных
