Производительность

Создать хорошее веб-приложение не сложно. Для этого достаточно обеспечить:

• согласованность данных (англ. consistency) (во всех вычислительных узлах в один момент времени данные не противоречат друг другу);
• доступность (англ. availability) (любой запрос к распределённой системе завершается корректным откликом);
• устойчивость к разделению (англ. partition tolerance) (расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций).

Однако при этом задачу высокой производительности никто с разработчиков не снимает. Создать "быстрое" приложение не сложно. Для этого достаточно:

• Формализовать требования производительности, которые высказывает клиент.
• Понять принципы создания высоконагруженных, масштабируемых приложений.
• Научиться логировать метрики.
• Научиться анализировать их (самое сложное).
• Запустить процесс с обратной связью.
• Свести анализ к маленькому набору индикаторов.

  Клиентские требования по производительности

Чётко поймите, что именно для клиента означает "производительный сайт" и формализуйте эти требования. Большинство клиентов ориентируется на другие ресурсы и, как правило, говорят: "быстро как там-то". Такой ответ не должен вас удовлетворять. Требования должны быть чётко формализованы: Главная - 0,5 секунд, детальная - 0,3 секунды, "Умный фильтр" не более 1, 5 секунд.

Производительность JS в этом плане - первое, с чего надо начать. JS должен работать быстро.

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

В итоге получается что верстальщик и JS-разработчик - это основные люди, отвечающие за производительность с точки зрения клиента.

При работе с SSL рекомендуется использовать SPDY через модуль NGNIX, ускоряющий загрузку.

  Проблемы на клиентской стороне

Коллективная разработка при неумелой организации процесса также создает проблемы, по принципу: "У семи нянек дитя - без глазу". Тем более, что тестирует это все, как правило один человек, который просто не успевает сделать проверку всего и ограничивается только проверкой работы (а не скорости работы) созданного функционала.

Другая проблема - управленческая. Если руководство не понимает проблем разработки и качества разработки и его волнуют только сроки. В этом случае практически всё делается второпях, не оптимально и "на скорую руку".

Другие ошибки:

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

Полезные рекомендации по клиентской производительности можно также почерпнуть тут.

  Проблемы на серверной стороне

Создать себе реальные проблемы на серверной стороне можно с помощью:

• Непродуманной отдачи статики;
• Медленной генерацией динамического контента.

Для избежания проблем со статикой оптимальным решением будет использование CDN. Но, если в силу каких-то причин это неприемлемо, можно вынести статику на отдельный домен, что позволит скачивать её в несколько потоков. Либо перенести статику на отдельный сервер(ы) с быстрыми дисками.

На скорость генерации динамического контента в первую очередь влияет качество программирования. Сама по себе БД не тормозит. Тормозят запросы, которые задаются разработчиком.

При прогнозируемых больших объёмах данных рекомендуется познакомиться с теоремой CAP, NoSQL, изучить репликацию, изучить и использовать Galera.

  Материалы по теме

• Обеспечение производительности при эксплуатации проекта