Можно ли снизить стоимость передачи данных AWS, перейдя с HTTP API на gRP C? - PullRequest
2 голосов
/ 24 апреля 2020

У меня есть веб-сервис, который обрабатывает значительный объем трафика c. Этот трафик c может быть в диапазоне миллионов в минуту. Служба размещена в AWS EC2 за ELB и использует HTTP API. Это приводит к значительной сумме AWS счета, включающего сборы за передачу данных. Компонент Data Transfer Out в основном выше, поскольку 50% ответов от веб-службы несколько большие и кодируются как JSON в дополнение к согласованию SSL.

Теперь полезные нагрузки gRP C меньше по сравнению с аналогичными данные представлены как JSON из-за двоичной сериализации. Таким образом, можно сэкономить на затратах на передачу данных, переключившись с HTTP API на gRP C?

Я не смог найти ни одного эталона / статьи, где бы можно было сопоставить AWS Затраты на передачу данных с HTTP API / gRP C услуг. Было бы полезно сэкономить даже 5-10%.

PS: Здесь клиенты, обращающиеся к веб-сервису, тоже мои. Таким образом, можно вносить изменения как на стороне сервера, так и на стороне клиента.

1 Ответ

2 голосов
/ 24 апреля 2020

Может быть, но, вероятно, нет. Это зависит от ваших фактических данных.

Если вы используете HTTP для связи, то есть два компонента общего размера сообщения: заголовки HTTP и тело ответа. Если заголовки представляют значительную часть вашего общего размера сообщения, то имеет смысл избавиться от них с помощью альтернативного протокола уровня 7, такого как WebSockets.

Если заголовки не являются значимыми, тогда это зависит от того, каково ваше реальное содержание сообщения. Это потому, что буфер протокола, который используется gRP C, выполняет по существу две оптимизации:

  • Замена имен полей одно- или двухбайтовым значением. Это может быть большой экономией, если в вашем ответе JSON не часто используются одинаковые имена полей (ie, повторяющиеся объекты). Если это произойдет, то использование кодировки GZip снизит среднюю стоимость имени поля примерно до 5 байтов (мое наблюдение с большими файлами, YMMV).

  • Хранение номера c значения меньше, чем их нормальное количество бит. Если содержание вашего сообщения состоит из массивов чисел, это будет огромным выигрышем. Если это в основном текст, вы не увидите особой выгоды, потому что в любом случае придется отправлять одну и ту же последовательность байтов.

Лично я думаю, что переключение на WebSockets было бы лучшим первый шаг. Это предполагает, конечно, что эти сообщения приходят от относительно небольшого числа клиентов. Если каждое сообщение от другого клиента, вы ничего не сохраните.

...