Сейчас развлекаюсь написанием универсального интерфейса к разным хранилищам (в первую очередь, это FS, memcached, memcachedb) с записями вида key+value. В качестве основы, создал универсальный интерфейс:

module type STORAGE =
        sig
                type t
                type storage_descr_t
 
                val init: storage_descr_t -> t init_result
 
                val get: t -> Key.t -> get_result Lwt.t
                val get_list: t -> Key.t list -> get_result Lwt.t list
 
                val delete: t -> Key.t -> delete_result Lwt.t
 
                val set: t -> Key.t -> ?value_size:value_size -> value -> set_result Lwt.t
                val add: t -> Key.t -> ?value_size:value_size -> value -> add_result Lwt.t
                val replace: t -> Key.t -> ?value_size:value_size -> value -> replace_result Lwt.t
        end

Написал модуль FileSystem, реализующий такой интерфейс. Поскольку файлы могут быть (условно) бесконечного размера, это стало самой простой реализацией интерфейса. Но не всё в жизни так легко. Например, memcached имеет максимальный размер пары key+value где-то в районе 64KB. А хочется в нём хранить побольше. Да и файловые системы бывают дурные. Напрмер, не позволяют создавать файлы больше 512MB. Поэтому на основе FileSystem (ключевое слово import) был написан маленький модуль FileSystemSized, который помимо value пишет в файлик размер value. Штука, на первый взгляд, бесполезная. Но идём дальше. Создаём функтор Splitted, который принимает модуль с интерфейсом STORAGE и делает модули с тем же уже знакомым нам интерфейсом STORAGE. Этот функтор хитрый: он знает, какого максимум размера value может хранить переданный ему модуль. Если в одну запись не влазит — он бьёт value на кусочки, для каждого кусочка генерит свой уникальный ключ, и таким образом пишет. В первом кусочке он сохраняет реальный размер всего value. Вот зачем нам нужен был модуль FileSystemSized. На основе этого функтора получается чудесный модуль FileSystemSplitted. По образу и подобию можно сделать MemcachedSplitted. Или даже FileSystemSplitted_and_again_Splitted, только я не придумал зачем :)

Мыслим вперёд. Ключ у нас — строчка строгой длины, с равной вероятностью имеющая в первом/втором/третьем/… байте любое из значений 0..255. На основе первого байта ключа, мы можем раскидать пары key+value на 256 физических хранилищ (ну, или меньше, как захочется). Назовём такой функтор Distributed, и он тоже будет создавать модули с интерфейсом STORAGE. Получается изумительная картинка:

(* Создаём уже знакомый нам модуль для хранения больших значений
   в маленьких файлах.
*)
module FileSystemSplitted = Splitted(FileSystemSized)
 
(* Каждое значение хранится в одном файлике, но файлики раскидываются
   по разным директориям.
*)
module FileSystemDistributed = Distributed(FileSystemSized)
 
(* Каждое значение пилится на части, части раскидываются по разным директориям.
   С remote mount, получаем хранилище бесконечного размера для почти
   бесконечного количества значений.
*)
module FileSystemDistributedSplitted = Splitted(FileSystemDistributed)
 
(* Каждое значение хранится в одной директории, но там оно пилится на части.
   Директорий для хранения может быть несколько. Хранилище получается тоже
   бесконечным, но наполняется не так равномерно.
 *)
module FileSystemSplittedDistributed = Distributed(FileSystemSplitted)

Как видите, с помощью фактически одного интерфейса и двух функторов, получаем невероятное, лютое количество вариантов хранилища. Даже круче, чем в GlusterFS или GNU Hurd. А ведь мысль можно продолжить ещё дальше, дописав функторы Raid0 (писать значение в несколько хранилищ), Clustered (создаётся на основе списка хранилищ, умеющих только читать и списка хранилищ, умеющих изменять), Flock (за счёт некоторого performace degradation, делать exclusive lock на записи)… чем я и занимаюсь :) Замечу, что всё это в функционально чисто, без side-effects (они есть только на уровне хранилища) и безумно типобезопасно.

Самой большой моей ошибкой в проектировании была идея использовать POSIX треды. Всё замечательно, но только до тех пор, пока активных соединений не становится больше сотни. Дело в том, что такие треды, по сути, являются почти что отдельными процессами: у них свой стек, их обрабатывает шедулер ядра и т.д. Единственное отличие — у них в пределах одного процесса единое адресное пространство. Так вот, всё это вызывало такие проблемы, как переполнение стека, нелинейность масштабирования и пр. В качестве альтернатиы рассматривалось два варианта:

