Да, думаю нужен close в дополнение/вместо shutdown

так он есть

просто как писали выше - сокет не закрывается еще 60 сек

На стороне эликсира

ровно через 60 сек скрипт продолжает выполнение

сейчас добавлю

Попробуй без shutdown просто close.

оно так было изначально, разницы нет

Ты сейчас попробовал?

я думаю php не рвёт

netstat ом посмотри TIME_WAIT

и какой пид их держит

да откуда прозрачность, блин берется((((

5 сек

http://php.net/manual/ru/function.socket-close.php

там в доке снизу показаны опции

попробуй с ними

да, дело пишут, сейчас протестирую

В общем сдаётся мне time_wait будет или на сервере или на клиенте. Без опций.

значит так.. получается, что можно увеличить количество одновременно открытых tcp соединений до 60к штук. Т.к. время ожидания закрытия соединений 60 сек - у нас пропускная спосоюность 1к в сек

уже не плохо)

теперь можно игрануть с временем ожидания

тем самым увеличить до 2к и более в сек

число портов тоже можно увеличить

хотя я наверное гоню

в пакетах всё равно 2 байта под них же

cat /proc/sys/fs/file-max

Хотя исходящих портов да, ограниченное количество

Есть идея, до работы дойду - попробую. Выложи пожалуйста исходники.

ещё у бенчмарке включи ELIXIR_ERL_OPTIONS="+K true"

у меня ab на ноуте с ковбоем выдаёт 45000 rps

Я ПОБЕДИЛ!!!!!!!!

$linger = array ('l_linger' => 0, 'l_onoff' => 1); socket_set_option($sock, SOL_SOCKET, SO_LINGER, $linger);

Бля...

Вот между стрелками код

таким образом он полностью закрывает соединение

скотина этот пыхыпэ, сволочь, гад, недруг..

тестил бы ab или wrk

там эти проблемы давно решили

Да это не только в PHP. Так TCP работает.

или tsung ещё есть

http://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections

вот тут с тюнингом

да я читал эту штуку, уже некоторые вещи заюзал

Сколько в результате получилось?

100к за 7 сек

1 миллион за 30 сек без отправки назад

а проц какой?

для ranch сколько слушающих процессов?

что-то мало ((

def start_link(port) do {:ok, _} = :ranch.start_listener( :teaser_view, 10000, :ranch_tcp, [port: port, max_connections: :infinity, backlog: 100000], TeaserView.Handler, [] ) end

i7-6700

https://ark.intel.com/ru/products/88196/Intel-Core-i7-6700-Processor-8M-Cache-up-to-4_00-GHz

вот этот

10тыс много, у меня с 100 - 45К rps выдаёт и проц уменя Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz

а кинь серверную часть

я у себя погоняю

что-то мало ((

так клиент в один поток. Я думаю там узкое место.

ааа

ну да, согласен

Получается latency 100 uS. По-моему очень даже неплохо.

Да, клиент создает, пишет и закрывает соединение. Теперь надо многопоточно проверить)

штук так в 500

ERROR: S client not available

Используй wrk если хочешь сервер проверить.

ок, попробую

погоди, но он http тестирует

а мне то tcp надо

тебе вообще amqp надо тестировать

насколько я помню

tsung умеет

не, это уже другая тема

я тогда писал на udp, но потери пакетов были приличные

вот решил на tcp перейти

хочу сделать сборщик данных

Есть большой поток обращений в php скрипты, там пока все справляется хорошо. Но надо писать лог в базу из них. Чтобы не нагружать систему кучей запросов - лучше сделать сбор в одном месте и раз в 10 сек записывать все данные. Это можно сделать и через редис, но есть косяк в предварительной обработке этих данных. Эликсир декодирует json строки и делает все необходимые изменения с офигительной скоростью через flow и может в отдельном процессе вставлять данные в базу.

может тогда iperf/iperf3?

Есть большой поток обращений в php скрипты, там пока все справляется хорошо. Но надо писать лог в базу из них. Чтобы не нагружать систему кучей запросов - лучше сделать сбор в одном месте и раз в 10 сек записывать все данные. Это можно сделать и через редис, но есть косяк в предварительной обработке этих данных. Эликсир декодирует json строки и делает все необходимые изменения с офигительной скоростью через flow и может в отдельном процессе вставлять данные в базу.

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

может готовый https://www.elastic.co/products/logstash взять?

ну и весь стек притянуть

можно и анлизировать будет быстро

нужна запись в clickhouse

Для аналитики замечательно подходит

и у него прикол, что данные лучше вставлять пачками по >1000 элементов

следовательно такое решение наиболее правильное. Мы собираем кучу данных, через flow подготавливаем и обрабатываем. Потом всей толпой засовываем в clickhouse

Для аналитики замечательно подходит

С Алексеем Миловидовым общался на днях. Он говорит, что под Erlang нет коннектора.

а где можно посмотреть какие графики выдаёт?

Самим писать несложно, но этож писать надо

или там отдельно визуализация?

http интерфейс ведь есть

то http, а то api

визуализацию самому писать

для CouchDB тоже всё по http, однако апи гораздо удобнее

CouchDB API для Clojure кстати весьма крутое.

визуализацию самому писать

а в чём плюс тогда?

у вас как у яндекса/гугла миллиарды сообщений в месяц проходят?