порядки величины задержки для архитектуры приложения

Question

Существует ли ссылка, в которой приблизительно указано, сколько времени (в относительном или абсолютном выражении) требуется для передачи информации по сети (udp или tcp / ip), диску, памяти (последовательный / произвольный доступ), в процессе и между процесс и т.д.?

В конце концов мне придется измерить их, но я буду признателен за указатели на цифры с парком.

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

Answer 1

Я еще не сталкивался ни с чем подобным, и думаю, что на самом деле нет другого пути, кроме тестирования для ваших конкретных сценариев. Существует слишком много факторов, чтобы дать последовательный ответ: например какие сетевые адаптеры вы используете, выполняют ли они разгрузку контрольной суммы TCP, насколько эффективна ваша коммутационная матрица, какие диски вы используете, сколько у них кеша, сколько данных вы передаете, много маленьких пакетов или несколько больших пакетов и т. д. и т. д.

Когда вы говорите о времени доступа к ОЗУ, в настоящее время вы говорите о 10-100 нс, по сравнению с 4-8 мс для жестких дисков. Любой инструмент для тестирования должен дать вам хорошие результаты для измерения оперативной памяти и жесткого диска

UDP против TCP, с другой стороны, вы не можете назвать конкретные цифры. Теоретически UDP должен быть на 30-50% быстрее, чем TCP, потому что в нем отсутствует дополнительное отключение для ACK и он имеет меньшие издержки на заголовок, однако в действительности есть много случаев, когда TCP будет превосходить UDP только из-за контроля перегрузки. Кроме того, TCP с Nagle включил пакетные пакеты, что опять-таки не будет справедливым сравнением с UDP, который этого не делает.

В общем, проведите собственное тестирование в соответствии с вашими потребностями. Даже если где-то рядом с кем-то, кто проводил подобные тесты, была таблица с тестами, они могли бы быть полностью недействительными и невоспроизводимыми для вашего стека приложений и оборудования

Answer 2

+ 1 для Тома - вот что я собирался написать (чуть менее ясно), прежде чем увидел его ответ.

Еще одна вещь, которую следует учитывать, это

1. потребности в задержке и потребности в полосе пропускания

2. масштабируемость заданного решения. Э.Г.

   • Насколько сложно повысить скорость сети (вам нужно заменить сетевые платы? Проводные? Маршрутизаторы?) В зависимости от величины возможного масштаба (100 МБ против 1 ГБ)?

   • Насколько сложно повысить выигрыш в скорости диска в сравнении с увеличением скорости?

   например. более быстрый диск, диск с большей кэш-памятью, при условии, что ваш сценарий использования использует данные с кэшированием, RAID или другие данные, локальное хранилище или сетевое хранилище.

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