ВН
на сервере
Size: a a a
2020 June 08
AT
Вероятно это добавочное время - время переключения контекста/время на прерывания
ВН
на клиенте тоже
RS
Там прямая зависимость от цены
и кстати мы ж понимаем что цена это просто хотелки компании а не "реальная" стоимость
ВН
Вероятно это добавочное время - время переключения контекста/время на прерывания
вот, а что это за прерывания-то такие?
меня именно удивляет, что есть работа с диском - сетевой раундтрип высокий, а нет - низкий
при этом работа с диском она происходит между получением и отправкой сообщения, т.е. не должна никак влиять на раундтрип
т.е
- получил
- записал
- отправил ответ
» вот тут задержка 90 мкс «
- получил
- записал
- отправил ответ
меня именно удивляет, что есть работа с диском - сетевой раундтрип высокий, а нет - низкий
при этом работа с диском она происходит между получением и отправкой сообщения, т.е. не должна никак влиять на раундтрип
т.е
- получил
- записал
- отправил ответ
» вот тут задержка 90 мкс «
- получил
- записал
- отправил ответ
ВН
по логике вроде от диска все прерывания должны были произойти в интервале между "получил" и "отправил ответ"
AT
Интересно было бы померять
https://vilimpoc.org/research/ku-latency/
https://vilimpoc.org/research/ku-latency/
ВН
а на прерывания от сетевухи - как, сука, диск-то на них влияет
ВН
ну хотя да, если только представить какой-нибудь маразм типа того что у процессора есть только 1 канал прерывания ))) и он его отдаёт то диску то сети )))
ВН
но это же маразм какой-то, вроде
VO
так ты делал вариант где на сервере у тебя выполняется clock_gettime(CLOCK_REALTIME) сразу после получения, непосредственно до записи, сразу после и непосредственно после отправки?
ВН
APIC и всё такое
ВН
так ты делал вариант где на сервере у тебя выполняется clock_gettime(CLOCK_REALTIME) сразу после получения, непосредственно до записи, сразу после и непосредственно после отправки?
ага
ВН
вот именно там эти 90 мкс
AT
ну хотя да, если только представить какой-нибудь маразм типа того что у процессора есть только 1 канал прерывания ))) и он его отдаёт то диску то сети )))
Я всегда думал что в пределах потока почти так и происходит :)
VO
ну и где все четыре временых интервала в полсном вариаенте?
VO
ты что-то не то отвечаешь
ВН
ну и где все четыре временых интервала в полсном вариаенте?
ну там чуть-чуть сложнее, на самом деле в середине 2 записи
но примерно так:
- от получения epoll до начала записи на диск 14us
- от начала записи на диск до конца записи на диск ~70us (там 2 записи на самом деле)
- потом sendmsg проходит ещё за 6us (ну то есть можно не учитывать его даже)
- и дальше мы засыпаем до следующего epoll на 90us
но примерно так:
- от получения epoll до начала записи на диск 14us
- от начала записи на диск до конца записи на диск ~70us (там 2 записи на самом деле)
- потом sendmsg проходит ещё за 6us (ну то есть можно не учитывать его даже)
- и дальше мы засыпаем до следующего epoll на 90us
ВН
в усреднённом понимании - сервер видит среднюю латенси операции "от начала записи на диск" "до конца записи на диск" (точнее от момента завершения получения операции до начала отправки ответа) 73us, а клиент общую с учётом сети ~164us
ВН
при этом если сервер ничего не делает, а просто отправляет ответ, то клиент видит латенси 47us