У меня очень типичный сценарий:
браузер -> веб-сервер -> веб-сервис
Я видел много статей / документации о преимуществах сжатия данных, отправляемых с веб-сервера в браузер, для экономии полосы пропускания, но мне интересно, есть ли аналогичные преимущества сжатия данных между веб-службой и веб-сервером. ?
XML должен сжиматься очень мало, поэтому, конечно, мы получим те же преимущества с точки зрения пропускной способности, но мне особенно интересно, будет ли это компенсировано вычислительной мощностью, необходимой на веб-сервере для расшифровки сообщений SOAP, которые он получает. .
Кто-нибудь включил gzip для веб-сервисов и было ли улучшение производительности?
Если на то пошло, будут ли клиенты веб-сервисов даже понять gzip в первую очередь? Или включение шифрования будет пустой тратой времени, и клиент веб-службы никогда не воспользуется этим преимуществом?
Вопрос сводится к тому, что у вашего сервера есть в запасе - ЦП или пропускная способность? Если вы постоянно ждете подключения к сети, но ваш процессор простаивает, то вам, вероятно, стоит обратить внимание на сжатие. Если ваш процессор занят, но вы не отправляете много данных, то сжатие, вероятно, не для вас.
XML - это очень подробный (и, что более важно, повторяющийся) язык, поэтому сжатие, вероятно, существенно повлияет на объем передаваемых данных.
Сжатие полезно, только если его поддерживают обе стороны, иначе переключение переключателя ничего не даст. Реклама о том, что вы поддерживаете сжатие, не имеет большого значения, если сжатие вообще не используется.
Наконец, это не обязательно все или ничего, если вы передаете. Сжатие Gzip (LZ77) можно настроить для оптимизации по скорости, размеру или чему-то среднему. Как выполняется эта настройка, зависит от вашей реализации, но решение принимает только сторона, ОТПРАВЛЯЮЩАЯ данные. Распаковка сильно сжатых gzip-данных требует не больше ресурсов, чем распаковка слегка сжатых данных, так что получателю все равно все равно.
Как вы заявили, сервер отправляет заголовки по мере заархивирования содержимого, а браузер его расшифровывает.
Если вы хотите сделать это между вашим веб-сервером и веб-службой, поскольку ваша служба НЕ является браузером, вы бы сами прочитали заголовки (или предположили, что все сжато в сжатом виде), и вы использовали бы gzipdecode перед отправкой запроса обработчику SOAP.
Если вы не передаете много данных туда и обратно (которые стоит сжать), я не вижу в этом никакой пользы. Даже при благоприятном сжатии, если у вас недостаточно ЦП и ОЗУ для его поддержки, это может быть фатальным.
Надеюсь, это поможет, D
Поскольку пользовательский браузер обрабатывает gZip, веб-клиент на другом конце должен понимать, как распаковать gzip. Вы сможете убедиться в этом, заглянув в заголовки. IIRC - это заголовок «accept», а вы ищете «gzip» и «deflate».
Накладные расходы на кодирование / декодирование для gzip довольно номинальные, но они есть. Это полезно в браузерах, потому что они не очень своевременны - пользователь будет просто сидеть и раздражаться, пока страница не загрузится. Веб-сервис немного отличается, они обычно должны быть довольно быстрыми, иначе все приложение часто зависает.
Единственный раз, когда я бы предположил, что gzip был бы полезен в веб-сервисе, был бы, если бы это был простой сервис, который будет обрабатываться тысячи раз в день, когда экономия от 10 КБ до 2 КБ XML будет стоить накладных расходов на обработку. И это при условии, что веб-служба на другом конце может в первую очередь принимать gzip.
Кстати, помните, что сжатие двоичных данных МОЖЕТ дать БОЛЬШЕ информации, а не меньше. Так что в любом случае вы должны знать, какой тип данных сжимается.