Сжатие IIS против ручного GZIP

Question

В настоящее время я работаю над проектом, который передает некоторые геоданные через службу WCF.Эти данные увеличиваются в размерах (иногда 2-4Мб, а в особых случаях даже больше).Чтобы помочь уменьшить размер данных по сети, мы изначально включили сжатие gzip на IIS (это творит чудеса).Увы, в ходе тестирования мы обнаружили, что один из используемых нами прокси-серверов делает это бесполезным.

Итак, вместо этого я решил сжать сами данные, прежде чем они будут отправлены из нашего сервиса.Я использую SharpZipLib как в WCF, так и в нашем клиенте Silverlight.Он работает хорошо и сжимает наши данные с примерно 2,9 МБ до примерно 400 КБ, однако сжатие IIS способно еще больше снизить эффективность.

Теперь мне любопытно ...

1. Есть ли какой-нибудь секретный соус за сжатием IIS GZip, который делает его лучше?

2. Есть ли лучший алгоритм сжатия, который можно использовать?

Answer 1

Есть ли какой-нибудь секретный соус за сжатием IIS GZip, который делает его лучше?

В SharpZipLib вы можете использовать SetLevel(9) (при использовании zip), чтобы установить максимальное сжатие.Однако вы должны помнить, что вся полезная нагрузка сжимается, когда вы проходите сжатие через IIS, а когда вы выполняете свою собственную, это только часть полезной нагрузки.Поэтому IIS всегда сможет сжимать немного больше.

Есть ли лучший алгоритм сжатия, который можно было бы использовать?

Через IIS, не совсем.Существует только так много методов сжатия, которые можно использовать через HTTP: http://en.wikipedia.org/wiki/HTTP_compression.

С пользовательским сжатием вы можете попробовать 7zip, lzh и т. Д. - все, что вы можете найти в библиотеке или написать самостоятельно.Многое зависит от того, что вы архивируете, так как разные полезные данные сжимаются по-разному.Я бы попробовал те, которые встроены в sharpziplib сразу (bzip2).Я также попробовал бы 7zip (возможно с c #)

Answer 2

Я немного поигрался с различными компрессиями, а потом до меня дошло. Конечная точка WCF настроена для использования двоичного кодирования. Это означает, что IIS будет принимать двоичные закодированные данные и применять к ним сжатие.

В моем случае я сериализовал данные с использованием стандартного DataContractSerializer и MemoryStream. Это однако выплевывает XML.

Лучшим решением, которое мы нашли, было использование BinaryDictionaryWriter в моем DataContractSerializer. Это дает мне двоичные данные, которые я могу затем сжать с помощью GZIP. Окончательные результаты дают лучшее сжатие, чем мы получили с IIS. (Для порядка 700K через IIS до 500K с использованием этого метода)

Пример использования BinaryDictionaryWriter вы можете увидеть в следующем посте. Это ответ ниже утвержденного ответа. Как передать большой объем данных с помощью WCF?

Посмотрим, как теперь удаляет двоичное кодирование из конечной точки, чтобы узнать, стоит ли эта производительность дополнительного уровня «вещи».

Answer 3

1) Да, есть секретный соус, но я не знаю, что это такое.

Но это то, что я действительно хотел сказать:

2) Ваше желание повысить степень сжатия может замедлить работу вашего сайта. Не делай этого. Микрооптимизация на этом уровне бесполезна.