Прочитав в этом блоге о балансировке на стороне клиента, решил опубликовать свою статью, в которой описаны основные принципы масштабирования для web-проектов. Надеюсь, хабралюдям будет интересно почитать.

Основы масштабирования

Масштабируемость — способность устройства увеличивать свои
возможности
путем наращивания числа функциональных блоков,
выполняющих одни и
те же задачи.
Глоссарий.ru

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров — обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности — это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке — сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.

1 часть — тут

Проблема 6. Клиент никогда не знает стоимость работ.

Очень редко приходится встречать клиента, который понимает, сколько стоит реально то, что требуется сделать — большая часть клиентов имеют некий бюджет и пожелания того, что нужно сделать в итоге. Обычно ни о техзаданиях, ни о рейтах (оценка часа работы в денежном эквиваленте) — они ничего не слышали или слышали, но не сталкивались.

Методы решения:

А по-русски, платформонезависимый фреймворк для создания многозадачных и сетевых приложений на Perl.

POE позволяет достаточно просто и быстро создавать многозадачные приложения, особо не задумываясь об управлении процессами и другими приятными вещами, с которыми приходится сталкиваться при желании написать многозадачное приложение. Всю эту нагрузку на себя берет POE, мы лишь описываем, что мы хотим делать. В большинстве случаев все приложение выполняется одним процессом, но при необходимости, POE умеет порождать дочерние процессы и общаться с ними.

Читать далее...

JT Smith, президент Plain Black, создатель WebGUI, и одного из незамеченных успешного применения Perl в бизнесе, недавно прислал мне это эссе. Он разрешил мне издать его полностью здесь.

Кажется, каждый день меня спрашивают, почему я пишу на Perl, а не на PHP, Java, C#, Ruby, Python, или [вставьте ваш любимый язык здесь]. Люди говорят «Perl больше не используется, не так ли?» Сейчас, когда я пишу это, есть миллионы Perl программистов во всем мире. Perl5 активно поддерживается, и разрабатывается Perl6. Более 3000 модулей Perl было выпущено в 2006, и более чем в 2 раза, должны быть выпущены в этом году. Действительность состоит в том, что Perl совсем не умер.

Примечание: мини-статья написана для новичков

Давайте посмотрим вокруг: форумы, интернет магазины, гостевые книги и т.д. используют регистрацию и последующую авторизацию пользователей. Можно даже сказать, что это почти необходимая функция каждого сайта (только если это не домашняя страничка Васи Пупкина или не визитная карточка, какой-нибудь небольшой компании). Сегодня я хочу поделиться со всеми новичками информацией, о том, как лучше это все реализовать.

А вы знаете, что в 99% приложений и абсолютно всех CPAN-модулях таймеры и таймауты реализованы неправильно? Не верите? Правильно не верите! Есть, есть один CPAN-модуль, с корректной реализацией таймеров: EV. :) (Кстати, это, похоже, единственный CPAN-модуль из всех, реализующих event loop, который знает о проблеме использования fork вместе с event loop, описывает её в документации и даже пытается как-то решать!)

Проблема в том, что для реализации таймеров и таймаутов используются функции, возвращающие текущее время. А текущее время может быть изменено в любой момент в любую сторону на любую величину — админом или NTP-демоном. Поэтому получается так, что, например, таймаут установленный программой на 30 секунд, может сработать либо через 2 секунды, либо через пару суток — смотря как изменится текущее время после установки таймаута (а в особо запущенных случаях может не сработать никогда).

Единственный надёжный способ работать с таймерами и таймаутами — использовать монотонное время:
use Time::HiRes qw( clock_gettime CLOCK_MONOTONIC );
$now = clock_gettime(CLOCK_MONOTONIC);

Поддержка CLOCK_MONOTONIC была добавлена в Time::HiRes (по моей инициативе :)) два года назад. И вот сегодня я снова, как и два года назад, поискал на CPAN модули с правильной реализацией таймеров и таймаутов… и нашёл только один. :(

На днях вышел первый кандидат Perl-а на релиз — 5.10.0 RC1. А ведь прошло 5 лет с момента предыдущего релиза (5.8).

Так что же интересного нас ждет в 5.10?