V
это ты, конечно, интересно придумал
но важно-то, что ReadFull не приводит к вызову сискола
Size: a a a
2020 February 27
DP
Т
Эта шутка не стареет
V
это ты, конечно, интересно придумал
но важно-то, что ReadFull не приводит к вызову сискола
но важно-то, что ReadFull не приводит к вызову сискола
Уточни, плз. Это как?
Он же должен считать буфер, значит делает read. Сисколов не будет только в случае, если read, к примеру, вернул 1000 байт, а мы потом делаем 100 ReadFull по 10 байт - получим сисколл на 100 запросов.
Или там как-то по иному?
Он же должен считать буфер, значит делает read. Сисколов не будет только в случае, если read, к примеру, вернул 1000 байт, а мы потом делаем 100 ReadFull по 10 байт - получим сисколл на 100 запросов.
Или там как-то по иному?
DP
Уточни, плз. Это как?
Он же должен считать буфер, значит делает read. Сисколов не будет только в случае, если read, к примеру, вернул 1000 байт, а мы потом делаем 100 ReadFull по 10 байт - получим сисколл на 100 запросов.
Или там как-то по иному?
Он же должен считать буфер, значит делает read. Сисколов не будет только в случае, если read, к примеру, вернул 1000 байт, а мы потом делаем 100 ReadFull по 10 байт - получим сисколл на 100 запросов.
Или там как-то по иному?
там в недрах eventloop, и ReadFull, если данных недостаточно, говорит шедулеру “позовешь меня, когда появится еще”, и ложится в память, пока не позовут.
DP
в любом случае, read на сокете не вызывается нак прямо
DP
строить свой протокол поверх udp
V
строить свой протокол поверх udp
Протокол чужой и древний (smpp).
RS
Подскажите, насколько эффективно использовать io.ReadFull при чтении tcpstream'а или лучше читать в буфер всё, что прилетело из сети и потом парсить? Будут грабли с переключением контекста в системном вызове или всё уже закешировано?
Задача - читать бинарный протокол, данные летят в одной tcp сессии, заголовок 16 байт + variable часть, длина которой лежит в заголовке. Читать много, по 50-100k пакетов в секунду (делаю генератор нагрузки), т.е. по 100-200k io.ReadFull'ов в секунду.
Альтернатива - делать read и самому разбираться "что именно получил" разделяя на нужные куски (если получил неполный пакет, то возвращаемся в цикле и продолжаем делать read).
Задача - читать бинарный протокол, данные летят в одной tcp сессии, заголовок 16 байт + variable часть, длина которой лежит в заголовке. Читать много, по 50-100k пакетов в секунду (делаю генератор нагрузки), т.е. по 100-200k io.ReadFull'ов в секунду.
Альтернатива - делать read и самому разбираться "что именно получил" разделяя на нужные куски (если получил неполный пакет, то возвращаемся в цикле и продолжаем делать read).
гадать не стоит, лучше проверять, т.е. бенчмаркить 🙂
V
гадать не стоит, лучше проверять, т.е. бенчмаркить 🙂
Ну я на всякий случай спросил, вдруг у кого-то уже есть верный ответ на этот вопрос ;)
Пока вообще не могу понять, во что упираюсь - получаю порядка 50-60k pps причём на сильно разных по производительности машинах.
Буду профайлером проверять, искать узкое место. И пока оно явно не в read/write.
Пока вообще не могу понять, во что упираюсь - получаю порядка 50-60k pps причём на сильно разных по производительности машинах.
Буду профайлером проверять, искать узкое место. И пока оно явно не в read/write.
P
Подскажите, какой алгоритм сортировки в го реализован?
RS
Ну я на всякий случай спросил, вдруг у кого-то уже есть верный ответ на этот вопрос ;)
Пока вообще не могу понять, во что упираюсь - получаю порядка 50-60k pps причём на сильно разных по производительности машинах.
Буду профайлером проверять, искать узкое место. И пока оно явно не в read/write.
Пока вообще не могу понять, во что упираюсь - получаю порядка 50-60k pps причём на сильно разных по производительности машинах.
Буду профайлером проверять, искать узкое место. И пока оно явно не в read/write.
профайлер не всё раскроет, возможно придётся ещё повозиться с трейсером
P
Смотрел исходник. Там реализации всех алгоритмов) но так и не понял какой по дефолту работает