Не знаю почему, но по умолчанию настройки MySQL рассчитаны на десктопы 90-х годов. Например, 8Mb памяти под индексы InnoDB. Помните, как Билл Гейтс заявил, что «640 Кб памяти должно хватать каждому». Дефолтные настройки MySQL из этой серии.

Для начала моя выжимка из конфига (4G RAM, AMD Athlon 64 X2 Dual 5600+)

# ТОЛЬКО UTF! ТОЛЬКО ХАРДКОР!
collation_server=utf8_general_ci
character_set_server=utf8
default-character-set = utf8

# по умолчанию пускай будет InnoDB
default-storage-engine = InnoDB

key_buffer_size = 512M
innodb_buffer_pool_size = 512M
innodb_additional_mem_pool_size = 16M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 8

join_buffer_size = 8M
sort_buffer_size = 8M
read_rnd_buffer_size = 8M
tmp_table_size = 64M
max_heap_table_size = 32M
table_cache = 256

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 1

query_cache_type       = 2
query_cache_limit        = 1M
query_cache_size        = 32M

(далее...)

Как известно, PHP — интерпретируемый язык, т.е. каждый раз при обращении к скрипту, этот скрипт компилируется. Если у вас 1 скрипт, то ничего страшного нет, так как время компиляции не большое. Но в современных CMS и фрэймворках при отображении страницы используется 10-300 отдельных php-файлов (проще говоря, инклуды). Чем больше инклудов и чем они тяжелее, тем дольше выполняется процесс компиляции. (далее...)

В Nginx есть простая конструкция для кэширования статических файлов на клиенте. Тем самым страницы загружаются быстрее, а сервер не нагружается повторными запросами. Картинки, стили практически не меняются, поэтому ставим 10 лет и не паримся. Даже если файл стилей изменился, то надежней всего добавить какой-нибудь мусор в GET-параметры (например, /style.css?version=23)

server {
     ...

     location ~* ^.+\.(jpg|jpeg|gif|sfw|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
	 root /.../www/ekimoff.ru;
	 access_log   off;
	 expires  10y;
	 add_header  Last-Modified: $date_gmt;
	 error_page 404 = @fallback;
     }

     ...
}

Результат в FireBug

Статья для новичков. Memcached – это такая штука для кэширования данных в оперативной памяти сервера. (далее...)

Статья для новичков. В MySQL есть встроенное кэширование запросов. Подробнее можно почитать на Хабре. Тут я скажу о главном плюсе и главном минусе такого кэширования и приведу пример своего сервака. (далее...)

В форумном движке phpBB кэширование реализовано через файлы. Кэшируется всё подряд. Например, каждый sql-запрос кладется в отдельный файл, а так как для каждого пользователя выборка из базы может отличаться, то кэш вырастает до 150 000 файлов — реальный пример из жизни (на форуме всего лишь 70 тем и 700 пользователей). Всё это дерьмище лежит в одной папке и немного нагружает чтение с диска. Но в моем случае проблема была в обновлении кэша. Дело в том, что кэшируются еще и шаблоны. Поэтому при изменении шаблона, нужно обновить кэш — это можно сделать через админку. Вот здесь и начинаются проблемы с удалением из папки с десятками тысяч файлов. Скрипт удаления кэша падает с ошибкой 500. (далее...)

Вводная лекция про особенности архитектуры высоконагруженных проектов.
Кстати, это автор шаблонизатора Blitz.

Постепенно буду выкладывать интресные доклады с IT-конференций.
Вот например, отличный доклад про Memcached

Лекция про кэширование, репликацию и шардинг. Кстати этот чувак является одним из авторов книги по разгону MySQL

Статья для новичков. Самый простой и доступный способ кэширования – это кэширование на файлах. Хотя оно и самое медленное. Возьмем для примера мой блог. (далее...)

Довольно часто проблема кэширования возникает при тестировании скриптов на локальной машине.
Лекарство:

header("Expires: Mon, 08 Jun 1985 03:00:00 GMT"); // мой день рождения:)
header("Cache-Control: no-cache, must-revalidate");
header("Pragma: no-cache");
header("Last-Modified: ".gmdate('D, d M Y H:i:s')." GMT");