Мы не раз обсуждали вопросы производительности и масштабирования систем (этому и посвящен этот блог). Тем не менее, иногда очень полезно возвращаться к истоку этих понятий. Это важно для понимания их сути, а следовательно и для того, чтобы принимать правильные решения в нужные моменты времени.

Зачастую эти два понятия тесно связаны, но представляют собой два абсолютно разных свойства системы:

• Производительность - способность системы выполнять операцию за определенное допустимое время (другими словами, достаточно быстро)
• Масштабируемость - способность системы справляться с увеличивающимися нагрузками (обычно - путем наращивания аппаратных ресурсов)

Почему эти важно?

Если не думать об этих вопросах, не будет шансов для роста. Производительность Вашей системы означает, что Вы справляетесь с запросами сегодня. Масштабируемость же обеспечит способность справиться с запросами в будущем.

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

Какой язык выбрать?

Это неважно! В большинстве своем проблемы производительности лежат вне кода системы. Проблемы таятся в архитектурных решениях, но очень редко в их реализации. Даже столкнувшись с неудачной реализацией, затраты на ее исправление не сравняться с затратами на изменение архитектурных решений.

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

Когда начать?

Начинать решать вопросы производительности и масштабирования нужно только (и только!) тогда, когда они возникают. Никогда не стоит заниматься решением несуществующих проблем во время разработки системы. Опыт говорит о том, что абсолютно все системы испытывающие потребность в росте в большинстве случаев сталкиваются с проблемами, о которых на стадии разработки и предположить не могли.

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

Когда остановиться?

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

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

Общие правила эффективности

Опыт многих и многих можно свести к нескольким очень важным рекомендациям:

• Профилируйте всегда и с самого начала
• Тестируйте изменения на реальных данных (Вы не представляете, какие затычки можно будет обнаружить)
• Собирайте статистику и следите за динамикой всех аппаратных и програмных узлов
• Не делайте предположений, и не решайте несуществующих проблем - это может стать самой большой ошибкой
• Планируйте изменения, но не делайте их без надобности

Вопросы масштабирования

1. Изолируйте компоненты системы (как програмно, так и аппаратно)
2. Кешируйте
3. Распределяйте СУБД по разным физических серверам (федерация)
4. Используйте репликацию
5. Анализируйте все технологические решения на предмет масштабирования и избегайте тех, с которыми могут возникнуть проблемы

Вопросы оптимизации

1. Разрабатывайте системы с учетом возможности внедрения кеширования данных (всех данных!)
2. Используйте внешние ресурсы максимально редко (если есть возможность не инициировать соединение с СУБД на каждой странице, обязательно используйте ее)
3. Не изобретайте велосипед - используйте средства платформы максимально обширно (а современные платформы имеют огромные арсеналы всевозможных инструментов)
4. Используйте прекомпиляцию и кеширование кода (естественно в случаях, когда этого не предусматривает стандартная поставка платформы)
5. Избегайте огромных циклов или высокой вложенности рекурсий

К дополнение ко всему написанному, обязательно посмотрите отличный доклад, посвященный обсуждаемой тематике (по нему и была написана эта обзорная статья):

Scalability and Performance Best Practices -

Как Вы планируете изменения при росте?

Статьи по теме

• Масштабируемость и производительность… Первые вопросы
• Масштабирование - худшие практики
• Twitter.com - архитектура и масштабирование
• Масштабирование в Web - опыт Ebay