Часть 1. О производительности сайтов.

Проблемы с производительностью сайта рано или поздно начинают волновать почти всех.

За последние несколько лет, я постоянно занят на многих проектах, где вопрос производительности вообще никогда не снимается и постоянно контролируется.

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

Не существует одного подхода к решению задачи такого типа, который подошел бы всем сайтам, потому что причины разные.

Тормозной сервер

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

  • Медленный жёсткий диск — тогда решением будет замена на твердотельный SSD.
  • Мало оперативной памяти — тогда, если возможно, следует докупить оперативной памяти.
  • Если сайт производит множество вычислений, то надо поставить процессор мощнее или, если возможно, поставить ещё один.
  • Возможно, сайт вовсе не тормозит, и вся проблема состоит в пропускной способности интернет-канала — тогда надо заниматься решением этого вопроса: либо канал расширить, либо снять часть нагрузки с сайта. Например, отдавать изображения с другого сервера.

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

Проблема может быть в настройках сервера

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

У вас может возникнуть вопрос: почему я этот способ написал после апгрейда сервера?

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

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

Решение этой задачи потребует привлечения опытного админа и возможно даст свои плоды, но на его поиск уйдет некоторое время.

Если в базе данных накопилось много этих самых данных, то может помочь увеличение доступного количества используемой памяти под СУБД в целом или под индексы в частности. Или стоит попробовать перенос данных на другой диск.

Если затык в веб-сервере, то может помочь увеличение количества запущенных процессов или установка другого веб-сервера. Например, если на сервере стоит Apache2, то перед ним обязательно нужно поставить другой веб-сервер, Nginx, который лучше справляется с задачей общения с входящими запросами, а также защитит Apache от некоторых типовых способов атак.

Если админ сервера не смог решить проблему, то он точно должен её локализовать и выдать вердикт: тормозит вот такое приложение, оно жрёт такие и такие ресурсы. Надо чтобы жрало меньше или иначе (например, пускай жрёт оперативку, а не мучает диск — диск тормозной, а оперативки имеется вагон).

Код сайта требует улучшений

С такими данными вы уже можете идти к разработчику и выделять в его плотном графике время для оптимизации производительности.

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

Обычно, самым эффективным по соотношению результат к трудозатратам является разного рода кеширование. Этот подход убирает 70% проблем с производительностью. Ну или если не убирает, то хотя бы маскирует/затыкает, давая время на поиск/выбор другого решения, более надежного и долговечного. (Хотя, как показывает практика — нет ничего более постоянного, чем временный костыль 😁).

В следующих постах я расскажу:

  • О дорогущем сервисе, который позволил(не то что бы «помог», а именно «позволил!») нашей команде локализовать проблемы с производительностью на одном высоконагруженном legacy проекте, за время пробного периода в этом сервисе!
  • Как можно спроектировать сайты типы интернет-магазинов таким образом, чтобы убрать 90% причин, которые обычно приводят к тормозам и пятисотвторым ошибкам и всему вот этому, что вгоняет владельцев в тоску и панику одновременно.
  • На какие оптимизации стоит тратить время сейчас, а какие можно отложить, чтобы выполнить полезные с точки зрения бизнеса задачи, а не погрязнуть в вечной и/или преждевременной оптимизации.

Читайте далее: Часть 2. Какие бывают проблемы с производительностью универсальных коробочных CMS

Подпишитесь на новые статьи

Подпишитесь, чтобы получать новые статьи в числе первых!

Я не шлю спам. Отписаться можете в любое время! Powered by ConvertKit

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *