Если кого-то волнует, куда я пропал и почему так затих – всё очень просто – я ушёл в работу.
На этой и прошлой неделе моей любимой темой был Load Balancing.
За это время я успел познакомиться с возможностями Lighttpd и его mod_cache, mod_proxy, mod_proxy_core, поставить FreeBSD, на нём закрутить Lighttpd + PHP под FastCGI. Кроме того пересмотрел nginx и его ngx_http_upstream и взглянул на Apache 2.2 с его mod_proxy и mod_proxy_balancer.
Больше всего мне понравились Lighttpd и Apache 2.2. Жаль, вот только, что Apache – это жирноватая корова по сравнения с Lighttpd, а с Lighttpd пугает его свойство зависать на огромной загрузке, и не ясно, избавились ли от него; и очень огорчил mod_cache у Lighttpd – я думал это полноценный модуль, а это ужасных хак. Этот хак не входит ни в одну стандартную постановку моего любимого FreeBSD, а ведь та простота, с которой можно организовать кеширование манит. mod_proxy_balancer доступен только от версии 1.5, а она ещё не признана стабильной, а возможностей у него куда больше, чем у mod_proxy.
Вообще, чти я скажу – ситуация в выборе ПО для Load Balancing на уровне HTTP отличная – выбор есть, нет ничего сложного в реализации, главное выбрать определённую платформу. В ближайшие месяцы я уже наверное смогу сказать, что выбрано и как себя ведёт.
Ещё, что касается Load Balancing – так пересмотрел в MySQL как работает Replication и даже дома собрал небольшую модель из одного мастера и 3 слейвов, посмотрел как всё запускается, как реплицируются данные, как ведёт себя сервер после падения на короткий срок и восстановления работоспособности.
Кстати, MySQL выпустил интересное начинание: MySQL Proxy. Если к версии 1.0.0 она была-бы стабильная, отлично поддерживала балансирование и кешинг, плюс возможность задать read-only и write-only сервера, да и документации сопровождающей много с примерами – получилась бы отличное решение для загруженных систем.
Ещё в исследование входило общее поднятие Performance у сайта.
За всё время ещё не мало перечитал дополнительной литературы (блоги, статьи, касты разные) по MySQL, оптимизации запросов, планировании индексов, их использовании, оптимизации запросов со стороны MySQL. В Google Reader было добавлено не мало ресурсов связанных как с оптимизацией MySQL, так и на темы Load Balancing. Так-же в этой теме очень сильно помогают разные тесты на средних и больших кол-вах данных. Не раз запускался ab – Apache HTTP server benchmarking tool, который позволял сравнить время работы разных запросов к тем-же данным с/без индексов и прочих мелких условиях.
Тяжело сказать, конечно, что всё это блоги и “добавлено в Google Reader”, просто всё это читалось, курилось, переваривалось:
High Scalability – Building bigger, faster, more reliable websites.
MySQL Performance Blog
Domas Mituzas – специалист по MySQL + поддержка Wikipedia рекомендую Wikipedia: site internals, etc (the workbook)
Load Balancing Your Web Site
Performance Tuning Best Practices for MySQL
MySQL Manual Index Hint Syntax
Optimizing Queries with EXPLAIN
FastCGI in PHP. The way it could be
Lighttpd Performance Improvements
Lighttpd Optimizing FastCGI performance
Understanding FastCGI Application Performance
Squid: Accelerator Mode
XCache
Faster Is Possible
Using X-Accel-Redirect Header With Nginx to Implement Controlled Downloads
Lighttpd X-Sendfile
Scaling with MySQL replication
Может чего и забыл – у меня нет лаптопа (я их ненавижу), поэтому часть ссылок ещё есть на другой машине, и возможно завтра я их тоже добавлю сюда.
По последнему абзацу. Выложи все ссылки, что нарыл по теме оптимизации производительности. Не один я благодарен буду :)
Знаешь, ценность этого всего исследования не в кол-ве ссылок или блогов, которые я нашёл, а в том, что я проделал, сколько из этих HTTPD поставил и как настроил, сколько их опробывал только что-бы увидеть как оно работает, сколько ещё в форумах тредов прочёл с разрешением разных проблем.
Через неделю все эти ссылки не будет иметь никакой цены и важности – в сети появиться ещё куча новой инфомации об этой теме.
Все те решения, которые я опробывал и пересмотрел могут подойти мне в моём конкретном случае, и не подойти другим.
Моё мнение:
Вся оптимизация заключается в уменьшении времени и ресурсов нужных для генерации страницы, либо в увеличении технических ресурсов для покрытия той можности, которая нужна для обслуживания клиентов.
Распределение нагрузки – в правильно выбранном и настроенном балансире и сети между серверами. Ну и надо систему иногда менять, переделывать систему хранения сесий, работу с базой данных.
Здесь много нюансов, которые сами всплывут по нужде и по обстоятельствам, если этим занимаются башковитые люди.
Ссылки ценны сами по себе. В отрывы от исследования. Потому что каждый пост несет какую-то новую информацию, которую можно проанализировать.
У нас вот например под балансер выделена отдельная машина, на ней стоит nginx, на бекендах также nginx, статика вынесена на отдельный хост, в sql стараемся максимально избавляться от блокирующих запросов, например count (*), все кешируемые блоки выносим в мемкеш. Пока он на бекендах, но скоро купим пару машин которые максимально забьем памятью под мемкеши.
Чтож, был рад чем-то помочь.
Примерно о такой-же структуре думаю и я сейчас, только вместо NGINX будет Lighttpd (скорее всего, но последнее слово не за мной), а вот на бякэндах останется Apache – переделывать то, что сейчас сделано и работает стабильно особой нужды нет.
Запросы на этом проекте уже достаточно вылизаны, так местами со свежего взгляда только что если заметим, а вот от count (*) избавиться наврятли везде сможем, только если кешировать часть на время.
Так как пока кеширование происходит полностью в статические файлы на жёстком диске – memcached ещё нет (вот по этому я бы сейчас предпочёл туда Lighttpd в режиме hash), но, всё-же в ближайшее время туда захотят добавить динамики и без memcached уже никуда.
Кстати, дома нашёл в истории ещё:
10 Tips for Optimizing MySQL Queries (That don’t suck)
MySQL Optimization: Slow Query Logs and Indexes
High Performance Web Servers
mtop/mkill – MySQL Monitoring Tools
Да, те каунты от которых нельзя избаится кешируем, как ты и предполагаешь.
А от файловых кешей мы отказались, они дают дополнительную нагрузку на сервер + мемкеш быстрее.
А с сервисами файло(-обменников, -хранилищ) типа рапидшары и т.п. какой-то другой подход к распределению нагрузки?
Не знаю, не интересовался, но, возможно они используют что-то близкое к технологии GeoDNS (это ближе к CDN) или рандомной DNS.