Сообщений в теме: 74

[BaAbaKa]

Мы сейчас с ребятами экспериментируем с форматом подкастов. На скорую руку собрали первый обзорный подкаст о том, зачем вообще мы уделяем внимание вопросам производительности и надежности. Как вставить сюда видеоролик я не понял :) , поэтому просто оставлю ссылку: Быстродействие и надежность: зачем и как?

[Maximchick]

Андрей, добрый день. Не подскажите как вы снимаете метрики(CPU, MEM ...) с сервера.
Заранее спасибо.

[BaAbaKa]

Используем самописный модуль, который позволяет собирать на "мишени" любую статистику (похож на hamster client/server) и складывать результаты в базу лунапарка. Если говорить об обычных системных статистик, то читаем напрямую из /proc/stat и ко. Потом из веба анализируя результаты теста можно просматривать всю собранную статистику. Есть очень много мыслей ка дальше аналитика развивать. Ну или станадртными утилитами в консольке :)

Тут как всегда важнее что потом с этим всем делать и как анализировать. А собрать обычно не проблема.

[forward]

Офисы разработки мы готовы открывать там, где появляются сильные команды разработки — именно так появился офис разработки в Екатеринбурге и Симферополе. Так что или создавайте хорошую команду разработки, которая потом сможет присоединиться к команде Яндекса, или можете сделать хороший стартап и поучаствовать в Яндекс.Старте :)

Какие условия для получения стартапа? Есть у меня много друзей разработчиков достаточно серьёзного уровня. Мы работаем в IT-компании, которая нас не очень интересует на перспективу. Не хотелось бы уезжать в Москву, а работать в своём городе как команда.

[BaAbaKa]

Офисы разработки мы готовы открывать там, где появляются сильные команды разработки — именно так появился офис разработки в Екатеринбурге и Симферополе. Так что или создавайте хорошую команду разработки, которая потом сможет присоединиться к команде Яндекса, или можете сделать хороший стартап и поучаствовать в Яндекс.Старте :)

Какие условия для получения стартапа? Есть у меня много друзей разработчиков достаточно серьёзного уровня. Мы работаем в IT-компании, которая нас не очень интересует на перспективу. Не хотелось бы уезжать в Москву, а работать в своём городе как команда.

Если какого-то стартапа для Яндекс.Старта нет, то напишите, пожалуйста, о своем предложении Грише Бакунову (bobuk@yandex-team.ru) — он заместитель руководителя департамента разработки и самый правильный человек для начала такого разговора.

[Куатор]

BaAbaKa, а можно рассказать, что конкретно в LoadRunner вас не устроило? Ну так, чисто между нами)

[BaAbaKa]

BaAbaKa, а можно рассказать, что конкретно в LoadRunner вас не устроило? Ну так, чисто между нами)

На тот момент были вот такие 4 пункта именно в таком порядке:

• Объемы железа для load generator
• Цена для требуемого в масштабах Яндекса числа vusers
• Наличие зачатков хорошего генератора нагрузок внутри
• Модель на основе виртуальных пользователей (для высоконагруженного веба сильно удобнее применять hit-base подход)

[forward]

Если какого-то стартапа для Яндекс.Старта нет, то напишите, пожалуйста, о своем предложении Грише Бакунову (bobuk@yandex-team.ru) — он заместитель руководителя департамента разработки и самый правильный человек для начала такого разговора.

Написал туда, вот уже полторы недели нет никакого ответа..... :(

[BaAbaKa]

Если какого-то стартапа для Яндекс.Старта нет, то напишите, пожалуйста, о своем предложении Грише Бакунову (bobuk@yandex-team.ru) — он заместитель руководителя департамента разработки и самый правильный человек для начала такого разговора.

Написал туда, вот уже полторы недели нет никакого ответа..... :(

Можно попробовать ещё через Яндекс-Старт: http://company.yandex.ru/public/start

Или через инсайдеров, я уже не.

[Куатор]

Андрей, такой ещё вопрос по организации процесса
Ситуация: разрабатывается сервис (приложение, сайт, ... ). Пехота прошлась по функционалу, можно теперь и по нагрузке продавить :)
У вас есть результаты тестов, допустим (не приведи Господь конечно), что всё плохо именно с точки зрения перформанса, сколько у вас времени на сообщение результатов?
Да, как-то мутнова-то получилось, пример:
Релиз нового функционала через две недели (итерация), доработали фичу и прошлись по функционалу тестировщиками ( ).
Отдали танкистам, через полторы недели.. у вас есть три дня на проведение тестов, анализ результатов и отправке "совета".. Если всё плохо, но об этом узнают за день до релиза, чего происходит?
Раньше стрелять нельзя, ибо не во что (пишется пока что), далее стрелять нельзя ибо тестируется (функциональные баги там и всё такое).. сколько времени на нагрузку отводится и что бывает , когда (не приведи Господь конечно) всё плохо?
Или у вас процессы ваще по-другому построены? Может нет определённого времени, к которому нужно выпустить новый сервис (функционал, приложение и др.).. или всё же умудряетесь стрелять с коленок, пока ещё мишень только пишется... ммм?

[OlesPisarenko]

Андрей, такой ещё вопрос по организации процесса
Ситуация: разрабатывается сервис (приложение, сайт, ... ). Пехота прошлась по функционалу, можно теперь и по нагрузке продавить :)
У вас есть результаты тестов, допустим (не приведи Господь конечно), что всё плохо именно с точки зрения перформанса, сколько у вас времени на сообщение результатов?
Да, как-то мутнова-то получилось, пример:
Релиз нового функционала через две недели (итерация), доработали фичу и прошлись по функционалу тестировщиками ( ).
Отдали танкистам, через полторы недели.. у вас есть три дня на проведение тестов, анализ результатов и отправке "совета".. Если всё плохо, но об этом узнают за день до релиза, чего происходит?
Раньше стрелять нельзя, ибо не во что (пишется пока что), далее стрелять нельзя ибо тестируется (функциональные баги там и всё такое).. сколько времени на нагрузку отводится и что бывает , когда (не приведи Господь конечно) всё плохо?
Или у вас процессы ваще по-другому построены? Может нет определённого времени, к которому нужно выпустить новый сервис (функционал, приложение и др.).. или всё же умудряетесь стрелять с коленок, пока ещё мишень только пишется... ммм?

Привет! Приму эстафету рассказов о нагрузочном тестировании в Яндексе.
Итак, как устроен процесс.
Если речь идет о новом проекте, то мы можем начать исследования (либо выдать уже имеющиеся данные) компонентов сервиса, например стораджа, прокси, шаблонизатора, без интерграции в проект. Либо выделить разработчику лоад-генератор для отладки своего кода с точки зрения перфоманса, дабы не пришлось переписывать заново. Непроизводительные куски выявляются сразу, это экономит время танкистам и всему проекту.

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

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

[BaAbaKa]

Андрей, такой ещё вопрос по организации процесса
Ситуация: разрабатывается сервис (приложение, сайт, ... ). Пехота прошлась по функционалу, можно теперь и по нагрузке продавить :)
У вас есть результаты тестов, допустим (не приведи Господь конечно), что всё плохо именно с точки зрения перформанса, сколько у вас времени на сообщение результатов?
Да, как-то мутнова-то получилось, пример:
Релиз нового функционала через две недели (итерация), доработали фичу и прошлись по функционалу тестировщиками ( ).
Отдали танкистам, через полторы недели.. у вас есть три дня на проведение тестов, анализ результатов и отправке "совета".. Если всё плохо, но об этом узнают за день до релиза, чего происходит?
Раньше стрелять нельзя, ибо не во что (пишется пока что), далее стрелять нельзя ибо тестируется (функциональные баги там и всё такое).. сколько времени на нагрузку отводится и что бывает , когда (не приведи Господь конечно) всё плохо?
Или у вас процессы ваще по-другому построены? Может нет определённого времени, к которому нужно выпустить новый сервис (функционал, приложение и др.).. или всё же умудряетесь стрелять с коленок, пока ещё мишень только пишется... ммм?

