“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. И я это уже постил, между прочим…

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