Сервер разработки стресс-тестирования / рабочий сервер

Вы можете использовать глобальную переменную

Вы можете использовать глобальную переменную [110] или метод getenv('variable').

ENV или метод getenv('variable').

5
задан Ankit Pandya 3 December 2015 в 09:15
поделиться

2 ответа

Вот различные подсказки/предложения:

  • Если Ваше приложение будет новым, таким образом, Вы не знаете, может ли оно обработать загрузку, оно будет иметь в производстве, то необходимо сделать "полное" тестирование. Необходимо сделать полное тестирование на производственных аппаратных средствах, которые, так как это еще не пошло "живое", не будут влиять на пользователей.

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

  • Регрессионный тест производительности состоит из выполнения стресс-теста всех отдельных "функций" (независимо от того, что это означает для Вашего приложения) на Вашем сервере разработки для измерения, это - производительность. Вы ведете учет результатов как Ваша "базовая линия".

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

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

6
ответ дан 14 December 2019 в 04:48
поделиться

Я думаю, что необходимо избежать какой-либо работы включая стресс-тестирование на производственных машинах, если Вы не знаете, что у Вас есть проблема, которую Вы не можете воспроизвести в своей тестовой среде - который сказал, возможно, что Вы знаете, что Ваши пользователи не используют систему в течение ночи? Если бы тесты не являются intrusibe/read только затем, я сказал бы, что это - дополнительная опция.

Относительно выполнения анализа на более слабой машине это не настолько плохо - большинство узких мест вызывается плохой архитектурой Вашей системы и должно быть видимо на различных аппаратных конфигурациях, только в различных сценариях загрузки - может быть еще легче заметить проблемы на более слабой машине, таким образом, я сказал бы что стресс-тест и оптимизировал бы в Вашей системе разработки, и Вы будете знать, что по крайней мере теоретически Ваша производственная система должна быть еще лучше.

2
ответ дан 14 December 2019 в 04:48
поделиться
Другие вопросы по тегам:

Похожие вопросы: