Около месяца назад я завершил работу над первым выпуском The Ruby Web Benchmark Report , наиболее полным тестом веб-приложений «Hello World», когда-либо созданным для Ruby. Это было значительное начинание. По пути я узнал кое-что о понимании производительности, бенчмаркинга и Ruby, чего не знал, когда начинал. Эти уроки выходят далеко за рамки того, что я ожидал получить, когда начал проект.
Вы никогда не узнаете, пока не пройдете тест
Первое, что меня удивило, это то, что вы никогда не знаете, какая у вас производительность, пока не запустите свои собственные тесты для своего собственного кода. Это может показаться очевидным, но это правда.
Например, я всегда думал, что Sinatra — самый быстрый веб-фреймворк Ruby, но это не так. На самом деле, хотя он и быстрее, чем Rails, он не так быстр, как обычные старые Rack или фреймворки, которые похожи на Sinatra, но имеют лучшую производительность, как на Кубе.
Кроме того, я был удивлен, насколько большой потенциал производительности есть в JRuby. По сравнению с MRI, стандартной средой Ruby, JRuby был намного быстрее почти в каждом случае, как только он прогрелся. До сих пор я думал, что JRuby будет полезен в контексте корпоративных магазинов Java, которые уходят от Java EE. Теперь я понимаю, что JRuby предоставляет высокопроизводительную альтернативу, которая может отсрочить или отменить необходимость перехода на язык с более высокой производительностью, такой как Java, Scala или Go.
Я не знал бы ничего из этого, не выполняя свои собственные тесты.
Когда вы смотрите на мои номера, не принимайте их за чистую монету. Сделайте свои собственные тесты. Неважно, докажете ли вы их правильно или нет. Вы узнаете что-то просто, испытав процесс тестирования для себя. Если ничего другого, то опыт откроет вам глаза на преимущества более частого тестирования кода.
Имея свои собственные данные, это здорово, потому что я могу использовать их для принятия решений о том, что должно измениться, а что — остаться прежним. Без моих собственных данных я чувствую, что летаю вслепую.
Инструменты иногда меняют результаты
Изначально я планировал просто использовать Apache Bench для запуска всех моих тестов. Однако некоторые случаи показали, что некоторые серверы, такие как WEBrick, плохо работают с Apache Bench. Итак, я использовал инструмент под названием wrk , который также используется в WebE Benchmarks TechEmpower .
Поскольку эти два инструмента работают по-разному, вы не можете ожидать одинакового числа запросов в секунду. Тем не менее, вы можете увидеть тенденции, которые совпадают между несколькими инструментами. Важно смотреть на тенденции, которые соответствуют обоим инструментам. Это помогает определить, где измерительный инструмент неверен до такой степени, что он искажает показатели производительности.
Точно так же, как вы калибруете весы с известным весом, вы должны убедиться, что ваши измерительные инструменты точны и разумны.
Были некоторые серверы или фреймворки, которым просто не нравились Apache Bench или wrk. В других случаях один сервер просто плохо работал бы с одним инструментом. В этом случае вы обвиняете инструмент, инфраструктуру, сервер или даже среду выполнения? Если вы потратите время на запуск тестов с несколькими инструментами для тестирования, вы увидите трещины. Иногда это просто очень крошечные глюки в большей системе, но в других случаях цифры никогда не согласуются с реальностью.
Итак, мой совет, когда дело доходит до инструментов сравнения, не слишком зацикливаться на одном конкретном инструменте. Используйте два, три или четыре в ваших собственных тестах. Вам не нужно идти за борт, но даже если вы просто запустите несколько инструментов тестирования для меньшего подмножества тестирования, у вас будет больше данных для работы.
Я надеюсь, что из этого раздела вы узнаете, что вы не можете сидеть на одном инструменте или наборе данных, потому что это, в конечном счете, приведет вас в заблуждение. Если вы проверите свои данные в нескольких инструментах, у вас будет лучшее представление об истинной производительности.
Ошибки приводят к хорошим разговорам
Одна из самых интересных частей выполнения тестов состояла в том, что результаты в конкретных сценариях привели к очень хорошим беседам с создателями платформы, среды выполнения и серверов.
В некоторых случаях для фреймворка требовался патч, потому что настройки по умолчанию не приводили к приличным результатам тестирования. В других случаях были исправления, которые могли значительно ускорить каркас. Было приятно услышать от создателей различных проектов, что я могу сделать, чтобы ускорить их результаты.
Другой разговор, который вылился из этого проекта, был о самой методологии. Каков наилучший способ запустить эти тесты? Должны ли они работать на локальной машине? Должны ли они запускаться на удаленных компьютерах для более адекватного моделирования условий в Интернете? Должны ли они работать в облаке? Это хорошие разговоры, потому что они приводят к лучшим данным и лучшим рассуждениям.
Я думаю, что самый захватывающий разговор был о том, какое влияние эти тесты оказывают на реальный мир. Учитывая, что я тестировал простое веб-приложение «Hello World», тест не предназначен для показа чего-либо, кроме теоретической максимальной пропускной способности. Я думал, что у вас никогда не будет приложения менее сложного, чем «Hello World», поэтому все остальное, что вы создадите, будет медленнее, чем это.
Однако другие люди возразили, что речь идет о разнице в пару миллисекунд, и для большинства приложений это не имеет значения. База данных почти всегда будет медленнее. Даже простое уменьшение размера файла на изображениях в большинстве случаев будет влиять на скорость загрузки страницы.
Я на самом деле согласен. Мы не говорим о различиях в производительности, которые сделают или сломают большинство приложений в реальном мире. При этом существует реальное представление о том, что Rails работает медленно, что привело к тому, что многие команды отошли от Ruby, когда их приложения должны масштабироваться. Я надеюсь, что эти сравнительные тесты покажут, что Ruby может быть быстрее, чем большинство людей его применяют.
Хорошо, что мои усилия по тестированию по крайней мере возобновили разговор о производительности Ruby и ускорили процесс. Я надеюсь, что разговор продолжается.
Мы всегда можем проверить больше
Последний урок, который я усвоил, состоит в том, что всегда есть что-то еще, что можно проверить, или какой-то другой вариант, чтобы попробовать. Как только люди увидели эталонный тест Hello World, им захотелось увидеть эталонные тесты базы данных, им нужно было больше фреймворков, различных конфигураций и т. Д. Это действительно здорово, и это выявило, что мы, вероятно, недостаточно проводим тестирование нашей работы.
Там не так много хороших данных о производительности различных частей наших систем и драгоценных камней. Какой фреймворк самый быстрый? Ну, это похоже на Кубу прямо сейчас. Какой ORM самый быстрый? Я понятия не имею. У меня еще нет данных по ORM. Как насчет кеширования? Что насчет анализа JSON? Вы поняли идею.
Существует множество данных о производительности, которых у нас просто нет. Тем не менее, если мы создадим культуру вокруг производительности и сравнительного анализа, я думаю, что мы сможем улучшить и принять более обоснованные решения относительно наших инструментов.
Заворачивать
Бенчмаркинг — это весело, хотя может быть немного времени. Сообществу Ruby было бы лучше, если бы мы все потратили немного больше времени на сравнительный анализ нашего кода, чтобы у нас было лучшее понимание и обзор программного обеспечения, которое мы создаем. Производительность не самая важная вещь для каждого приложения, но знание производительности нашего приложения поможет нам создать лучшее программное обеспечение, и это лучший результат для всех участников.
Ruby Web Benchmark является отправной точкой для изучения производительности, но я не намерен, чтобы она была конечной точкой. Я планирую продолжить исследовать мир высокопроизводительного Ruby, и если вы захотите последовать его примеру, я буду публиковать больше статей, тестов и связанных с ними проектов на моей странице высокопроизводительных рубинов, а также здесь, на SitePoint.