Сергей Куракин - личный сайт

Так как тема Load Balancing мне сейчас очень актуальна, я иногда посматриваю на большие Литовские проекты со стороны пользователя и задумываюсь, что они делают. Хотя, может это и не особенности местного Load Balancing, но я уже второй раз встречаю такое решение на довольно популярном проекте. Если кто знает в других местах подобные модели, или причины - пишите в коммнетарии, мне очень интересно.

Сейчас в ЛитНете очень популярен один проект, клон YouTube.com - маленький Литовский videogaga.lt. О нём сейчас пишут в Литовский блогах, писают кипятком, так как он очень вовремя появился в Литве и позволил незнающим английского легко загружать своё видео в интернет и делиться с друзьями. Ах, как хорошо.

Я совсем не знаю что у них на “в заде”, но вот с переди кажется, что они пошли не тем путём. Придя на www.videogaga.lt вас перенаправят на www1.videogaga.lt, ещё есть www2.videogaga.lt, www3.videogaga.lt, www4.videogaga.lt (у всех разные внешние IP). Если я правильно понял, они при помощи 4 субдоменов и редиректов распределяют нагрузку.

Похожим путём пошли и всем в прибалтике известные one.lt, причём задолго до videogaga.lt. Куча серверов,внешние редиректы и всё зависит от удачи - повезёт, попадёш на незагруженный сервер, не повезёт - будешь ждать ответов (по крайней мере так говорят пользователи). Я не в курсе конечно отношений и производителей, но у меня есть ощущение, что всё делала одна и таже контора.

Хотя я могу быть и не прав в своих домыслах и все эти субдомены предназначены для других целей?

Вот такие особенности я заметил…
Я вот не понимаю, почему суб-домены, почему дублируется содержание? Почему в переди не поставлен распределящий нагрузку proxy, как это сделано у Google (хотя хер знает как там, но главное что все мы ходим через www.google.com а не через www1.google.com, www2.google.com, … www1024.google.com) или на том-же flickr.com или YouTube.com? Нет, я согласен - статическое содержание может отдавать ферма под другим субдоменом (как у flickr.com), но основное и динамическое содержимое всегда как-бы должно с одного домена идти. Но всё-же зачем субдомены и редиректы? Почему?

А вот и ссылочка, кстати. Оба проекта стоят на сервере Resin/2.1.6. В Google по запросу Resin на первом месте сайт caucho.com. Оказывается какой-то хитрый HTTP сервер, который high-performance с load balancing. Нужно будет расковырять его, посмотреть что он, как он и зачем он.

Bookmark:

Если кого-то волнует, куда я пропал и почему так затих - всё очень просто - я ушёл в работу.

На этой и прошлой неделе моей любимой темой был 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, который позволял сравнить время работы разных запросов к тем-же данным с/без индексов и прочих мелких условиях.

(далее…)

Bookmark:

1. Мне нравиться PHP
2. Мне очень нравиться PHP
3. Мне нравиться то, как сделан Zend Development Environment и то, что Zend Development Environment прекрасно поддерживает Zend Framework с подсказками кода
4. Мне нравиться то, что я всегда без проблем могу посмотреть в исходники Zend Framework и разобраться что к чему
5. Мне нравиться Zend Framework потому что я могу продуктам с его использованием спокойно делать стандартный debug с Zend Development Environment, поставить Break point там где хочу и посмотреть как оно там всё происходит
6. Мне нравиться, что я его могу тупо скачать как ZIP или TGZ, закинуть на сервер куда угодно, прописать в include_path и радостно пользоваться им как хочу
7. Мне нравиться, про я могу использовать разные шаблоны запуска/создания проекта, именно такие, какие мне нравятся или кажутся нужными для проекта
8. Мне нравиться, что PHP можно без проблем за несколько минут поставить почти на любую платформу, а значит там можно запустить Zend Framework

Bookmark: