Регулярная настройка производительности и обслуживания

Question

Как часто вы проводите регулярное обслуживание, такое как стресс-тестирование вашего приложения и / или настройку индексов базы данных для ваших приложений?

EG, Вы настраиваете (дефрагментируете, реорганизуете или перестраиваете) свои индексы базы данных один раз в неделю, каждые шесть месяцев или только после ввода больших объемов данных и проводите ли вы стресс-тестирование своего приложения после каждой основной или вспомогательной сборки, еженедельно ежегодно, никогда?

Answer 1

Когда я работал в крупной 3D CAD компании, у нас были тесты, которые выполнялись:

• Всякий раз, когда вы хотели проверить в коде. Около 40 тестов. Вам нужно было пройти все тесты, прежде чем вы смогли проверить код (вам также пришлось пройти проверку кода).
• Всякий раз, когда сервер сборки заканчивал непрерывную сборку
• Каждую ночь (много тестов, около 8 часов).
• Один раз в неделю (еще больше тестов - этот набор тестов займет много дней).

Каждый тест загружал определенную 3D-модель, созданную командой QA, чтобы подчеркнуть различные проблемы. Я уверен, что некоторые из моделей были предоставлены заказчиком, чтобы подчеркнуть ранее известные ошибки клиентов. Размеры моделей варьировались от микрон до 1 км во всех трех направлениях.

Answer 2

В действующей производственной системе, где код развивается, каждый день является стресс-тестом. Точно так же настройка базы данных заключается в том, чтобы знать, когда остановиться; когда производительность приемлема, вы останавливаетесь.

В частности, в Oracle споры о том, стоит ли перестраивать индексы, бушуют годами; некоторые люди верят в это, некоторые нет. Индекс представляет собой древовидную структуру B *; это будет точно отражать данные в таблице. Во многих случаях (за исключением следующих случаев) перестройка индекса похожа на ускоренную диету; Конечно, в краткосрочной перспективе индексы станут худыми, но со временем - возможно, всего за несколько дней или часов обработки - они вернутся в свое прежнее состояние. Пока производительность отвечает целям, зачем беспокоиться об этом? Перестройка индексов генерирует значительную активность ввода-вывода (нужно прочитать таблицу и / или индекс) и либо генерирует значительную активность повторения (запись векторов повторения для новых записей индекса), либо требует немедленного резервного копирования (если вы перестроили индекс с помощью NOLOGGING, индекс теперь не подлежит восстановлению).

Исключения:

• Обычно растровые индексы должны быть перешел в автономный режим и перестроен между данные, так как они могут патологически раздувать через деятельность DML

• Если один радикально разгружает много данные и использует глобальные индексы или некоторый другой не локально разделенный индекс, объединение (не восстановление, просто толкая соседнее пространство на соседний листья вместе) может быть разумным.

Answer 3

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

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

Answer 4

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