Сейчас развлекаюсь написанием универсального интерфейса к разным хранилищам (в первую очередь, это 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 (они есть только на уровне хранилища) и безумно типобезопасно.

Как известно, JavaScript — язык c динамической (для классов с утиной) типизацией, с очень плохо развитой системой типов. Стандартный интерпретатор даже в браузерах Mozilla с расширениями разработчика отлавливает минимум ошибок. Практически все эти ошибки — синтаксические. В результате, писать надёжный код на JavaScript предельно сложно. Положение усугубляет фактическая невозможность запуска программы без использования браузера, т.е. нет никакой песочницы для тестов.

В этой статье я попытаюсь описать некоторые технологии, которые помогут знакомому с Ocaml человеку существенно сократить время написания безопасного, стабильного и более-менее компактного JS-кода. Впрочем, описываемые техники есть и для некоторых других языков с развитой системой типов (например, Haskell).

Ocamljs: компилятор Ocaml ⇒ JavaScript

Скачать: http://code.google.com/p/ocamljs/

Всё просто: вы пишете client-side код вашего сайта на Ocaml, а с помощью этого компилятора получаете готовый для использования в браузере JavaScript. Для обеспечения работы, непосредственно к вашему скрипту дописывается около 40KB дополнительного кода. Например. Ни к чему не обязывающий код:

type tree =
	| Leaf of int
	| Node of tree list
 
let l : tree list = []
 
let _ =
	match l with
	| [] -> Dom.window#alert "empty list"
	| a :: [] -> ()
	| a :: b :: [] -> ()
	| _ -> Dom.window#alert "unexpected list"

Компилируем:

ocamljs -o test.js -I /usr/local/lib/ocaml/3.10.2/dom/ dom.cmjsa test.ml

Получаем вот такой код:

// .....
var oc$Dom$ = function () { var window$717 = window;
                            var document$718 = document;
                            return $(window$717, document$718); }();
var oc$1$ =
  function () {
    var l$63 = 0;
    if (l$63)
    {
      var match$71 = l$63[1];
      if (match$71)
      if (match$71[1]) (function () { var v$74 = oc$Dom$[0];
                                      return _m(v$74.alert, v$74, ["unexpected list"]); }()); else ;
      else ;
    }
    else (function () { var v$73 = oc$Dom$[0];
                        return _m(v$73.alert, v$73, ["empty list"]); }());
    return $(l$63);
  }();
var oc$Std_exit$ = (_(oc$Pervasives$[80], [0]), $());
return caml_named_value;
})();

JavaScript compressor

Как я уже сказал, код получается достаточно объёмным. Частично эту проблему решает gzip (при условии, что и сервер, и браузер имеют его поддержку). Однако, код можно существенно сократить за счёт оптимизации по размеру. Для этого есть ряд готовых online-утилит. Используемые техники:

• Удаление комментариев
• Удаление не несущих синтаксической нагрузки пробелов и переносов строк
• Назначение локальным переменным функций более коротких имён
• Вынесение длинных повторяющихся констант в переменную с коротким именем

Наилучшие результаты показывает Packer (http://dean.edwards.name/packer/), однако ocamljs компилирует не полностью корректный код — иногда забывает точки с запятой — поэтому Packer генерирует не работающий код. С учётом некорректности оригинального кода, наилучший результат показал Dojo ShrinkSafe (http://www.dojotoolkit.org/docs/shrinksafe). Рекомендую прогнать код через валидатор (http://jslint.com/), это в любом случае неплохая идея. Пример кода, получающегося с помощью Dojo ShrinkSafe:

// .....
var _213=function(){
var l$63=0;
if(l$63){
var _215=l$63[1];
if(_215){
if(_215[1]){
(function(){
var v$74=_210[0];
return _m(v$74.alert,v$74,["unexpected list"]);
}());
}else{
}
}else{
}
}else{
(function(){
var v$73=_210[0];
return _m(v$73.alert,v$73,["empty list"]);
}());
}
return $(l$63);
}();
var _218=(_(_106[80],[0]),$());
return _9d;
})();

Код получается практически не читаемым, зато размер сокращается в 2-4 раза.

Быстро сравнить различные компрессоры можно на сайте: http://compressorrater.thruhere.net/

O’Browser: виртуальная машина на JavaScript

Скачать: http://ocsigen.org/obrowser/

Ваш код будет скомпилирован в байт-код, закодированный в UUE. Для вызова кода, достаточно вызвать его в виртуальной машине:

<script src="vm.js" type="text/javascript"></script>
<script type="text/javascript">
  /* <![CDATA[ */
    window.onload = function () {
      exec_caml ("tutorial.exe.uue") ;
    }
  /* ]]> */
</script>

Байт-код получается достаточно объёмным, да и сжатию поддаётся только за счёт слоя gzip. Впрочем, код самой виртуальной машины вполне поддаётся обработке JavaScript компрессоров. Валидность кода получается даже выше, чем у ocamljs. Декомпиляция байт-кода в нормальный JavaScript становится нерешаемой проблемой :)

include Set.Make(struct type t = (int * int) * int let compare = compare end)
 
let (@) g f x = g (f x) and id x = x and sw f x y = f y x and zip x y = (x, y)
 
let fold9 f = let rec loop i = if i>8 then id else loop (i+1) @ f i in loop 0
 
let fold81 f = fold9 (fold9 @ (@) f @ zip)
 
let mark ((i,j),x as e) : t -> t =
  add e @ fold9 (fun k -> remove ((i/3*3 + k/3, j/3*3 + k mod 3), x) @
    remove ((i,j),k) @ remove ((i,k),x) @ remove ((k,j),x))
 
let search =
  let g p f s = fold (f @ sw mark s) (filter ((=) p @ fst) s) in
  fold81 g
 
let read () =
  let f p = Scanf.scanf "%d " (fun x -> if x>0 then mark (p,x-1) else id) in
  fold81 f (fold81 (fold9 @ ((@) add @ zip)) empty)
 
let print s () =
  let pr ((i,j),x) = Printf.printf "%d%c" (x+1) (if j=8 then '\n' else ' ') in
  iter pr s; print_newline ();;
 
search print (read ()) ()

Вы посмотрите эту красоту, это же [почти] совершенство! А если учесть, что 272 байта — это чтение задачи с STDIN и вывод результата, размер кода сокращается до менее чем 600 байт.

Впрочем, Perl традиционно отличился своей минималистической магической мешаниной:

use integer;@A=split//,<>;sub R{for$i(0..80){next if$A[$i];my%t=map{$_/9
==$i/9||$_%9==$i%9||$_/27==$i/27&&$_%9/3==$i%9/3?$A[$_]:0=>1}0..80;R($A[
$i]=$_)for grep{!$t{$_}}1..9;return$A[$i]=0}die@A}R

Ну и специалисты по PHP тоже выразились: http://www.weberdev.com/get_example-4243.html

1. Показать всякую текущую статистику (устаревшее show_workers, show_nodes и т.д.)
2. Управлять списками наблюдения.

Второй пункт интереснее. Немного предыстории. Часто бывает, что у клиентов на shared-хостинге случился перерасход ресурсов и они хотят знать, откуда эта нагрузка растёт. Резонное желание. Но беда в том, что ни я, “заведующий всем” © на хостинге, ни тем более техподдержка не может точно ответить на такой вопрос. Просто неоткуда брать данные. Чтобы разрешить эту проблему и были созданы списки наблюдения. Допустим, по MySQL-пользователю evlampiy случилось превышение нагрузки на MySQL. Пишем:

start save time, sent, query from mysql where user = “evlampiy” into file “/home/evlampiy/mysql_load.txt”

Всё, с этого момента прокся начнёт сохранять в указанный файлик все запросы к MySQL, пришедшие от пользователя evlampiy. Будет записано время выполнения запроса, количество посланных клиенту байт и сам запрос. Как только выяснили происхождение нагрузок, пишем:

stop save time, sent, query from mysql where user = “evlampiy” into file “/home/evlampiy/mysql_load.txt”

Запись прекратилась. Можно и понавороченней:

start save current_time, time/60, sent/1024/1024, host, uri from http where host = “john.5070.info” and ((uri = “/” and time < 0.5) or (uri = “/news/” and time > 0.01)) into file “/tmp/crazy_requests.txt”; stop save host from http into file “/tmp/all_http.txt”

Разумеется, можно посмотреть текущий список наблюдения:

show queries

На моей машине оверхед на один запрос со списком наблюдения длиной 5 получился 70 микросекунд, что примерно соответствует 2.3% на одно наблюдение при отдаче напрямую и 1.7% при проксировании.

Повторю, тестировалось именно проксирование. Известно, что при прямой отдаче и Apache, и Nginx использует ядрёный вызов sendfile(), который отдаёт содержимое файлика в сокет без лишних копирований. Это неинтересно. А вот проксирование — это совсем другое дело. В ядре пока что ещё нет прямых путей для копирования из сокета в сокет (есть полупрямой вариант splice() + pipe(), но как выяснилось он даже не на всех современных ядрах работает).

Итак…

На порту 8080 живёт Apache 2 ITK. У него в VirtualHost лежит bigfile размером ровно 20MB.

На порту 8081 живёт Nginx, который проксирует в Apache. Его конфиг:

worker_processes  16;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
worker_connections  1024;
}

http {
sendfile        on;
tcp_nodelay        on;
gzip  off;

server {
listen 12.34.56.78:8081;
server_name test1.com www.test1.com;
location / {
proxy_pass http://12.34.56.78:8080;
proxy_redirect http://test1.com:8080/ /;
proxy_set_header Host $host;
}
}
}

Результаты siege для Nginx:

debian2:~# siege -t30s -b -c 10 http://test1.com:8081/bigfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:                 372 hits
Availability:              100.00 %
Elapsed time:               29.66 secs
Data transferred:         6773.34 MB
Response time:                0.78 secs
Transaction rate:           12.54 trans/sec
Throughput:              228.37 MB/sec
Concurrency:                9.82
Successful transactions:         372
Failed transactions:               0
Longest transaction:            4.09
Shortest transaction:            0.07

228MB в секунду. Конкурентность 9.82. Доступность 100%. Самый медленный ответ: через 4 секунды.

Результаты oProxy (тоже 16 рабочих, чтобы было абсолютно честно):

debian2:~# siege -t30s -b -c 10 http://test1.com/bigfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:                 691 hits
Availability:              100.00 %
Elapsed time:               29.71 secs
Data transferred:        13820.00 MB
Response time:                0.38 secs
Transaction rate:           23.26 trans/sec
Throughput:              465.16 MB/sec
Concurrency:                8.94
Successful transactions:         691
Failed transactions:               0
Longest transaction:            9.18
Shortest transaction:            0.05

465MB в секунду (лучше более, чем в 2 раза). Конкурентность 9.18. Доступность 100%. Самый медленный ответ: через 9 секунд (хуже более, чем в 2 раза). Почувствуйте разницу ©

Мерим на маленьком файле. smallfile имеет размер 5 байт. Эмулируем атаку яростных 10 пользователей. Прочая конфигурация такая же. Результаты в Nginx:

debian2:~# siege -t30s -b -c 10 http://test1.com:8081/smallfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:               16952 hits
Availability:              100.00 %
Elapsed time:               30.47 secs
Data transferred:            0.08 MB
Response time:                0.02 secs
Transaction rate:          556.35 trans/sec
Throughput:                0.00 MB/sec
Concurrency:                9.97
Successful transactions:       16952
Failed transactions:               0
Longest transaction:            0.20
Shortest transaction:            0.00

Результаты в oProxy:

debian2:~# siege -t30s -b -c 10 http://test1.com/smallfile >/dev/null
** SIEGE 2.66
** Preparing 10 concurrent users for battle.
The server is now under siege…

Lifting the server siege…      done.
Transactions:                8718 hits
Availability:              100.00 %
Elapsed time:               29.57 secs
Data transferred:            0.04 MB
Response time:                0.03 secs
Transaction rate:          294.83 trans/sec
Throughput:                0.00 MB/sec
Concurrency:                9.27
Successful transactions:        8718
Failed transactions:               0
Longest transaction:            9.00
Shortest transaction:            0.00

А вот тут сливаем, почти в 2 раза. Аналогичная картина при увеличении конкурентных запросов. Но прокся при этом начинает показывать ещё более худшие результаты в Longext transaction. Буду над этим работать.

Update: нашёл в чём причина. В генах архитектуре. Завтра найду время, и перееду с socket passing на shared accept() и, возможно, epoll. Правда, при этом не совсем понятно, что делать с шедулингом нагрузки по рабочим. Рычаг теряю. Судя по логам, accept() на каждое соединение в среднем 3 миллисекунды тратит. Отсюда и цифра — 300 транзакций в секунду.

Из нового:

• Балансировка нагрузки. Универсальный модуль для любых видов соединений. Написано кривовато, но работает. Заведует всеми узлами мастер-процесс. Это несколько замедляет процесс (рабочим приходится больше общаться с мастером), зато позволяет контролировать балансировку в одном месте.
• Файлик: список сайтов. Пока каждый сайт можно только включить/выключить и прописать алиасы. Кроме того, на будущее есть поле “домашняя директория сайта”. В ближайшее время есть планы проксёй отдавать статичные файлы. Не понятно, что делать с .htaccess. Не хочется забивать, как это нынче делается в Nginx.
• Файлик: список узлов. Представляет из себя IP, мастер-пароль, список ролей.
• Роли. Что каждая машина умеет/должна делать. От этого зависит поведение балансировщика и некоторых скриптов. Предопределённые роли: worker_http (узел умеет обрабатывать HTTP-запросы), master (узел будет точкой входа, где висит балансировщик) и другие. Всё рассказывать раньше времени не буду :)
• Мониторинг. Наконец нашёл, где заюзать функционалы. На основе этого функционала (functional) написан мониторинг файлов. Как результат, прокся умеет автоматически подгружать изменённый список сайтов или узлов.
• Новый параметр у oproxyctl: show_nodes. Показывает известные узлы. Кто в дауне, сколько у каждого активных запросов, сколько всего обработано. Может оказаться полезным для выяснения проблемных узлов.
• Поддерживаем новый протокол, который я сам выдумал :) Служит для различных сервисных запросов к узлу. Поскольку позволяет совершать совершенно небезопасные вещи, авторизация происходит без передачи открытого пароля по сети.
• Новая утилита: clusterctl. Умеет 1) запустить на узлах с указанной ролью (или на всех, или на определённом IP) определённую команду и вернуть в STDOUT/STDERR что в итоге получилось 2) рассказывать список ролей текущей ноды 3) рассказывать список узлов, поддерживающих указанную роль. Служит для сервисных скриптов.
• Прокся умеет выставлять X-Forwarded-For, чтобы в конечном итоге в логи попадал нужный IP.
• Сервисные скрипты: apachectl (рестарт Апача на всех узлах), repquota и другие.
• Оптимизация, стабильность.

Допил коньяк. Опять потянуло на философию…

Написал версию 0.02 проекта с рабочим названием oProxy. В этой версии всё переписано с нуля + умеет считать трафик и прочую статистику :) На моём ноуте умеет обрабатывать ~2500 соединений в секунду. Соединения обрабатываются рабочими. При этом, 80% тормозов происходит на принятии соединения мастером, около 10% в мутексах для сбора статистики внутри рабочих, и около 10% уходит непосредственно на саму обработку (парсинг заголовков HTTP-запроса, обработка ошибок протокола и т.д.). Рабочие CPU почти не едят, в отличие от атакующего siege’а (~0.4% против 35%). То есть, запас роста есть. Памяти жрёт 1.7Mb на одного рабочего.

За пятничный вечер сделал дома больше, чем за всю рабочую неделю в офисе. Там становится невозможно работать. И причины не совсем ясны. Даже старое средство — наушники с музыкой — уже не помогает. Надо что-то придумывать. Послушать Шурика, и приходить на работу к 07:00?.. [не канает: ответственнен за некоторые машины, которые почему-то любят падать в период 23:00..03:00].

Полтора года тащился от Ocaml. Полтора года прищуренным глазом посматривал на вакансии. С вакансиями ситуация такая: за полтора года в России их было 2 штуки, обе уровня “мы тут пишем крутую фигню, но зарплата фиг знает когда будет”. За рубежом ситуация чуть лучше, но Ocaml-программистов хотят там всякие университеты и на соответствующие должности. И тут получил официальное одобрение разрабатывать заданный проект на чём сам пожелаю. Если так пойдёт и дальше — через полгодика я сам смогу торговать окамлевыми вакансиями! А ведь ещё не прошло и года с момента увольнения Стаса, который буквально позавчера должен уехать в СПб на вакансию Lisp-программиста.

Ошибка HTTP:Http_client.No_reply

Характерное написание исключения вызвало подозрения. И не зря:

$ grep No_reply netclient/http_client.mli
exception No_reply;;

Они бы ещё через маршала давали API к себе — цены бы им не было :)