2008-10-25 4 views
3

클라이언트에서 서버로 TCP/IP를 통해 XML을 보낸 다음 다른 클라이언트로 브로드 캐스트하는 클라이언트 서버 응용 프로그램이 있습니다. 일반 스트림을 보내지 않고 XML을 압축하여 성능을 향상시킬 수있는 XML의 최소 크기가 무엇인지 어떻게 알 수 있습니까?압축 XML 메트릭.

이 예제에 대한 좋은 측정 항목이 있습니까?

답변

2

Xml은 대개 반복성이 높기 때문에 일반적으로 매우 잘 압축됩니다.

또 다른 옵션은 바이너리 형식으로 스왑하는 것입니다. BinaryFormatter 또는 NetDataContractSerializer는 간단한 옵션이지만 xml과 비교할 때 모두 Java와 호환되지 않는 것으로 악명이 높습니다.

또 다른 옵션은 google의 "프로토콜 버퍼"와 같은 휴대용 이진 형식입니다. 나는 .NET/C# 버전 인 protobuf-net을 유지 관리하고 있습니다. 이것은 일반적인 .NET 접근 방식 (XmlSerializer/DataContractSerializer 등)과 나란히 호환되도록 설계되었지만 xml보다 훨씬 작으며 직렬화와 비 직렬화 모두에서 처리 (CPU 등)가 훨씬 적게 필요합니다.

This page은 XmlSerializer, DataContractSerializer 및 protobuf-net의 일부 숫자를 보여줍니다. 나는 라고 생각하면 압축이 있거나없는 통계가 포함되어 있지만 사라진 것으로 보입니다 ...

[업데이트] QuickStart 프로젝트에 TCP/IP 예제가 있습니다.

0

꼭 압축하십시오.

두 개 이상의 태그가있는 경우 대역폭을 절약 할 수 있습니다.

+0

하지만 지퍼 링과 압축 해제로 오버 헤드가 없습니까? – leora

+0

또한 클라이언트가 XML을 해석하는 방법을 고려해야합니다. 예를 들어, SAX는 큰 XML에 대해 압축 된 스트림을 구문 분석하고 DOM을 통해 전체 XML을 압축 해제하고로드해야합니다. – duckworth

+0

스트림에서는 언제든지 직접 압축/압축 풀기를 사용할 수 있습니다. C#을 모르지만 Java에서 작동합니다. InputStream st = new GZipInputStream (inStream); st.read() – Marko

0

압축이 효과가 있는지 판단하려면 시스템에 예상되는 예상 데이터 양을 사용하여 몇 가지 테스트를 실행해야합니다.

희망이 도움이됩니다.

1

느슨한 메트릭은 단일 패킷보다 큰 모든 것을 압축하는 것이지만 단순한 질의입니다.

응용 프로그램에서 내부적으로 바이너리 형식을 사용하는 것을 삼가야 할 이유가 없습니다. 시간이 많이 걸리더라도 네트워크 오버 헤드는 압축하는 것보다 몇 배 더 느릴 것입니다 (장치).

두 가지 제안을 통해 쉽게 적응할 수없는 경우 벤치 마크를 통해 압축 할 지점을 찾을 수 있습니다.

0

우리가 수행 한 테스트에서 우리는 큰 이점을 발견했지만 CPU 관련 사항에 유의해야합니다.

한 프로젝트에서 .NET을 실행하는 클라이언트에 많은 양의 XML 데이터 (> 10MB)를 보냈습니다. XML 파일이 충분히 커질수록 Microsoft XML 라이브러리가 XML 파일을 구문 분석 할 수 없다는 것을 알게되었습니다 (컴퓨터가 다 떨어졌습니다. > 1 기가 이상의 컴퓨터에서도 마찬가지입니다. XML 구문 분석 라이브러리를 변경하면 결과적으로 도움이되었지만 이전에 우리가 전송 한 데이터에서 GZIP 압축을 사용하도록 설정했기 때문에 큰 문서를 구문 분석하는 데 도움이되었습니다. 우리의 두 리눅스 기반 웹 스피어 서버에서 우리는 XML을 생성 한 다음 상당히 쉽게 gzip을 처리 할 수있었습니다. 50 명의 사용자가이 파일을 동시에 (약 10 ~ 20 개의 파일 로딩) 동시에 실행하면 약 50 %의 CPU로이 작업을 수행 할 수있었습니다.XML의 압축은 .net GUI보다 서버에서 처리 (즉, 구문 분석/CPU 시간)가 더 나은 것처럼 보였습니다.하지만 이는 아마도 위에 언급 된 Microsoft XML 라이브러리의 부적절한 사용으로 인한 것일 수 있습니다. 앞에서 언급했듯이, 더 빠르고 더 적은 메모리를 사용할 수있는 더 나은 라이브러리가 있습니다.

우리의 경우 우리는 크기면에서도 엄청난 발전을 이루었습니다. 50 메가의 XML 파일을 경우에 따라 약 10 메가까지 압축했습니다. 이것은 분명히 네트워크 성능을 도왔습니다.

우리는 영향에 대해 우려하고 있었고 이것이 다른 결과를 가져올 수도 있기 때문에 (우리 사용자는 큰 파도에서 일을하는 것처럼 보였으므로 우리는 CPU가 부족하다는 것을 염려했습니다) 우리는 gzip을 켜고 끌 때 사용합니다. 나는 네가이 일을하도록 권하고 싶다.

또 하나 : XML 파일을 데이터베이스에 저장하기 전에 압축하여 약 50 %의 공간 (XML 파일의 크기는 몇 K에서 몇 메가이지만 대개 상당히 작음)을 절약했습니다. 압축을 사용할 때와 사용하지 않을 때를 구분하는 특정 레벨을 선택하는 것보다 모든 일을 더 쉽게 할 수 있습니다.