1. Библиотека Equeue. Знаменита тем, что предоставляет низкий уровень к управлению очередями обработки дескрипторов. Это и минус — работать с ней не слишком комфортно: “есть только очередь и события, всё остальное на ваше усмотрение”.
2. Библиотека Lwt. По сути, то же самое, но выполнено совсем, совсем с другого бока. В интерфейсе предоставляется модель монад и псевдопотоков (отсюда название: LightWeight Threads). Быдлокодеру, навроде меня, достаточно лишь описать зависимости между состояниями: что делать, когда я получу данные из вон того сокета, и куда их записать потом.

Выбор пал на Lwt. А вот тут следует сказать несколько восторженных слов о типизации Хиндли — Милнера, используемой, в том числе, в Ocaml. Как я уже сказал, потоки POSIX при разработке выглядят практически как отдельные процессы. Создал поток, и забыл о нём, а он варится сам по себе. В Lwt же надо отдельно позаботиться о последствиях каждой операции IO. Прежде всего, я заменил все вызовы Unix.socket (создание сокета) — благо в коде почти все они были в моей обёртке и реально вызов встречался только в 2-3 местах — на Lwt_unix.socket. И понеслось. Типовычислялка компилятора сразу указала мне, где я, дурень, пытаюсь подсунуть в нормальную сокетную функцию параметр с каким-то странным типом Lwt_unix.file_descr. Следующая неделя прошла за чрезвычайно интеллектуальной работой. Компилятор говорил мне, что нужно сделать чтобы впасть в нирвану, а я всячески пытался её достичь. Таким образом, буквально через несколько дней негритянской работы, передо мной предстал код, который мало того, что не содержал ни одного вызова к стандартным функциям IO, так ещё и компилился.

Каково же было моё удивление, когда с первым запуском оно ещё и заработало! После недели тупой работы, перехода с философии “одно соединение == один самостоятельный псевдопроцесс” на “одно соединение == один конечный автомат”, после исправления тучи кода исключительно по указаниям компилятора! Кривенько, но заработало, результат я увидел. Последующая неделя ушла на исправление совсем новых багов, багов ещё со старой версии и дописывания новых приятных мелочей.

Итого, имеем. Кластер с определённым количеством клиентов (пока меньше, чем на одной машине в среднем, но уже существенно). Прокся заведует как балансировкой нагрузки между HTTP-узлами, так и между MySQL. Т.е. гоняются вполне реальные данные настоящих сайтов. На одно соединение (не запрос) HTTP в среднем уходит чуть меньше миллисекунды CPU (это и проксирование динамики, и отдача статики с помощью системного sendfile). На соединение MySQL уходит несколько больше — около 5 миллисекунд, хотя алгоритм там наоборот в целом проще. Связываю это с

• sendfile() там не применишь, все проксируемые данные копируются в userspace
• Имею богатый опыт разглядывания скриптов клиентов. А это совсем другая, удивительная, не поддающаяся научному изучению культура. У них принято сказать SELECT * на большую табличку, затем сложным алгоритмом с циклами тройной вложенности вычленить из многомегабайтного результата 2 строки, затем их отправить обратно в мускуль с целью join’а в непристойной позе с другой табличкой.

Памяти жрёт в рабочем режиме при текущих нагрузках стабильно 12-15MB (один мастер, 4 рабочих).

Планы (или мечты?) на будущее:

• Пропатчить Lwt на предмет использования epoll() вместо select(). Чтобы в будущем не было мучительно больно обрабатывать 10000 одновременных соединений. Если, конечно, до этого дойдёт.
• Написать некую глюкалу, которая сильно поможет в поиске причин высоких нагрузок как на сайтах, так и в БД. Пока мне это видится чем-то вроде: oproxyreport “select response_time-start_time, uri from http where host=’ispsystem.com’ and uri begins with ‘/ru/’ save to ‘/tmp/load.log’”. Если будет реализовано — сразу можно будет написать интерфейсик в ISPmanager, чтобы клиенты могли сами это делать.

Я всё сказал.

p.s. Нет, не всё :) С переходом на Lwt, обнаружилась ещё одна приятная особенность: портабельность. Например, во FreeBSD 7.1. поломали те самые POSIX треды, из-за чего мне пришлось отказаться от альфа-тестирования прокси на ней в своё время. Lwt же ни от чего не зависит. Select() есть везде, а не блокирующие сокеты криво реализованы разве что в винде.