На сколько я понял, автор и сети свои не делал, только шлюзы свои ставил. Ай-ай-ай, нехорошо так делать! Видимо, поэтому провайдеры и ополчились: они инфраструктуру в городе делают, а кто-то нахаляву её использует и продаёт свой дешёвый интернет. Ещё и внешний канал провайдера выжирает при этом, кстати.
Вы тёплое с мягким не путайте, отказоустойчивость DNS — это несколько NS записей. А вы пишете про отказоустойчивость сервиса с помощью DNS, это совсем другое. Если нужно второе — то курите маны в сторону CARP и аналогов, + балансировщики нагрузки.
Правда, иногда возникают проблемы типа невозможности запихнуть больше 96 гигов памяти в одну машину или больше 24 дисков в одну полку. В определённый момент горизонтальное масштабирование начинает стоить сильно дешевле вертикального. И софт придётся писать отказоустойчивым, потому что диски, к примеру, всегда будут сыпаться, природа у них такая. А сеть всегда падает, и обязательно будут ретрансмиты. И ещё сервера внезапно выключаются. Но использовать надо серверное железо, аптайм от этого сильно вырастает, экономятся админские нервы.
И про эти проблемы знают те, кто хотя бы сотню серверов в одном приложении использует. Мегасистему, которая крутится на каком нибудь сановском сервере за пол ляма долларов, проще написать. Но сервера с xeon на ту же сумму могут оказаться намного производительнее.
Я в курсе разницы. Вы тоже уже поймите наконец, что я хотел сказать: что поток, что процесс одинаково будут спать на сисколлах, в отличие от асинк модели. А кто больше памяти будет жрать и как с ней работать — это соооовсем другой вопрос.
Вообще-то собственно стрелялка на С написана, phantom называется. В дебиан контроле он по зависимостям тянется. На перле и питоне обвязка для запуска только написана. Я всякие маркетинговые цифирки плохо помню, но 60к рпс своими глазами видел.
Даже если хранить в каждом процессе копию всего этого барахла (я про байткод), то получится аж целых пара мегабайт на процесс. При современных объёмах оперативки на серверах это смешные цифры. Если поднапрячься — то можно в шаред мемори положить, тогда совсем оверхеда не будет. И то, что не получается 1 раз проинициализировать всё нужное, проблема PHP, а не обычного многопроцессного приложения. А точнее, это даже не проблема, а защита от дурака.
Вообще-то, в современных популярных ОС потоки, которые заснули на блокирующем сисколе, не получают своего кванта времени до тех пор, пока сискол не отработает. Никаких пустых циклов ожидания в здравом уме никто не делает, исключением из этого является спинлок.
Что такое асинхронное выполнение кода, как в node.js? Это 1 поток, который получает уведомления от ядра, и свитчит контексты задач в userland. При этом внутри ядра для получения асинхронности дискового ввода-вывода AIO в Linux, к примеру, создаются потоки, которые блокируются, а потом посылают уведомление в userland. Минусы: сложно писать. Именно про это пишет автор поста.
Многопоточное или многопроцессное приложение использует большое количество потоков/процессов (существенно больше количества ядер, сотни, а то и тысячи потоков), каждое выполняет одну задачу, а шедулятся они уже ядром. Минусы: накладные расходы на контекст свитчинг.
В любом случае будут общие очереди, соединения и т.д., но это больше относится к обвязке, непосредственно получающей запросы клиентов и ставящей их в очередь на обработку.
Что вы там хотите шарить между потоками в типичном веб-приложении мне совершенно непонятно, т.к. в большинстве своём каждый запрос не зависит от остальных, это одно из условий горизонтального масштабирования. Или вы считаете, что синхронизация доступа к одному ресурсу из нескольких потоков бесплатна?
И да, я писал сервисы на тредпуле, которые держат десятки тысяч запросов в секунду. И да, я в курсе как применять epoll вместе с конечными автоматами для написания асинхронных приложений, писал хитрые модули для nginx и смотрел, как устроена node.js. И как бороться с лишними решедулингами в сетевых приложениях тоже, кстати, знаю.
Ещё раз: я не говорю о том, что между ними нету разницы в принципе. Я утверждаю, что если каким либо образом запустить php в нескольких потоках и при этом это будут независимые интерпретаторы, и если запустить его в нескольких процессах, то нет никакой разницы при сравнении с node.js, т.к. что мультитредность, что мультипроцессность — суть не меняется, ОС одинаково будет шедулить потоки, потоки точно так же будут спать в сисколах и т.д. Слово абстракция вам знакомо?
Который в статье написан. С точки зрения ядра Linux, к примеру, поток — это тоже процесс, просто он имеет общее адресное пространство и общие ядерные объекты типа дескрипторов с другими процессами, входящим в тот же process group. Если не пользоваться общей памятью, не использовать общие дескрипторы, то разницы между процессом и потоком с прикладной точки зрения нету.
Если у вас 90% времени IO — значит либо алгоритмы работы с данными диске надо оптимизировать, либо программа написана очень хорошо. А вот если в sys система дофига времени проводит, и количество контекст свитчей зашкаливает, вот тогда надо думать thread pool vs. async
И про эти проблемы знают те, кто хотя бы сотню серверов в одном приложении использует. Мегасистему, которая крутится на каком нибудь сановском сервере за пол ляма долларов, проще написать. Но сервера с xeon на ту же сумму могут оказаться намного производительнее.
Дарю :) Пока, правда, без красивых графичков.
Что такое асинхронное выполнение кода, как в node.js? Это 1 поток, который получает уведомления от ядра, и свитчит контексты задач в userland. При этом внутри ядра для получения асинхронности дискового ввода-вывода AIO в Linux, к примеру, создаются потоки, которые блокируются, а потом посылают уведомление в userland. Минусы: сложно писать. Именно про это пишет автор поста.
Многопоточное или многопроцессное приложение использует большое количество потоков/процессов (существенно больше количества ядер, сотни, а то и тысячи потоков), каждое выполняет одну задачу, а шедулятся они уже ядром. Минусы: накладные расходы на контекст свитчинг.
В любом случае будут общие очереди, соединения и т.д., но это больше относится к обвязке, непосредственно получающей запросы клиентов и ставящей их в очередь на обработку.
Что вы там хотите шарить между потоками в типичном веб-приложении мне совершенно непонятно, т.к. в большинстве своём каждый запрос не зависит от остальных, это одно из условий горизонтального масштабирования. Или вы считаете, что синхронизация доступа к одному ресурсу из нескольких потоков бесплатна?
И да, я писал сервисы на тредпуле, которые держат десятки тысяч запросов в секунду. И да, я в курсе как применять epoll вместе с конечными автоматами для написания асинхронных приложений, писал хитрые модули для nginx и смотрел, как устроена node.js. И как бороться с лишними решедулингами в сетевых приложениях тоже, кстати, знаю.