По непонятным причинам из десяти тысяч запросов 1-2 зависали надолго )

А в это время другие запросы отрабатывали?

Вдруг это просто GC начинал свое долгое дело

Percentage of the requests served within a certain time (ms) 50% 0 66% 0 75% 0 80% 0 90% 0 95% 1 98% 1 99% 1 100% 31279 (longest request)

Ну профиль нагрузки былпочти ровно такой. Почти все запросы отрабатывают меньше чем за 1мс, а 1-2 запроса за 1-2 секунды. Может тут в GC дело, да, но вот же пример на голом libevent и все равно то же самое.

Если бы сработал GC то я думаю что в очереди сразу накопилось бы несколько десятков запросов от ab и все они обрабатывались бы долго.

Может, разные версии libev? У меня libev-dev 1:4.22-1

И у меня такая.

А в это время другие запросы отрабатывали?

Да, работают

Дело в том, что зависает какой-то запрос(ы), а новые обрабатываются!

Принемает и быстро отвечает

А для какого-то зависшего он просто ничего не делает

Это точно не GC

Там практически нет его работы

Я даже вырубал его

Это может быть еще косяк ab кстати

Процесс спустя 30 сек раздувался до 200 метров

Попробуй померять с помощью wrk

Это может быть еще косяк ab кстати

Я тоже в эту сторону думаю

НО!

Я делаю тот же самый тест на nginx и у него все работает!

не виснет

Еще прикол такой, что иногда виснит так, что данные в сокете есть, а он его дергает CB. Я просто в таймере вычитывал еще из зависших сокетов и там данные были

Если бы сработал GC то я думаю что в очереди сразу накопилось бы несколько десятков запросов от ab и все они обрабатывались бы долго.

Да, GC бы отразился на большом числе запросов. Значит, ищите баг в эвентлупе или ограничениях процесса на число сокетов и т.п.

Вот яркий пример:

ab -c 500 -n 100000 127.0.0.1:8080/ This is ApacheBench, Version 2.3 <$Revision: 1706008 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking 127.0.0.1 (be patient) Completed 10000 requests Completed 20000 requests Completed 30000 requests Completed 40000 requests Completed 50000 requests Completed 60000 requests Completed 70000 requests Completed 80000 requests Completed 90000 requests ^C Server Software: Server Hostname: 127.0.0.1 Server Port: 8080 Document Path: / Document Length: 10 bytes Concurrency Level: 500 Time taken for tests: 17.109 seconds Complete requests: 99852 Failed requests: 0 Total transferred: 8487420 bytes HTML transferred: 998520 bytes Requests per second: 5836.11 [#/sec] (mean) Time per request: 85.674 [ms] (mean) Time per request: 0.171 [ms] (mean, across all concurrent requests) Transfer rate: 484.44 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 12 81.8 2 3006 Processing: 0 12 171.3 3 12834 Waiting: 0 10 171.3 2 12834 Total: 0 24 195.4 5 12839 Percentage of the requests served within a certain time (ms) 50% 5 66% 20 75% 25 80% 25 90% 27 95% 28 98% 32 99% 42 100% 12839 (longest request)

Тест длился 17.109 seconds

100000 - 99852 = 148 реквестов щависло

Самый первый завис спустя 17 - 13 ~ 4 секунды

Но после этого он обработал еще десятки тысячь запросов

Это странно

Такое ощущение что планировщик какой-то кривой, забывает про некоторые сокеты надолго )

ыгы

Что-то типа того

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

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

Нет

Он даже не вызывает первый раз колбек, для вычитки

+ это простой GET запрос

Из AB

Там всего данных до 1Кб

плюс загодлвки, немного, но все же

жаль, что у меня не воспроизводится

А ты сделай ab -c 500 -n 100000 127.0.0.1:8080/

И, думаю, у тебя тоже будет такая ситуация

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

+ cb будет вызываться до тех пор, пока есть что-то в буфере

Если я из него вычитал пару байт, это не значит, что то, что в нем осталось - пропадет

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

