highload, 2/2

[fisher_geekly]

В этой части отчета о конференции highload-2007 я напишу о втором дне мероприятия, а в конце попробую подвести итоги. Отчёт о первом дне, если вы вдруг его не читали, здесь (Зайцев, Демкин, Таксиков, Аксенов, Орлов, Хайруллин, Крюков, Андрюнин) .

Comments

S3M2J

[anonymous]

По поводу S3M2J. В докладе сказано было, что памяти почти не кушают. А при join, которая аналогично join в sql, они первую таблицу пересортировывают по объединяемому столбцу.
По идее у них sort самая ресурсоемкая операция и достаточно часто применяется при join.
Интересно каким способом они сортируют? По частям?

Re: S3M2J

[raa]

да, согласен, было бы интересно узнать.

Re: S3M2J

[ospf_ripe]

Не знаю как сделано в S3M2J (возможно в докладе это было, я не помню), но я бы сделал так:
данные разбиваются на куски такого размера, чтобы каждый умещалася в RAM (с учетом всех накладных расходов).

Далее каждый кусок целиком читается с диска сортируется в RAM и на диск пишется отсортированный кусок.
После этого отсортированные куски мержатся попарно пока не получится один большой отсортированный массив.

Таким образом можно сортировать данные многократно превышаюшие размер RAM и на диск нагрузка "правильная" - последовательное чтение, последовательная запись.

Re: S3M2J

[quappa]

SORT поддерживает только сортировку данных, которые умещаются в памяти. Соответственно SPLIT+SORT+MERGE поддерживают сортировку любых данных. В этом фишка.

[raa]

>Вероятно, потоки ввода-вывода от серверного сокета
ну да, а по-другому ж и не получится. только ключевой фразы о передаче сокета я не помню - поэтому и говорю, что на системном уровне описания не хватало.

>>и ещё вот такой, ну вы знаете как оно всё работает
дык, башкой думать надо, умных людей спрашивать, в код смотреть, а не доки читать :)

[__si__]

>Не может же порождённый процесс слушать тот же самый порт.
может. все чилды апача слушают (accept) одинаковые порты которые для них открыл родитель. сам родитель никаких данных из сети не получает и не рабоатет с ними.

[fisher_geekly]

дааа первый так рабоает, точно. а второй в mpm-worker?

[proforg]

"Nginx очень быстро умеет SSI, но не умеет SSI с удаленного хоста"
индикативно - умеет, почему нет.

[fisher_geekly]

индикативно - это как?
если умеет, то наверное не умел, когда седи модуль писать. ну а потом там очень часто надо оборачивать одни и те же данные в в чуть разный HTML в зависимости от кучи параметров и фантазии маркетологов

[proforg]

индикативно - полноценно наверное не умеет, но ему же по большому счёту всё равно откуда брать данные, локально или с удаленного сервера, proxy_pass / fastcgi. но конечно как серьёзный шаблонный движок ssi не тянет, факт :) хотя нам хвататет (впрочем и задачи там минимальны)

[fisher_geekly]

да, спасибо, поправлю текст

[quappa]

POE не является обёрткой над libevent -- к сожалению. По умолчанию в POE используются циклы вокруг селектов, плагинчик libevent написан третьими лицами, сырой и не работает.

У Кудинова было много ошибок, не ожидал даже. Например про fork, в результате которого каждый процесс в Юниксе содержит копию процесса init.

[fisher_geekly]

эээ спасибо не знал, поправлю в тексте.
я вообще на перле лет пять не пишу но пару месячев назад ставил POE ради интереса и интерфейс мне очень понравился.
так что же - на нём не получится толком огранизовать kqueue/epoll event loops?

[fisher_geekly]

а насщет косяка с initом - дада, наверное, перепутал что первый процесс init дальше детки, и fork создаёт для детки копию адресного пространства папы - но про exec-то он не знает чтоли :)

Использование nginx как сервера-сборщика / Андрей Барано

[tterm]

>Использование nginx как сервера-сборщика / Андрей Баранов (Mail.RU

Re: Использование nginx как сервера-сборщика / Андрей Бара

[fisher_geekly]

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

>>К сожалению, похоже эту часть вообще никто не заметил
вы правы, я например про это вообще не помню :)

>>Мы хотели получить какой-либо отклик, чтобы было с чем идти к руководству пробивать open source
ну, обычно сначала выкладывают в open source, чтобы можно было потрогать руками, и уже получить отклики :)

>>Увы, open source не получилось - прямой запрет сверху
вы уж извините, но я от мыла ничего другого и не ожидал. жаль.

Re: Использование nginx как сервера-сборщика / Андрей Бара

[safaga]

>упрощение создания рапределенных архитектур - ну это спорный вопрос, всё-таки

Re: Использование nginx как сервера-сборщика / Андрей Бара

[tterm]

> насчет целесообразности. всё-таки мне кажется что основная задача с инженерной токи зрения - перенести нагрузку с бекендов на фронтенды

Не согласен, регулировать нагрузку и проще и гибче варьируя число фронтов/беков и совмещая/разнося их. Задача стояла уменьшить общую нагрузку (фронты+беки) и упростить код проекта.

> (упрощение создания рапределенных архитектур - ну это спорный вопрос, всё-таки).

На мой взгляд идеально подходит для веб-сервисов. Другое дело, что построение проекта как совокупности сервисов - спорный вопрос, тут мы ещё "будем поглядеть".