tag:blogger.com,1999:blog-5411819754291292105.post8140333921019433438..comments2023-04-10T00:28:48.006-07:00Comments on archimag: Асинхронный вебarchimaghttp://www.blogger.com/profile/07997791035847047137noreply@blogger.comBlogger29125tag:blogger.com,1999:blog-5411819754291292105.post-915401445605041872010-05-03T02:12:59.347-07:002010-05-03T02:12:59.347-07:00А, так под "будет много потоков, но не все он...А, так под "будет много потоков, но не все они будут активны" имеется в виду, что тред-рабочий выполнивший epoll_wait отключается до появления готового к диалогу клиента. Т.е. эта штука будет автоматически происходить при использовании event-base. Тогда понятно.quasimotohttps://www.blogger.com/profile/00314164162692094788noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-49993209822239026672010-05-02T00:28:01.097-07:002010-05-02T00:28:01.097-07:00@quasimoto
Скорей в виде форка. Технически я ещё ...@quasimoto <br />Скорей в виде форка. Технически я ещё не знаю что потребуется. Но, скажем так: нельзя добиться высокой масштабируемости в сотню строк код ;)<br /><br />> Имеются в виду aio_read/aio_write?<br /><br />Нет. Имеет в виду на основе epoll.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-35020249110626260702010-05-01T14:59:32.876-07:002010-05-01T14:59:32.876-07:00Как я понял это всё уместиться во что-то вроде пат...Как я понял это всё уместиться во что-то вроде патча :) (?)<br /><br />А именно - сдвинуть часть работы из process-connection (который работает в отдельном, вновь созданном, треде) в handle-incoming-connection, который работает в треде ацептора. Так?<br /><br />И ещё вопрос про:<br /><br />>> сервер асинхронным образом полностью считывает запрос<br /><br />и<br /><br />>> сервер отправляет ответ клиенту асинхронным образом<br /><br />Как асинхронным образом? Имеются в виду aio_read/aio_write?quasimotohttps://www.blogger.com/profile/00314164162692094788noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-84253088134124014122010-04-24T22:12:37.846-07:002010-04-24T22:12:37.846-07:00@Mike
Конечно не снизит, но может улучшить ситуаци...@Mike<br />Конечно не снизит, но может улучшить ситуацию, когда есть большое колличество потоков и лишь несколько из них реально активны.<br /><br />Green Threads нет и не будем (в Common Lisp). Так что нечего о них вообще рассуждать. Я исхожу из этого.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-62791431323202516652010-04-24T16:36:12.605-07:002010-04-24T16:36:12.605-07:00> Не, я про то, что при необходимости лучше пла...> Не, я про то, что при необходимости лучше планировщик пилить.<br /><br /><br />это не снизит стоимости создания, удаления треда. разве что скорость переключения, но это не самый критичный момент + надо собственно будет делать переключение, тогда как в green threads скедулер сидит внутри процесса.<br /><br />желательнее иметь возможность быстрого создания микротреда без всего кернелового оверхеда, что собственно выше про ерланг и написали.<br /><br />// всё imhoMikehttps://www.blogger.com/profile/11026306789386184204noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-34876929011143107242010-04-24T16:34:50.038-07:002010-04-24T16:34:50.038-07:00Этот комментарий был удален автором.Mikehttps://www.blogger.com/profile/11026306789386184204noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-45334833116778701902010-04-24T06:16:55.413-07:002010-04-24T06:16:55.413-07:00> Зелёные треды в ядро запихать не получится.
...> Зелёные треды в ядро запихать не получится. <br /><br />Не, я про то, что при необходимости лучше планировщик пилить.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-76214220712264980612010-04-24T05:20:55.701-07:002010-04-24T05:20:55.701-07:00Сообщество - это как раз мы ;) После однократного ...Сообщество - это как раз мы ;) После однократного портирования код будет работать вечно, т.к. затрагиваемые места меняются не часто (если меняются).<br /><br />Зелёные треды в ядро запихать не получится. Они туда идейно не воткнутся.Anonymoushttps://www.blogger.com/profile/02380968018415209802noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-38060708031893568682010-04-24T03:47:03.572-07:002010-04-24T03:47:03.572-07:00> из CMUCL в SBCL можно перетащить
> code/m...> из CMUCL в SBCL можно перетащить <br />> code/multi-proc.lisp<br /><br />Это большой риск. По-факту, большой потребности в green threads со стороны сообщества SBCL нет, а значит судьба этого кода (если его таки перенести)будем сомнительна - ведь любой код надо сопровождать в течении длительного проекта, а неиспользуемый код создаёт трудности для развития. <br /><br />Green threads это может и удобно, но это ведь не может быть единственным решением? Если что и патчить на таком уровне, то кажется проще и больше смысла патчить ядро Linux ;)archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-494444531461443822010-04-24T03:15:10.014-07:002010-04-24T03:15:10.014-07:00> В общем: создадим вокруг лучшего языка лучшег...> В общем: создадим вокруг лучшего языка лучшего инфраструктуру ;)<br /><br />Если поднапрячься, то из CMUCL в SBCL можно перетащить code/multi-proc.lisp. Разницы между ними не слишком много, нужно лишь разобраться, как в них работа со стеками и lexenv'ом сделана.Anonymoushttps://www.blogger.com/profile/02380968018415209802noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-22059832285150492502010-04-23T05:54:58.721-07:002010-04-23T05:54:58.721-07:00@grundik
Нет, ни о каком mass shared hosting речь,...@grundik<br />Нет, ни о каком mass shared hosting речь, конечно, не идёт. Никакой PHP здесь тоже не фигурирует. Речь идёт о позиционировании набора инструментов, включающего в себя Hunchentoot, как оптимального для построения веб-приложений (не просто веб-сайтов), которые, в том числе, должны работать и под высокой нагрузкой. <br /><br />Если мы не говорим о highload, то сразу обозначаем предел применимости. Кто, например, выберет такой инструмент для начала стартапа, если с самого начала понятно, что он не будет справляться с высокой нагрузкой? Ведь стартап мечтает о высокой нагрузке ))<br /><br />> но как-то не могу представить себе смысл.<br /><br />Смысл в том, что бы иметь уверенность, что Common Lisp может использоваться для решения любых задач в области веб-разработки без страха уткнуться в какие-либо принципиальные ограничения. <br /><br />В общем: создадим вокруг лучшего языка лучшего инфраструктуру ;)archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-83548765388819663902010-04-23T05:23:47.506-07:002010-04-23T05:23:47.506-07:00Про статистику и "известную информацию" ...Про статистику и "известную информацию" - я просто занимаюсь этой темой немного (я работаю в конторе, которая разрабатывает некоторый софт для индустрии хостинга), и по моим данным (анализ логов крупных хостеров, моделирование нагрузки, профилирование) недостатки апача очень сильно зависят от характера загрузки, количества сайтов и прочих параметрах.<br /><br />То есть если интересно позиционировать hoonchentut как замену apache для mass shared hosting - тогда да, замечания справедливы. Однако же mass shared hosting - это PHP. Хорош ли hoonchentut в связке с PHP? Может ли он быть производительнее, чем nginx + apache + mod_php (в hoonchentut-е ведь будет как максимум fastcgi, верно)? Я думаю нет.<br /><br />Если же говорить не о mass shared hosting (а о чём тогда), то у апача проблемы с производительностью не сильно критичны (ну, если мы не говорим о highload), плюс есть такие довольно неплохие решения как lighty.<br /><br />Я не то чтобы критикую, дело ваше, но как-то не могу представить себе смысл.grundikhttps://www.blogger.com/profile/08116607657034473453noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-5119011518615936172010-04-22T23:58:28.376-07:002010-04-22T23:58:28.376-07:00@lionet
О, это я понимаю, но не имею возможности с...@lionet<br />О, это я понимаю, но не имею возможности создавать микротреды в Common Lisp и исхожу именно из этого факта. Т.е. поскольку нет возможности полагаться на специальные возможности, положенные в основу языка, то надо делать более "интелектуальное" решение. <br /><br />За всё надо платить, за Erlang - тоже, например тем, что это не CL, но такую цену я не согласен ;)archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-46387731999508185452010-04-22T23:51:43.642-07:002010-04-22T23:51:43.642-07:00@archimag
Ключевое отличие («противоречие») в том...@archimag<br /><br />Ключевое отличие («противоречие») в том, что в системах с возможностью плодить один микротред на коннект (например, в C/ST или Erlang), из трёх фаз "принимаем клиента или делаем отлуп | вымачиваем коннект в очереди ожидания | порождаем тред на коннект" вторая фаза лишняя.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-10131345200928313322010-04-22T02:01:35.595-07:002010-04-22T02:01:35.595-07:00@lionet
Собственно, не увидел противоречия, я каже...@lionet<br />Собственно, не увидел противоречия, я кажется это и имею в виду, когда говорю об асинхронной обработке HTTP, что запрос от клиента вычитывается, но если система уже загружена, то реальная его обработка начинается только когда в системе освобождаются необходимые ресурсы. Эту задачу и должен решать "балансировщик нагрузки". Ну а если необработанных запросов накопилось слишком много, то надо резетить новые соединения - это кажется довольно очевидным.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-39000493622335556842010-04-22T01:52:44.077-07:002010-04-22T01:52:44.077-07:00По поводу StateThreads и потоков: никогда не знаеш...По поводу StateThreads и потоков: никогда не знаешь, когда именно нужно порождать потоки. Никогда не будет такого понятия, как "вот сейчас не могу обработать нового клиента, так что подождём" — это сразу вызовет thrashing из-за забивания очередей в ядре. Единственная схема, которая работает и требует минимальной настройки — это режим «или порождаем тред (green thread, state thread (ST), process (Erlang)) на соединение, ИЛИ выгребаем соединение и тут же его закрываем, с флагом "отошли RST отправителю'». Никаких "подождём до более удобного случая" делать нельзя — его может не наступить.<br /><br />Это если есть возможность порождать дешёвые треды, до тысяч и десятков тысяч на экземпляр программы.<br /><br />Естественно, если у нас есть ограничение не на сотню (сотни) тредов в системе, а на всего лишь 2-4-8 (по количеству процессоров), или там, например, 32, совет выше может не совсем подходить. В таком случае эффективнее будет выгрести сокет и положить его в отстойник до тех пор, пока освободится кусок машинерии. Если отстойник забит больше чем на N слотов (100? 1000?), то надо принимать и тут же резетить соединения.<br /><br />Поверьте написавшему несколько высокоскоростных веб серверов для промышленных применений (Netli/Akamai, Cisco ASA).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-26083596383106121182010-04-22T00:42:59.112-07:002010-04-22T00:42:59.112-07:00@grudnik
Ссылку конкретную не скажу, ибо просто не...@grudnik<br />Ссылку конкретную не скажу, ибо просто не фиксирую перерабатываемые источники информации, а просто сохраняю выжимку у себя в голове. Но мне казалось, что это достаточно широко известная информация, которая регулярно обсуждается в разных источниках. <br /><br />> что именно не устраивает сейчас<br /><br />Используемая в hunchentoot модель поток на соединение.<br /><br />> Ну в смысле какой сайт, хостящийся на <br />> hoonchentut-е, имеет такую нагрузку, <br />> с которой hoonchentut не справляется?<br /><br />Вот уж не думаю :) Но, во-первых, если бы Hunchentoot демонстрировал чудеса производительности для экстремальных случаев и при этом предоставлял бы весьма удобную среду для разработки, то это был бы отличный маркетинговый ход для популяризации использования CL в веб. Во-вторых, есть некоторый набор технологий, на которые я ориентируюсь в перспективе на несколько ближайших лет и мне надо знать их предел. И если я вижу принципиальные ограничения, то это вызывает у меня серьёзный "неконфорт", я просто не могу полагаться на решения, которые в какой-то момент могу перестать соответствовать требованиям.<br /><br />> при ответе на мой комментарий я как-нибудь<br />> смогу об этом узнать<br /><br />Например, можно использовать atom-ленту: http://archimag-dev.blogspot.com/feeds/8140333921019433438/comments/default<br /><br />Если зарегистрироваться на blogpost и писать от этой учётки, то будут приходить письма.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-82373296134257158122010-04-21T23:36:16.923-07:002010-04-21T23:36:16.923-07:00А можно ссылочки на те источники, на основании кот...А можно ссылочки на те источники, на основании которых утверждается про проблемы Апача и причины использования nginx? Если это ваше собственное профилирование, то пост про это был бы очень интересным.<br /><br />Также не совсем понятно (сорри, читаю не всё, что вы пишете, возможно, раньше было объяснение) что именно не устраивает сейчас. Ну в смысле какой сайт, хостящийся на hoonchentut-е, имеет такую нагрузку, с которой hoonchentut не справляется?<br /><br />PS: при ответе на мой комментарий я как-нибудь смогу об этом узнать, или надо будет мониторить комменты через бразуер?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-85425797944616862552010-04-21T07:39:32.462-07:002010-04-21T07:39:32.462-07:00Можно и пул воркер-тредов сделать. Только удобной ...Можно и пул воркер-тредов сделать. Только удобной работы с контекстом уже не будет.Anonymoushttps://www.blogger.com/profile/02380968018415209802noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-84008550106544088902010-04-21T07:29:46.853-07:002010-04-21T07:29:46.853-07:00@13-49
Ну, собственно, я смотрел на них не долго и...@13-49<br />Ну, собственно, я смотрел на них не долго и решил что оно не надо, даже в том виде, как сделано в Erlang. Моя мысль заключается в интеллектуальном управлении колличеством потоков, в конце концов, в контексте веб-сервера мы не обязаны немедленно порождать новый поток для каждого запроса, а можем приняв запрос от клиента спокойно выждать подходящий момент для его обработки.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-45563615711749424272010-04-21T07:14:09.232-07:002010-04-21T07:14:09.232-07:00Green threads должны быть очень хорошо интегрирова...Green threads должны быть очень хорошо интегрированы в систему, чтобы ими было удобно пользоваться. В Erlang'е, судя по всему, это сделано очень хорошо.Anonymoushttps://www.blogger.com/profile/02380968018415209802noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-54807597569967459002010-04-21T07:05:05.890-07:002010-04-21T07:05:05.890-07:00@lg
Только я, скажем так, не фанат ecl :) Моя осно...@lg<br />Только я, скажем так, не фанат ecl :) Моя основная реализация - SBCL. Потом, сейчас есть iolib, которая поддерживает event loop через epoll и т.п. И, кстати, там для буферов используются куски foreign-памяти, там что они работают достаточно неплохо. Но если говорить об реализации асинхронного HTTP для Hunchentoot, то я пока держу в уме просто использовать пул foreign-страниц, который не будет учитываться gc, а пользовательский интерфейс надо делать как потоки, на базе gray streams - что бы старый код для hunchentoot ничего не заметил.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-38874331946367082212010-04-21T06:36:17.367-07:002010-04-21T06:36:17.367-07:00отлично! для данной задачи мало реализовать связк...отлично! для данной задачи мало реализовать связку event loop и корутин, необходима ещё качественная (быстрая и без копирования) организация памяти и буферов. можно взять ecl за базу, вкрутить в него связку libev + libocoroutine добить какой-нибудь клёвой gc-awared реализацией chain буферов, в этой связке накатать линейные неблокирующие аналоги read/write/connect/accept/etc - и получить ништяковый каркас. <br /><br />Потребность в таком каркасе уже пару лет есть у sxemacs для реализации non-preemptive multitasking ..lghttps://www.blogger.com/profile/08003803875490377611noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-29182491285916295832010-04-21T06:30:42.847-07:002010-04-21T06:30:42.847-07:00@quasimoto
Как раз с утра внимательно разглядывал...@quasimoto <br />Как раз с утра внимательно разглядывал ;) Но это не совсем. Я считаю, что сам факт использования асинхронных операций более эффективен, чем блокирующий ввод/вывод. Поэтому, при необходимости выполнить асинхронный вызов поток должен остановиться, где-то в другом месте производиться обработка вызова в асинхронном виде, а после его завершения результат возвращается в остановленный поток и он возобновляет свою работу. Взаимодействие с MOM - один из вариантов, но далеко не единственный.archimaghttps://www.blogger.com/profile/07997791035847047137noreply@blogger.comtag:blogger.com,1999:blog-5411819754291292105.post-65950479106485973522010-04-21T06:19:23.175-07:002010-04-21T06:19:23.175-07:00>> Каркас для выполнения асинхронных операци...>> Каркас для выполнения асинхронных операций<br />>> в рамках синхронного потока выполнения.<br /><br />Можно посмотреть на ZeroMQ (и соответствующий биндинг cl-zmq), как и AMPQ он позволяет обеспечивать асинхронный интерфейс к синхронному, например ДБ.quasimotohttps://www.blogger.com/profile/00314164162692094788noreply@blogger.com