43  /  97

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

Просмотров: 20969
Дата последнего изменения: 17.01.2024
Сложность урока:
3 уровень - средняя сложность. Необходимо внимание и немного подумать.
1
2
3
4
5

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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



5
Курсы разработаны в компании «1С-Битрикс»

Если вы нашли неточность в тексте, непонятное объяснение, пожалуйста, сообщите нам об этом в комментариях.
Развернуть комментарии