мне не нравится пхп тем, что он не статический :)

ну... сколько нынче максимум на сервер... около 200 ядер?

@miksir 8 ядер было у сервака, где снимали бенч.

поэтмоу я последнее время изучаю ява-фреймворки..

8 ядер? "не верю" ;)

@miksir 8 ядер.

максимум вореров 20... хотя и это много... 100к запросов на воркер... 0.01мс на запрос?

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

откуда взяться воркерам ещё)

в смысле?

в смысле кто их создаёт эти самые воркеры

а, ну я обычную схему fastcgi сервера рассматривал

не, нету её там

там что-то вроде реактовского tcp сервера, как я понимаю

откуда ты знаешь, что есть в Владислава?

читаю что он пишет)

а воркеры ну как откуда, треды ;)

или reuse

Треды + libEvent + Ev.h (системный)

+ тюнинг ядра.

в потоках stream_select

каждый селект при этом яростно смотрит события

но треды в линуксе почти что процессы... т.е. все-равно их много не наплодишь, на ядра оглядываться нужно

правильно. Потому у меня порядка 24-28 воркеров. и при выходе на пиковую пропускную способность процы не уходят далее 80-90%

т.е. не впадает во фризы

в потоках stream_select

Это как так? Звучит как костыль

каждый воркер отрабатывает пачку соединений?

это не костыль. Это имитация принципа потокового распределения в apache kafka

libevent работает противоположно stream_select

libevent работает противоположно stream_select

почему? так же работает, только лучше ;)

@chebotarevp они делают немного разные вещи. Я событиями сообщаю, что надо положить в тред. А селект уже разбирает что и кому обработать. Мне же надо как то дергать воркеры, в которые этот самый селект и происходит

Разница в направлении воркфлоу. при stream_select пользовательский код переьирает набор сокетов и каждый опрашивает, не случилось ли там события. А в libevent пользовательских код только регистрирует обработчики, и ядро само доставляет события на сокетах на них. Получается быстрее, и перебирать ничего не надо.

Разница в направлении воркфлоу. при stream_select пользовательский код переьирает набор сокетов и каждый опрашивает, не случилось ли там события. А в libevent пользовательских код только регистрирует обработчики, и ядро само доставляет события на сокетах на них. Получается быстрее, и перебирать ничего не надо.

неее... не опрашивает ;) может прекрасно слипать пока не будет события

Лан, расскрою секрет. Логика работы написана на 7.2. Но обвязка сервера написана на Zephir Lang и позволяет мне при обработке не пересобирать байт-код и производить максимум работы в оперативке. Плюс у нас база данных реплицируется в inMemoryTables.

ну и прямой доступ к memalloc

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

(malloc)

а в случае еполла ты один раз отправляешь пачку, и потом работаешь как со списком хранящимся в ядре

@miksir огромный оверхед в данном случае компенсируется тем, что я могу из зефира делать напрямую time_wait соединение =)

Лан, расскрою секрет. Логика работы написана на 7.2. Но обвязка сервера написана на Zephir Lang и позволяет мне при обработке не пересобирать байт-код и производить максимум работы в оперативке. Плюс у нас база данных реплицируется в inMemoryTables.

а потратить меньше времени на изучение если не ергланга, то хотя бы.. го... ну или банально с... и получить в общем результат лучше... не? ;)

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

Ты написал ровно то же что и я только другими словами :)

Ты написал ровно то же что и я только другими словами :)

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

@miksir Я так извращаюсь как раз потому, что упарываюсь по ерлангу. но мне оч нравится пыха.

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

Ну вызов же неблокирующий

Формирует множество дескрипторов, потом над этим множествовм вызываешь сисколл select(). Он по ним и бегает.

Ну вызов же неблокирующий

блокирующий ;) в неблокирующем смысла нет ;)

блокирующий ;) в неблокирующем смысла нет ;)

А вот и есть. В хайлоадкапе все чемпионы только так и спаслись

если у тебя будет неблокирующий селект, т.е. с таймаутом в 0 - то у тебя просто ЦПУ будет жраться в цикле

Да

Но при этом скорость ответа возрастает ))

гм... за счет чего?

Хотя, это как раз в epoll они выставляли 0 таймаут

тут, возможно, другая проблема - работа с файлами...

насколько я помню, даже то подобие aio, что есть в линукс - не может быть загнано в epoll

Mr. Nameless скажи мне кто нить года три назад, что пыха будет обрабатывать более 2 000 000 запросов в секунду, я бы не поверил..

и сейчас слабо верится

Забыл как эта опция называется, но в linux есть она специально, когда нулевой таймаут, жрется процессор но время ответа на сокет минимально.

есть, да... вопрос в том - с какими целями

как бы while(1) { epoll_wait(,,,-1); ... } ничем не хуже, а много лучше while(1) { epoll_wait(,,,0); ... }

но только если у нас нет операций, которые не попадают в еполл...

последняя сотня сообщений явно не про пхп :)

а это и не про пхп чат ;)

как бы while(1) { epoll_wait(,,,-1); ... } ничем не хуже, а много лучше while(1) { epoll_wait(,,,0); ... }

Лучше в мирное время, хуже в военное. Когда синус может достигать двух.

У заснувшего epoll тратится немного времени на разгон электронов в процессоре, когда приходит событие и будит его.

ERROR: S client not available

нолики растут ;)

под нагрузкой 0.018, без нагрузки 0.105? ничего не напутал? ;)

под нагрузкой 0.018, без нагрузки 0.105? ничего не напутал? ;)

XD под вечер мозг поплыл. Да, перепутал. Холостой: 0.018мс, Под нагрузкой 0.105мс. Все замеры без нагрузки на сеть (без сетевой задержки)

ну 0.105 мс при 30 воркерах - это никак не 2 ляма... где-то на порядок меньше

ну 0.105 мс при 30 воркерах - это никак не 2 ляма... где-то на порядок меньше

0.00010585784912109 сек

ну, это около 10к зарпосов в секунду

О_о

шо? 1/0.000105 = 9523 :)

тогда верю

Собери докер контейнер чтобы можно было скачать и ручками потыкать

в 2 ляма в секунду даже на 8 ядрах и вусмерть оттюнингованном ядре верится слабо.

Если это там не внедрение в нулевое кольцо и в TCP стек.

И попадание в когерентность кеша.

С утра тестили на чистой сборке ubuntu-server (без тюнячек), вот лог: Total data sent: 123640.4 MiB (129646334294 bytes) Total data received: 852.8 MiB (894251446 bytes) Bandwidth per channel: 43.513⇅ Mbps (5439.1 kBps) Aggregate bandwidth: 59.616↓, 8642.922↑ Mbps Packet rate estimate: 137211.4↓, 838519.4↑

значения собственно: {от} {до}

ааа... где тут коннекты?

в пике: 838519, на разогреве 137211

аа... причем тут пакеты?

потому, что тестировалось постоянное tcp соединение и мерились именно пакеты с валидным ответом.

бгг

мдя...

я же писал об этом выше..

ну... под "запросы в секунды" обычно нечто другое подразумевается, да...

Да какая разница? Норм тащит

ну у него и не пхп ;_

Правда если пошли извраты с тюнингом ядра и переписыванием на зефире, то может стоит переписать на go тогда

ну запросы бывают разные.. Кто то имеет ввиду http, в нашем вот случае tcp. Http запросы тоже замеряли: вот AB (обращаю внимание, что без тюнинга ос) Requests per second: 208415.11 [#/sec] (mean) Time per request: 0.960 [ms] (mean) Time per request: 0.005 [ms] (mean, across all concurrent requests)

не, tcp запросы в секунду и "число пакетов" - тоже немного разные штуки... ну в моем понимании

8 ядер, одна виртуалка. Правда на базе собственного облака на open stack.

вот если бы были udp запросы ;)

@miksir Ок, сори, возможно не правильно выразился. Просто для меня пакет == запрос т.к. с пакетом приходит.. запрос =))