Perfomance vs. scalability

Иногда встречаюсь c непониманием того, что такое производительность, а что такое масштабируемость. Почему-то некоторые люди считают, что это одно и то же.

С производительностью все более менее понятно. Это мера скорости работы системы. Запрос поступает в систему и через некоторое время система генерирует ответ. Это время (которое иногда называют latency) и является мерой производительности системы. Для интернет-приложений время получения ответа клиентом может быть значительно больше, чем время генерации ответа на стороне сервера (потери в канале, необходимость загрузки дополнительных статических ресурсов и т.д). Обычно эти издержки не учитываются при оценке производительности, хотя надо признать, они могут очень сильно влиять на user experience работы с приложением.

С масштабируемостью все немного сложнее . Если производительность это ответ на вопрос "как быстро?", то масштабирумость — на вопрос "как много?". Как много пользователей одновременно могут пользоваться ресурсом? Как много данных может быть в базе данных прежде чем она перестанет справляется с нагрузкой?

Иначе говоря, оптимизация под производительность подразумевает делать ту же работу используя меньше ресурсов. Под масштабируемость — используя больше ресурсов, делать пропорционально больший объем работы.

Это может показаться странным, но оптимизация под масштабируемость нередко приводит к худшей производительности. С точки зрения производительности наверное нет ничего лучше чем sql-вызовы прямо в шаблоне (зачем тратить лишнее время на вызовы полиморфных методов, да?). Но для того чтобы хорошо масштабироваться по объему данных в БД, необходимо уметь "пилить" нагрузку между серверами. А для этого требуется гибкий механизм диспетчеризации обращений к базе данных (ORM, ActiveRecord, DataMapper, DAO или что там у вас). Нам нужен некий промежуточный слой, который бы абстрагировал клиента от знания где именно (на каком сервере) лежат данные, которые он запрашивает. В зависимости от специфики реализации такие слои могут добавлять существенный overhead к latency ответа. И все это делается только ради того чтобы быть больше, а не быстрее (на самом деле делается гораздо больше, это всего лишь частный пример), потому что в большинстве случаев быть большим выгоднее, чем быть быстрым.

Только не поймите меня неправильно, я не хочу сказать, что быть быстрым не надо. Пользователи не будут ходить на ваш ресурс если страницы будут открываться по 10 секунд. Что я хочу сказать, так это то, что ваши пользователи не будут платить вам больше, если страницы вашего ресурса будут открываться не 0.2 секунды, а 0.1. Но если у вас будет в два раза больше пользователей...

Future Evolution of High-Performance Microprocessors

Довольно интерестное видео о тенденциях развития микропроцессоров. Norm Jouppi из Hewlett-Packard рассказывает о текущих проблемах и о том, что из себя будут представлять микропроцессоры лет эдак через 5-10.

Было много сказано, про power wall и про то, как растущее энергопотребление не дает наращивать частоты. При этом заметно упали темпы снижения базового напряжения, используемого микросхемами. Мне, как программисту, было интерестно в первую очередь другое, — каковы тенденции в развитии микропроцессоров.

Оказалось, что "гонка" за ядрами явление временное, а тенденции смещаются в сторону гетерогенных вычислений. А это значит, что довольно скоро компьютеры будут похожы на... PlayStation. В PlayStation 3 стоит процессор IBM Cell, который по своей архитектуре ближе всего к тому, что называется heterogeneous computing.

Идея гетерогенных вычислений довольно проста, в отличии от SMP где все процессоры в системе одинаковы, в гетерогенной архитектуре есть разные исполнители, которые с разной эффективностью выполняют разную работу. Существуют предпосылки для перехода к такой архитектуре.

Во-первых, мы не можем дальше наращивать частоту отдельного исполнителя (процессора/ядра), — слишком большое энергопотребление.

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

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

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

На самом деле, это сильное упрощение того, что говорил Norm Jouppi. Поэтому заинтересовавшимся советую посмотреть видео и слайды.