Я подозреваю, что здесь есть путаница в терминах, вызывающая путаницу в том, что вы пытаетесь решить.
Поставщик услуг хостинга обычно предлагает объем трафика (часто называемый пропускной способностью) в месяц. Это может быть 500 МБ или 1 ТБ и т.д., В зависимости от предлагаемого плана. Если эта "пропускная способность" слишком мала, вы будете платить хостингу за чрезмерное потребление трафика. В целом, ваша цель как разработчика приложения состоит в том, чтобы сократить объем отправляемых и получаемых данных для каждого пользователя, потому что, в основном, меньше данных и одинаковое или лучшее удовлетворение пользователей и транзакций означают, что вы не отправляете лишние данные и взимать плату за бизнес (это очень общее правило, которое легко нарушить контрпримерами; однако, принцип отказа от отправки ненужных дополнительных данных хорош).
Пользователям веб-службы также нужна полоса пропускания, как это условно определено - объем данных, передаваемых за единичный интервал, обычно измеряется в битах в секунду. Это также обычно зависит от ограничений, установленных вашим поставщиком услуг хостинга, потому что вы делитесь ими с другими людьми и потому что в какой-то момент их подключение к Интернету будет ограничено. В хостинге (между машинами) вы можете смотреть на 1 Гбит / с (1 000 000 000 бит в секунду). Ваш хостинг может иметь ограничение в 30 МБ / с (небольшой хостинг, не близко к магистрали). Нет четкой взаимосвязи между этой "мгновенной" пропускной способностью, максимальной скоростью пакетной передачи, которую вы отправляете, и ежемесячным использованием данных (ежемесячная пропускная способность хостинга). Вы можете передавать данные с высокой скоростью, но использовать только небольшое количество. OTOH, если ваша максимальная скорость низкая, то вы не можете превысить месячную пропускную способность ... Но прежде чем это станет проблемой, пользователи будут жаловаться на производительность.
И это, вероятно, реальная проблема здесь. Спектакль. Я подозреваю, что клиенты жалуются, что дела идут недостаточно быстро. Это приводит к рассмотрению пропускной способности. Но это не проблема. Проблема производительности заключается в том, что ваши серверы заблокированы. Когда пользователь делает запрос, сервер начинает обработку, блокируется, а затем время ожидания клиента. Пользователь видит плохой сервис, а вы идете оптимизировать ... что?
Вы выбрали оптимизацию скорости передачи данных. Но это, вероятно, не проблема. Сбой службы является проблемой. Исправьте приложение, и тогда у клиентов больше не будет тайм-аут. Дело не в том, сколько данных и как быстро они зависают, что является абсолютным препятствием для выполнения работы на любом уровне пропускной способности.
