Есть подозрение что шаблон с стандартным php кодом будет генерироваться дольше чем текстовый шаблон прочитанный из файла с подстановкой переменных. (DISCLAIM: это просто мнение, я не проверял на реальных тестах.)
Дело может быть в том что используя стандартный php код в шаблонах, PHP движку придется как минимум компилить файл с шаблоном, что само по себе отъедает больше времени чем простое чтение содержимого файла и подстановка переменных.
В качестве подтверждения могу привести пример чтения конфигов описанных в этой статье habrahabr.ru/blogs/php/112402/. В этой статье результаты чтения и разбора INI файлов быстрее чем подключение PHP файлов с массивом данных.
Да то что вы предлагаете это и так понятно, а вот что вы за это хотите, это уже более интересно.
Но информации про 40% я так и не нашел на вашем сайте.
40% на посевной стадии это бизнес по нашему! А через три месяца за следующий транш еще раз 40%?
На официальном сайте ни номеров контактных телефонов нет, ни условий на которых будут предоставляться деньги, ничего кроме пары заезженных клише…
Может вы просветите нас во все тонкости (условия) вашей работы, и станете более открытыми? А то как то все мутно получается: покажи, расскажи а потом видно будет надо это тебе или нет.
Как раз тестировщики и должны протестировать 100% кейсов, и не важно сколько это времени займет, потому что если выкладывать не качественно протестированный продукт себе дороже — или вы этого не знали? ;)
Заведите им документ в котором будут описаны все «use case»-ы и требуйте 100% тестирования их, всеми возможными тестами.
По поводу геораспределенных датацентров, то с такой задачей не сталкивался. Но могу сказать что это очень легко решается, и разработчик (и/или архитектор) должен был это предусмотреть.
У вас что тестировщиков нет? Или они не тестируют функциональность перед деплоем новой версии?
«Редкий бесконечный редирект»? Извините меня, но надо очень постараться что бы такое нагородить. И каким образом он может быть таким редким что даже разработчики вряд ли бы напоролись?
К тому же вопрос был в другом. Я не просил приводить примеры ваших злостных багов, а просил привести пример дискретной процедуры выполняемой пользователем, которая не может быть воспроизведена в нагрузочных тестах.
Спасибо за развернутый ответ. Но контекст темы все таки про сбор информации о работе PHP скриптов, а так как и профайлинг и мониторинг собирают некую информацию о работе программы, то эти процессы можно считать условно идентичными в пределах данного контекста.
Приведите пожалуйста показатель «Request per second» с включенной и выключенной «пинбой». Я думаю этот параметр будет более актуален чем время выполнения скрипта.
Ну раз так Вы считаете, то не могли бы Вы описать отличия понятий «мониторинга» и «профайлинга»? С точки зрения эти процессы похожи тем что они оба выполняют сбор информации о выполнении скрипта/программы. Поэтому я не считаю что я в чем то путаюсь, скорее Вы ;)
> Плюс к этому процессы на проде и в тестах все же отличаются, как бы мы не пытались сделать их идентичными.
Приведите пример дискретного PHP процесса, который выполняется пользователем и не может быть идентично реализован в нагрузочных тестах?
Ну это и так понятно. Имелось ввиду: выполнить нагрузочные тесты на девелоперском сервере с включенным пинбой. Пинба промониторит работу скриптов во время нагрузочных тестов. Потом команда сможет проанализировать мониторинг и внести коррективы в работу скриптов (при необходимости).
А так вы оверхедите на продакшене, а это как то не очень фей-шуйно.
А вы выполните 'ab -n 1000 -c 10 yoursite.com/somepage.here' два раза, один раз с отключенным пимбом, второй раз с включенным, и покажите нам результаты.
Дело может быть в том что используя стандартный php код в шаблонах, PHP движку придется как минимум компилить файл с шаблоном, что само по себе отъедает больше времени чем простое чтение содержимого файла и подстановка переменных.
В качестве подтверждения могу привести пример чтения конфигов описанных в этой статье habrahabr.ru/blogs/php/112402/. В этой статье результаты чтения и разбора INI файлов быстрее чем подключение PHP файлов с массивом данных.
В метро на работу в одном вагоне с академиками ехать будете
Но информации про 40% я так и не нашел на вашем сайте.
40% на посевной стадии это бизнес по нашему! А через три месяца за следующий транш еще раз 40%?
Может вы просветите нас во все тонкости (условия) вашей работы, и станете более открытыми? А то как то все мутно получается: покажи, расскажи а потом видно будет надо это тебе или нет.
Всем спасибо, в эту ветку больше не постю :)
Заведите им документ в котором будут описаны все «use case»-ы и требуйте 100% тестирования их, всеми возможными тестами.
По поводу геораспределенных датацентров, то с такой задачей не сталкивался. Но могу сказать что это очень легко решается, и разработчик (и/или архитектор) должен был это предусмотреть.
Ну а так пинба вам помогла :)
«Редкий бесконечный редирект»? Извините меня, но надо очень постараться что бы такое нагородить. И каким образом он может быть таким редким что даже разработчики вряд ли бы напоролись?
К тому же вопрос был в другом. Я не просил приводить примеры ваших злостных багов, а просил привести пример дискретной процедуры выполняемой пользователем, которая не может быть воспроизведена в нагрузочных тестах.
Ну раз так Вы считаете, то не могли бы Вы описать отличия понятий «мониторинга» и «профайлинга»? С точки зрения эти процессы похожи тем что они оба выполняют сбор информации о выполнении скрипта/программы. Поэтому я не считаю что я в чем то путаюсь, скорее Вы ;)
> Плюс к этому процессы на проде и в тестах все же отличаются, как бы мы не пытались сделать их идентичными.
Приведите пример дискретного PHP процесса, который выполняется пользователем и не может быть идентично реализован в нагрузочных тестах?
Пинба — мониторит работу PHP скриптов. Какая разница кто будет дергать тест — пользователь или тест? Вы же не работу с интерфейсом мониторить будете.
А так вы оверхедите на продакшене, а это как то не очень фей-шуйно.
Думаю этот инструмент нужно ставить все таки на девелопмент сервер. Для продакшена это в любом случае это оверхед.