Дано:

1. Есть кластер. В кластере живёт несколько узлов. В узле живёт несколько веб-серверов. В веб-сервере живёт несколько аккаунтов. В аккаунте живёт несколько сайтов.
2. Для каждого сайта известна текущая нагрузка. Соответственно, известна нагрузка для каждого из аккаунтов.
3. Известно количество сайтов в каждом из аккаунтов.
4. Для каждого аккаунта сказано, на скольких минимум узлах (не веб-серверах) он должен присутствовать. Пусть это будет μ.
5. Для каждого аккаунта известно, какие веб-серверы обрабатывают его в данный момент.

Задача состоит в том, чтобы перераспределить аккаунты по веб-серверам так, чтобы

1. Аккаунты с максимальной нагрузкой присутствовали на максимальном числе узлов. Ну и соразмерно все остальные.
2. Каждый аккаунт представлен минимум на μ узлах.
3. В пределах одного узла каждый аккаунт представлен лишь один раз.
4. Текущая нагрузка наиболее равномерно распределена между всеми узлами (или с каким-то коэффициентом — не суть).
5. Сайты максимально равномерно распределены между всеми веб-серверами, чтобы минимизировать объём памяти каждого из процессов веб-серверов.
6. Сделать это всё так, чтобы изменения коснулись по возможности минимального количества веб-серверов, чтобы затем минимум их пришлось заставить перечитывать конфиг.
7. Делать это каким-то хитрым алгоритмом т.к. простой перебор на потенциальные десятки тысяч сайтов может отожрать немало проца и памяти…

Понятно, что идеально соблюсти все условия не получится. Соответственно, надо либо расставить приоритеты условиям, либо ввести коэффициент максимальной допустимой погрешности решения. Решение вырастает весьма объёмным даже для простого перебора. Мне страшно представить о часе, когда надо будет искать более изящные решения.

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

Повторю, тестировалось именно проксирование. Известно, что при прямой отдаче и 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 транзакций в секунду.

time perl -MDBI -e ‘$dsn = “DBI:mysql:database=mysql;host=127.0.0.1;port=5501″;$dbh = DBI->connect($dsn, “user”, “анунеподглядывай”);for(0..100000){$s = $dbh->selectall_arrayref(”select repeat(100000000000000000, 10)”);}’

Во время выполнения, oProxy ел около 31% CPU, MySQL 25% Perl 50%. Ещё есть куда расти.

Как этого добился:

1. Прежде всего выяснил, что очень большие задержки происходят при чтении из сокета. Исследование показало, что я всегда перед этим делаю двойную запись в сокет (отдельно заголовок пакета, и отдельно содержимое), как следствие включается дополнительное ожидание данных ядром от программы, а удалённая сторона некоторое время ничего не получает и не отвечает. Слил всё в один write, ситуация улучилась раза в 4. Но всё равно плохо.

2.  Далее обнаружил, что иногда из-за особенностей протокола MySQL, данные опять отправляются несколькими исходящими пакетами подряд (пакет-заголовок датасета, описание поля, описание поля …, пакет конец описаний, данные, данные, …, конец данных). Всё-таки поставил Ocaml 3.11 и включил для сокета опцию Unix.TCP_NODELAY. Стало ещё лучше, но всё равно не то.

2.5. (в этом месте выясняется, что 80% времени программа проводит в обработке той кучи дебага, что есть в коде. Логи были стремительно сокращены :)

3.  Часовое разглядывание вывода tcpdump’а привело к интересному результату: оказывается, последовательности своих пакетов, MySQL склеивает в одно целое и отправляет одним TCP пакетом. Только сейчас в описании протокола вижу ключевую фразу: The description is of logical packets. Не стал мудрствовать лукаво, тоже начал склеивать последовательности, сократив таким образом количество write’ов в сокет до возможного минимума. С этим пунктом, TCP_NODELAY начинает иметь смысл только при отправке больших массивов данных, поэтому временно упразднён и всё возвращено обратно на Ocaml 3.10.2.

Написал версию 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-программиста.

“Ocaml”, судя по всему, тестировался в скомпилированном в нативный код виде. В режиме интерпретатора варианта тестирования нет. Кстати, похожие языки – Ocaml и Haskell – оказались близкими и по производительности: