Objective Caml - Среда, 20 апреля 2011

Objective Caml

ocaml@conference.jabber.ru

Среда, 20 апреля 2011< ^ >

Конфигурация комнаты

Участники комнаты

GMT+4
[00:41:11] arhibot вышел(а) из комнаты
[00:57:40] Kakadu вышел(а) из комнаты
[01:20:45] Typhon вышел(а) из комнаты: Replaced by new connection
[01:20:48] Typhon вошёл(а) в комнату
[01:40:05] ygrek вышел(а) из комнаты
[01:47:38] zert вышел(а) из комнаты
[02:07:31] <Typhon> gds, https://github.com/mibori/actorprocess -- видел? пилят "типизированный эрлангие", как я понял.
[02:40:53] Typhon вышел(а) из комнаты
[04:03:09] ftrvxmtrx вышел(а) из комнаты
[04:03:22] ftrvxmtrx вошёл(а) в комнату
[07:19:25] Typhon вошёл(а) в комнату
[07:44:38] iNode вышел(а) из комнаты
[08:04:00] Typhon вышел(а) из комнаты
[08:21:48] iNode вошёл(а) в комнату
[08:22:23] iNode вышел(а) из комнаты
[08:39:27] iNode вошёл(а) в комнату
[08:59:12] gds вошёл(а) в комнату
[09:00:00] Typhon вошёл(а) в комнату
[09:00:44] <gds> Typhon: видел другие посты мибори давности несколько лет, кое-что даже понравилось.  Буду это смотреть обязательно.
[10:47:04] gds вышел(а) из комнаты
[10:54:43] ftrvxmtrx вышел(а) из комнаты
[11:12:28] ygrek вошёл(а) в комнату
[11:49:32] ftrvxmtrx вошёл(а) в комнату
[11:58:50] komar вышел(а) из комнаты: Replaced by new connection
[11:58:52] komar вошёл(а) в комнату
[12:09:22] gds вошёл(а) в комнату
[12:13:44] ygrek вышел(а) из комнаты
[12:22:04] zert вошёл(а) в комнату
[13:04:36] komar вышел(а) из комнаты: Replaced by new connection
[13:04:37] komar вошёл(а) в комнату
[13:14:09] ermine вышел(а) из комнаты
[13:18:25] ermine вошёл(а) в комнату
[13:29:37] <f[x]> http://ncannasse.fr/projects/hss
[13:37:40] <Typhon> у оксигена, вроде бы, есть тоже свой енхансер для цсс?
[13:41:30] ermine только щас обнаружила, что даркс оксигена переделали в разные репы
[14:31:03] <gds> http://paste.in.ua/2183/ -- немного абыдна.  придётся дополнительную функцию рожать.
[14:42:27] ygrek вошёл(а) в комнату
[14:42:43] ygrek вышел(а) из комнаты
[15:32:54] <gds> не знаю, как нормально оформлять/форматировать топлевел-значения, когда у функции длинный тип.  http://paste.in.ua/2184/ -- лучшее, что приходит в голову.  если есть идеи получше -- расскажите.
[15:33:53] <f[x]> mli :)
[15:34:24] <f[x]> let f : type = fun x y ->
[15:36:06] ftrvxmtrx вышел(а) из комнаты
[15:36:42] ftrvxmtrx вошёл(а) в комнату
[15:37:40] <gds> мне и внутри ml хочется указывать типы, ибо они порой хитрые, а указание типа в топлевел-выражении -- первый шаг к ловле ошибок типизации.
[15:48:57] ftrvxmtrx вышел(а) из комнаты
[15:50:09] ftrvxmtrx вошёл(а) в комнату
[17:06:06] iNode вышел(а) из комнаты
[18:25:11] <gds> касаемо парвела.  нужно ли, если концептуально, делать такой комбинатор, который позволит запускать произвольное, без ограничений, количество lwt-потоков, обрабатывающих сообщения данным обработчиком?  С одной стороны, лишние ограничения не нужны, с другой же -- это явно непрактично, ибо будет тормозить, так как почти всегда проще заблокироваться и обработать то, что есть, не тратя памяти-процессора на потоки и их переключения (а то и экономя кеши всякие).
[18:26:25] <f[x]> > лишние ограничения не нужны
WTF
[18:27:14] <f[x]> в сервере правило номер один - ограничения для всех структур
[18:27:43] Kakadu вошёл(а) в комнату
[18:27:45] <f[x]> если есть неограниченный пул или очередь или кэш - это бага по определению
[18:27:53] Kakadu вышел(а) из комнаты
[18:28:32] <f[x]> которая просто ждёт своего звёздного часа
[18:28:44] Kakadu вошёл(а) в комнату
[18:35:35] <gds> > в сервере правило номер один
клиентское на этом деле тоже писать можно, потому и говорю.  А про сервера -- дико +1
[18:36:42] <f[x]> клиент ушедший в своп по головке не погладит :)
[18:38:05] <gds> это-то да.  В общем, спишем на секурвити, поставим опциональный аргумент и дефолт "42 потока".
[18:49:36] <gds> интересно, как в эрланге и вообще при параллельном программировании делают относительно-точное распараллеливание на хосты?  Просто раскидывать сообщения по разным хостам по round-robin принципу -- кривовато.  Форвардить (в отличие от "редиректить") через хост, следящий за тем, кто ответил, а кто ещё думает -- криво, рано или поздно упрёмся в трафик.  Work stealing такой, чтобы был относительно эффективен, слабо представляется.
Как вариант -- обязать отвечающего вдобавок к ответу клиенту ещё намекнуть серверу о чём-то типа "я свободен", чтобы следующее сообщение было к нему.  Но тоже не ок.
[18:51:10] <ftrvxmtrx> можно как в riak'e -- раздавать сообщения по hash'у от самого сообщения
[18:51:41] <ftrvxmtrx> ну это если совсем утрированно
[18:52:50] <ftrvxmtrx> gds: http://wiki.basho.com/An-Introduction-to-Riak.html#Clustering
[18:53:24] <gds> понял.  Идея хорошая.  Но страдает той же проблемой, что и round-robin -- если где-то затор, а кто-то отдыхает, то этих отдыхающих не загрузишь особо.
Хотя кое-где это очень применимо -- например, если с запросом связано что-то, что хорошо кешируется, и одинаковые запросы уйдут к одинаковым серверам.
[18:53:58] <ftrvxmtrx> угу
[18:56:56] <f[x]> какой-то дефолтный механизм это ок, но вообще логика приложения разруливать захочет
[18:56:59] <ftrvxmtrx> насчёт заторов, можно, опять же, хост может ответить "ой, я весь такой загруженный, не буду обрабатывать", а вопрошающий пойдёт по кольцу дальше, на следующий хост
[18:57:16] <f[x]> ага, и следуюший хост тоже ляжет :)
[18:57:24] <f[x]> и так по цепочке :)
[18:57:27] <ftrvxmtrx> ну почему ляжет? :)
[18:57:46] <f[x]> ну у него резко станет в два раза больше запросов
[18:59:27] <Typhon> это даже как-то называется специально
[18:59:37] <Typhon> половина стораджей на dht-ring этим страдают
[19:00:13] <gds> ftrvxmtrx: про riak прочитал.  Хорошо сделано, судя по доке.  Учту его.
[19:00:30] <f[x]> каскадное отключение это называется :)
[19:00:38] <Typhon> йеп!
[19:01:00] <Typhon> про динамический лоад бэлансинг читал около месяца назад  статью, но не помню ничего хорошего — водяная видимо статья была, и найти не могу
[19:08:00] <gds> насчёт "ляжет" -- мне кажется, что клиенты сначала подолбятся в один сервер, там скажут "приходите завтра", пойдут на следующий, там тоже заполнят всё, но в конце концов, если кластер способен обслуживать такой поток запросов, то они дойдут до нужного хоста.
Но какой-то механизм редиректов иметь ввиду буду, чтобы можно было в теории поставить стрелочника, периодически получающего статистику с рабов, и редиректящий на наименее загруженных рабов.  Опционально -- сделать так, чтобы на стрелочника редиректили сами рабы, в случаях, когда раб, на которого обратились раундробином / по хешу / случайно, имеет большую очередь входящих сообщений.
[19:12:31] <Typhon> ещё такая тема — есть хэш спейс, в традиционном хэш спейсе ноды разделяют на n кусков его (от 0 до m; от m до m1 и т.д.) — тогда если узел плохеет, запросы идут на соседа, в два раза больше, ага. поэтому ща делят хэш спейс, скажем, на n * 10 и и каждой ноде по кусочку из каждого участка. роутинг сложнее, надёжность — выше
[19:15:07] <gds> недопонял, как делят и почему на соседа не в два раза больше получается?
[19:17:18] <f[x]> кстати у gerd'а про это было
[19:18:12] <gds> "The Gerd Already Did It"?..
[19:19:30] <Typhon> кольцо делится на n частей, также, как и раньше, дальше каждая из этих частей делится на n маленьких кусочков — в итоге, каждая нода держит по малнькому кусочку из каждого кусочка, то есть зоны ответственности не "монолитны" — если падает один хост, его ответственность равномерно распределяется по остальным, как-то так
[19:19:39] <Typhon> на рисунке это лучше втыкается, чем я объясняю :-)
[19:19:52] <ftrvxmtrx> в riak'e так и сделано
[19:20:09] <ftrvxmtrx> physical node == N * virtual node
[19:20:51] <ftrvxmtrx> если я правильно понял Typhon'a
[19:20:58] <Typhon> а, ну да вот http://wiki.basho.com/attachments/riak-ring.png
[19:22:19] <gds> Typhon: ага, да, там именно это колечко нарисовано.  Это в случаях, когда дело касается данных (хранение, модификация).  Если же просто абстрактные считалки, то смысла не много.
[19:23:08] <gds> была идейка о том, что клиенту надо однократно посчитать хеш, и потом, зная, что N узлов есть, идти на узел "хеш mod N", а если один из узлов отдыхает, то временно выбросить его, сформировать список из живых N-1 узлов, и идти на узел "хеш mod (N-1)".
[19:24:11] <gds> наблюдаю какой-то бардак в своей голове по этому вопросу.  Буду утрясать.
[19:40:18] iNode вошёл(а) в комнату
[21:01:43] ftrvxmtrx вышел(а) из комнаты
[21:33:35] Typhon вышел(а) из комнаты
[21:49:18] komar вышел(а) из комнаты: Logged out
[21:49:22] komar вошёл(а) в комнату
[21:49:38] Kakadu вышел(а) из комнаты
[22:01:07] Kakadu вошёл(а) в комнату
[22:29:22] ftrvxmtrx вошёл(а) в комнату
[23:00:03] Typhon вошёл(а) в комнату