Привет! Приму эстафету рассказов о нагрузочном тестировании в Яндексе.
Итак, как устроен процесс.
Если речь идет о новом проекте, то мы можем начать исследования (либо выдать уже имеющиеся данные) компонентов сервиса, например стораджа, прокси, шаблонизатора, без интерграции в проект. Либо выделить разработчику лоад-генератор для отладки своего кода с точки зрения перфоманса, дабы не пришлось переписывать заново. Непроизводительные куски выявляются сразу, это экономит время танкистам и всему проекту.

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

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

Док, спасибо! :) Со всем согласен.

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

[Куатор]

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

Не совсем понял этот кусочек. Лоуд-генератор понятно (машинка производящая нагрузку жеж?), что на счёт скрипта? Если функционал новый, то нужен скрипт в соответствии с которым лоуд-генератор будет нагружать сервис (сайт и др). Разработчик сам пишет новый скрипт для тестирования производительности своей части кода? Или у вас есть какие-то стандартные шаблончики, типа заготовки, куда можно вставить только параметры и как минимум стандартные запросы будут отправлены и получены ответы под нагрузкой, на которые можно будет полюбоваться (ну там время отклика транзакций, которые программист должен был создать в скрипте).
Или использует просто профилировщик типа AMD CodeAnalyst , а остальное - ваша забота? )

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

Функциональное тестирование проводит сам разработчик, нет мануальных тестировщиков? То есть, когда разработчик сказал - работает, сразу эстафету принимают нагрузчики?

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

Эт понятно , вопрос в другом, когда вы сообщаете результаты? Просто, если релиз завтра, а вы только закончили тесты и говорите - у нас всё плохо и менеджер принимает решение, выпускать не выпускать (или отключать критичные части или ещё чего). Или у вас нет фиксированной даты релиза этой части функционала.. то есть , разработчик написал, отладил.. отдал вам.. вы провели тесты, всё плохо - на доработку, и так пока не скажете - норма! Можно релизить.. Ммм?

[OlesPisarenko]

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

Не совсем понял этот кусочек. Лоуд-генератор понятно (машинка производящая нагрузку жеж?), что на счёт скрипта? Если функционал новый, то нужен скрипт в соответствии с которым лоуд-генератор будет нагружать сервис (сайт и др). Разработчик сам пишет новый скрипт для тестирования производительности своей части кода? Или у вас есть какие-то стандартные шаблончики, типа заготовки, куда можно вставить только параметры и как минимум стандартные запросы будут отправлены и получены ответы под нагрузкой, на которые можно будет полюбоваться (ну там время отклика транзакций, которые программист должен был создать в скрипте).
Или использует просто профилировщик типа AMD CodeAnalyst , а остальное - ваша забота? )

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

Функциональное тестирование проводит сам разработчик, нет мануальных тестировщиков? То есть, когда разработчик сказал - работает, сразу эстафету принимают нагрузчики?

у нас есть фунциональщики, но в этом топике речь не о них.

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

Эт понятно , вопрос в другом, когда вы сообщаете результаты? Просто, если релиз завтра, а вы только закончили тесты и говорите - у нас всё плохо и менеджер принимает решение, выпускать не выпускать (или отключать критичные части или ещё чего). Или у вас нет фиксированной даты релиза этой части функционала.. то есть , разработчик написал, отладил.. отдал вам.. вы провели тесты, всё плохо - на доработку, и так пока не скажете - норма! Можно релизить.. Ммм?

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

[Куатор]

Спасибо