“Highload” оптимизация для самых маленьких

Это скорее не статья, а так заметка, на которую следует ссылаться, если кто-то не думает о том что в проекте может быть записей больше, нежели в тестовой базе данных, а скорость интернета меньше нежели доступ по локальной сети в 100мбит.

Исходя из моего опыта разработки (да и не только моего), зачастую, «бутылочным горлышком» вашего приложения является база данных, таким образом перво-наперво включаем slow query log (← это ссылка на гугло-поиск) и смотрим какой запрос у нас самый медленный, и думаем что с ним делать, если не можем вкурить проблему — зовём старших, пусть тоже повтыкают в EXPLAIN (← ссылка на документацию → на хабр) вашего чудо-запроса.

Но, опять же ссылаясь к моему опыту, большинство проблем с БД решают правильные индексы. Легко запомнить, что индексировать следует внешние ключи, и всё что у вас в WHERE, ORDER BY, GROUP BY (список не полон, для начала – самое оно).

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

Поиск с использованием LIKE это плохо. Полнотекстовый с MyISAM уже лучше. Внешний аля Sphinx — рулит и бибикает для MySQL и PostgreSQL, инфа достоверная 100%.

Но это полбеды, проблем в БД может подкинуть и само приложение — обращение к БД в цикле/рекурсии или еще каким извращенным способом могут привносить удивительные поправки в результаты нагрузочного тестирования. Сделайте простой профайлер ваших запрос и проследите на каких страницах количество запросов начинает зашкаливать (особенно это касается типа-ORM и почти-Active Record, когда один объект = один запрос, или даже не один). Всем кто уповает на магию фреймворков, иль каких-нить gem-ов — не надейтесь, всё о чём я написал в равной степени относится к большинству языков web-программирования, г..код есть везде, он вездесущ.

Ну, а теперь о главном, нет о главной странице в 1,5 метра — дождется ли её загрузки пользователь со скоростью доступа в 256кбит? Клиентская оптимизация должна проводиться в обязательном порядке: YSlow да Page Speed вам в зубы. Да если погуглить, то даже небольшая правка htaccess для apache улучшит ситуацию:

# Enable ETag
FileETag MTime Size
 
# Enable Deflate
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/x-javascript
 
<ifModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 1 seconds"
  ExpiresByType text/html "access plus 1 seconds"
  ExpiresByType image/x-icon "access plus 2592000 seconds"
  ExpiresByType image/gif "access plus 2592000 seconds"
  ExpiresByType image/jpeg "access plus 2592000 seconds"
  ExpiresByType image/png "access plus 2592000 seconds"
  ExpiresByType text/css "access plus 604800 seconds"
  ExpiresByType text/javascript "access plus 216000 seconds"
  ExpiresByType application/x-javascript "access plus 216000 seconds"
</ifModule>

Пожмите JavaScript и CSS, да переключите jQuery на Google CDN. И я это уже постил, между прочим…

С уважением, ваш КО

15 thoughts on ““Highload” оптимизация для самых маленьких”

  1. То что ты описал это не high load, а оптимизации производительности приложения.
    Когда говорят о High Load – это о том как строить горизонтально масштабируемые системы. При нагрузки 10000 запросов в секунду никакие YSLow и оптимизации MySql не помогут.

    1. Я в курсе, смайла irony просто нет :)
      Highload теперь в кавычках, чтобы не вносить смуту

    2. А ссылочку на статьи про горизонтально масштабируемые системы можно?

  2. А теперь можно углубиться в вопрос, пожалуйста?
    Рассказать более некэповские моменты:)

  3. Выборки с LIKE – это не всегда плохо. Если у поля есть индекс, и запрос выглядит как url LIKE ‘http://google.com/%’ – все в порядка. С другой стороны, полнотекстовый поис MyISAM – не всегда хорошо. Если в таблицу добавляется много записей, то вся оптимизация сойдет на нет из-за блокировок. Будьте аккуратны :-)

  4. Начиная с какой нагрузки на сайт стоит начинать заморачиваться?

    1. С той – с которой сайт работает не достаточно быстро

  5. Спасибо за статью. Интерестно было бы почитать такую же для оптимизации клиентской стороны.

    1. отличная статья. спасибо за ссылку=) и текущая статья тоже:)

    2. честно говоря, статья – сплошная вода.. нужно больше примеров, больше по сути. пример с метрополитеном мне понравился.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.