там делантся ev_stop/start, вроде эт значит, что сбразывается. ev не вызывает колбэк, пока данные есть, а вызывает, когда была активность.

Сейчас проверю

там делантся ev_stop/start, вроде эт значит, что сбразывается. ev не вызывает колбэк, пока данные есть, а вызывает, когда была активность.

Не

Работает

Вычитывал по 2 байта и после каждой вычитки перерегистрировал в loop

Работает

if (revent & EV_READ){ received = recv(io.fd, buffer, 2, 0); writeln("read: ", received); if (received < 1){ return closeFd(loop, io); } myIo.bufferIn ~= buffer[0..received]; reInit(loop, io, EV_READ); }

И вычитал все данные

Пофиксил проблему О.о

Просто убрал O_NONBLOCK

Тоесть сокеты блокирующие и все стало работать!

Без зависаний

Ну пока...

А там посмотрим)

Не, все равно виснит

а кто-нибудь случайно не знает где-нибудь double linked list, который может работать с Unique?

Почему так?

Я что-то туплю, а теперь как этот код должен выглядеть? https://dlang.org/changelog/2.081.0.html#implicit_catch_error

круть) как в Java уже

покажи плиз как теперь должно быть

https://tour.dlang.org/tour/ru/basics/exceptions

для кого тур переводили? :)

ERROR: S client not available

и держим в актуальном состоянии +-

А все дошло

Ну, без указания какого именно исключения/ошибки ты ждёшь, Кетч писать нельзя

Логично

Я что-то туплю, а теперь как этот код должен выглядеть? https://dlang.org/changelog/2.081.0.html#implicit_catch_error

Даже не знал что такое было

Там для плюсов много фишек добавили как понимаю. Видать идея совместимости не покидает

Лучше бы GC допилили. В сто раз полезнее было бы

Там для плюсов много фишек добавили как понимаю. Видать идея совместимости не покидает

У плюсов бинарный интерфейс не стандартизован же

Лучше бы GC допилили. В сто раз полезнее было бы

+1

последнее время стали большие релизы получаться. Раньше я даже не замечал их

вообще кстати по-моему можно фичи поднимаются в списке, если на них задонатить

можем скинуться чатом, если договоримся какую фичу все хотят

точней не скинуться, а а договориться и задонатить вместе то, что считаем нужным

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

сытые западные программисты или неизбалованные отечественные

я не знаю внутренней кухни сообщества

Сытые западные что-то донатят сами очень мало. В моем понимании им там 2-3 тыс долларов должно быть не сложно с рыла скинуть, а по факту там донаты 50-70 баксов в среднем получаются

ну, как бы, и для сытых западных программистов 2-3 тысячи долларов — это 2-3 тысячи долларов)

под западом подразумеваются США или Европа? Для вторых 2-3к - 75% - 90% от мединной нетто з.п. Для первых Почти 50% от нетто з.п. На "семечки" мало походит. Про з.п. США могу ошибаться, но на европейские позиции собеседуюсь последние пару месяцев

хотя я опять-таки смотрю в webdev, не могу говорить все отрасли

Нетто это типа на руки?

Мне тут вакансия упала на почту. Бэкэнд. Требуется знание Фотошоп, JQuery и PHP. Боюсь даже предположить чем они там занимаются.

Нетто это типа на руки?

да

Тупой вопрос №10. Что, все еще нет конвертеров C в D?

Тупой вопрос №10. Что, все еще нет конвертеров C в D?

)))

Мне тут вакансия упала на почту. Бэкэнд. Требуется знание Фотошоп, JQuery и PHP. Боюсь даже предположить чем они там занимаются.

ФулСтек

Только ОЧЕНЬ фул)))

Да под фулстеком какой трэш только не встречается.

Мне тут вакансия упала на почту. Бэкэнд. Требуется знание Фотошоп, JQuery и PHP. Боюсь даже предположить чем они там занимаются.

Натягивают шаблоны от десигнеров, видимо

Тупой вопрос №10. Что, все еще нет конвертеров C в D?

как-то она не прям чтобы огонь

dstep, кажется называется

https://code.dlang.org/packages/dstep