Сжатие XML-метрики. - PullRequest
       19

Сжатие XML-метрики.

3 голосов
/ 25 октября 2008

У меня есть клиент-серверное приложение, которое отправляет XML по TCP / IP с клиента на сервер, а затем передает его другим клиентам. Откуда я знаю, какой минимальный размер XML-кода гарантирует повышение производительности за счет сжатия XML-файла, а не его отправки по обычному потоку.

Есть ли хорошие показатели по этому или примерам?

Ответы [ 5 ]

2 голосов
/ 25 октября 2008

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

Другим вариантом будет обмен в двоичном формате; BinaryFormatter или NetDataContractSerializer - простые варианты, но оба они общеизвестно несовместимы (например, с Java) по сравнению с XML.

Другим вариантом может быть переносимый двоичный формат, такой как "протокол буфера" Google. Я поддерживаю версию .NET / C #, которая называется protobuf-net . Это разработано, чтобы быть совместимым бок о бок с обычными подходами .NET (такими как XmlSerializer / DataContractSerializer), но намного меньше, чем xml, и требует значительно меньше обработки (ЦП и т. Д.) Для сериализации и десериализации.

На этой странице показаны некоторые цифры для XmlSerializer, DataContractSerializer и protobuf-net; Я думал, что он включает в себя статистику с / без сжатия, но они, похоже, исчезли ...

[обновить] Я должен был сказать - в проекте QuickStart есть пример TCP / IP.

1 голос
/ 25 октября 2008

Свободным показателем будет сжатие чего-либо большего, чем один пакет, но это просто придирки.

Нет причин воздерживаться от использования двоичного формата внутри вашего приложения - независимо от того, сколько времени займет сжатие, нагрузка на сеть будет на несколько порядков медленнее, чем сжатие (если только мы не говорим об очень медленных устройствах). ).

Если эти два предложения не успокаивают вас, вы всегда можете проверить, где найти место для сжатия.

0 голосов
/ 25 октября 2008

В проведенных нами тестах мы обнаружили огромное преимущество, однако помните о последствиях для процессора.

В рамках одного проекта, над которым я работал, мы отправляли большие объемы данных XML (> 10 мегабайт) клиентам, работающим на .NET. (Я не рекомендую это как способ сделать что-то, это просто ситуация, в которой мы оказались !!) Мы обнаружили, что, поскольку файлы XML стали достаточно большими, библиотеки Microsoft XML не смогли проанализировать файлы XML (машины закончились памяти даже на машинах> 1 гиг). Изменение библиотек синтаксического анализа XML в конечном итоге помогло, но прежде чем мы это сделали, мы включили сжатие GZIP для передаваемых данных, что помогло нам анализировать большие документы. На наших двух веб-серверах на основе Linux мы смогли сгенерировать XML, а затем довольно легко его сжать. Я думаю, что с 50 пользователями, делающими это одновременно (загружая от 10 до 20 этих файлов), мы смогли сделать это нормально, с 50% процессором. Похоже, что сжатие XML лучше обрабатывалось (то есть время разбора / процессора) на серверах, чем в .net-интерфейсах, но это, вероятно, было связано с вышеуказанными недостатками используемых библиотек Microsoft XML. Как я уже упоминал, есть лучшие библиотеки, которые работают быстрее и используют меньше памяти.

В нашем случае мы также получили значительные улучшения в размере - мы сжимали 50 мегабайт XML-файлов, в некоторых случаях до 10 мегабайт. Это, очевидно, также помогло повысить производительность сети.

Так как мы были обеспокоены влиянием, и будет ли это иметь другие последствия (наши пользователи, казалось, делали вещи большими волнами, поэтому мы были обеспокоены, что у нас не хватит процессора), у нас была переменная конфигурации, которую мы могли бы использовать включить / выключить gzip. Я бы порекомендовал вам сделать это тоже.

Другое дело: мы также заархивировали файлы XML, прежде чем сохранить их в базах данных, и это сэкономило около 50% пространства (файлы XML варьировались от нескольких килобайт до нескольких мегабайт, но в основном довольно маленькие). Вероятно, проще сделать все, чем выбрать определенный уровень, чтобы определить, когда использовать сжатие или нет.

0 голосов
/ 25 октября 2008

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

Надеюсь, это поможет.

0 голосов
/ 25 октября 2008

Всегда сжимайте его всегда.

Это сэкономит вам пропускную способность для всего с более чем 2 тегами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...