Наша команда столкнулась с недостатками инструментов нагрузочного тестирования, и, в конце концов, было решено разработать собственный сервис. Основные сложности:

• Если это сервис — для серьезной нагрузки цена слишком высока
• Если это утилита — результат зависит от скорости канала компьютера/сервера с которого проводился тест
• Повторяющиеся запросы не отражают реальной скорости, так как кэширование есть на самых разных уровнях начиная от CPU и заканчивая базой данных

Надеюсь, «велосипед» будет интересен и другим — сначала я опишу что уже работает, потом можно будет обсудить дальнейшие фичи.

Что уже сделано?

• Можно тестировать задания из списка url, до 20 штук
• Каждая url может содержать один или несколько случайных параметров, задаваемых с помощью функции $RND
• Тест запускается с множества серверов, на каждом из которых работает только 8 потоков
• Тестирование можно проводить из 4х регионов AWS — Ирландия, Восток/Запад США, Токио
• Тесты до 200 потоков мы готовы предоставлять бесплатно

Читать дальше →

Задача данной статьи — показать самый производительный путь написания тестов в контексте разработки веб-приложений.

Здесь и дальше под термином тесты будут подразумеваться юнит-тесты.

Разработка веб-приложений сопровождается постоянным использованием в коде базы данных. Если код работы с базой данных и код работы с результатом взаимодействия с базой данных не разделен, нам потребуется база данных в подавляющем большинстве тестов проекта. Также, если код использует методы фреймворка, нам для тестов потребуется подключить фреймворк. Пока тестов мало, всё отлично. Когда тестов становится больше, замечается проблема: скорость выполнения тестов немного напрягает. Когда время выполнения всех юнит-тестов становится больше чем минута, становится невозможным постоянно запускать все тесты. Разработчик начинает запускать только часть тестов, пытаясь уменьшить негативное влияние длительного времени работы тестов, но проблема снижения эффективности тестирования со временем будет только возрастать.

Источник проблемы находится в отсутствии четкого разделения кода работы с базой данных, кода, которому необходим фреймворк, и кода, для работы которого не нужна ни база данных, ни фреймворк.

Наша цель будет разобраться, каким образом необходимо писать тесты и код для обеспечения максимальной скорости выполнения тестов.
Читать дальше →

Любой специалист, причастный к тестированию веб-приложений, знает, что большинство рутинных действий на сервисах умеет делать фреймворк Selenium. В Яндексе в день выполняются миллионы автотестов, использующих Selenium для работы с браузерами, поэтому нам нужны тысячи различных браузеров, доступных одновременно и 24/7. И вот тут начинается самое интересное.



Selenium с большим количеством браузеров имеет много проблем с масштабированием и отказоустойчивостью. После нескольких попыток у нас получилось элегантное и простое в обслуживании решение, и мы хотим поделиться им с вами. Наш проект gridrouter позволяет организовать отказоустойчивый Selenium-грид из любого количества браузеров. Код выложен в open-source и доступен на Github. Под катом я расскажу, на какие недостатки Selenium мы обращали внимание, как пришли к нашему решению, и объясню, как его настроить.
Читать дальше →

Runkit 1.0.4 для PHP выпущен!

Поздравляю всех пользователей Runkit с новым долгожданным мега-релизом! Если вы постоянно используете Runkit и хорошо знакомы с его возможностями, историей и развитием, то можете сразу переходить к описанию изменений релиза 1.0.4. В любом случае предлагаю прочесть статью целиком.
Читать дальше →

Здравствуйте, дорогие читатели!

Как помнят самые внимательные из вас, мы работаем над инновационной книгой о микросервисах, но в то же время не забываем читать, что пишут в Сети на эту тему. Поэтому не смогли пройти мимо интереснейшей статьи из блога Amazon, автор которой Тим Вагнер делится своими взглядами на микросервисную архитектуру.

Много Java, JavaScript, схем, рассуждений и очень много текста Читать дальше →