2013-01-23 2 views
1

서비스가 클라이언트로부터받는 메시지의 크기를 검사하기 위해 MessageSizeInspector 클래스를 작성했습니다. 여기가 모습입니다 :대역폭을 절약하기 위해 WCF 비누 메시지 크기를 줄이는 방법은 무엇입니까?

//the actual implementation logs more! 
//but in this question, my only concerns is request.ToString() 
public sealed class MessageSizeInspector : 
      BehaviorExtensionElement, //to enable it to be used in config 
      IDispatchMessageInspector, //service-side inspector 
      IEndpointBehavior   //so we can apply it on endpoint 
{ 
    if (request != null) 
    { 
     Logger.Verbose("Message = {0}\n", request.ToString())); 
    }  
    //more 
} 

그리고이 형식의 메시지 로그 : 당신이 실제 메시지가 작은입니다 볼 수 있지만 수 있듯이

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> 
    <s:Header> 
    <To s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://localhost:8961/EngineService</To> 
    <Action s:mustUnderstand="1" xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://tempuri.org/IEngineService/GetMousePatternID</Action> 
    </s:Header> 
    <s:Body> 
    <GetMousePatternID xmlns="http://tempuri.org/"> 
     <args> 
     <accelerator xmlns="http://schemas.datacontract.org/2004/07/Runaware.Insight.EngineService" /> 
     <accessKey xmlns="http://schemas.datacontract.org/2004/07/Runaware.Insight.EngineService" /> 
     <controlId xmlns="http://schemas.datacontract.org/2004/07/Runaware.Insight.EngineService">66222</controlId> 

     <!--- deleted the rest to avoid verbosity --> 

     </args> 
    </GetMousePatternID> 
    </s:Body> 
</s:Envelope> 

XML 요소와 네임 스페이스가 을을 너무 거대한. 특히 네임 스페이스는 실제 메시지와 비교하여 너무 크다.

내 질문은 : 비누 메시지의 크기를 어떻게 줄일 수 있습니까? xmlns이 모든 요소에 대해 동일하므로 WCF는이를 최적화 할 수 있지만 그렇지 않습니다. 우리가 선택한 네임 스페이스를 더 짧게 사용할 수있게 할 수 있습니까? acceleratoraccessKey과 같은 몇 가지 요소는 아무 값도 없습니다 (오른쪽으로 스크롤하여 볼 수 있듯이).하지만 여전히 있습니다! WCF를 생략하고 서비스 측면에서 null (또는 기본값)으로 가정 할 수 있습니까?

요약하면 대역폭을 절약하기 위해 할 수있는 일은 무엇입니까?

나는 위의 메시지가 동일한 XML 요소와 네임 스페이스를 사용하여 정확히 같은 형식의 클라이언트라고 가정합니다.

서버는 C# 및 WCF로 작성되었으며 클라이언트는 Windows Web Services API을 사용하여 C++로 작성되었습니다. 서비스와 클라이언트는 모두 저에게 썼습니다. 그래서 나는 그들에 대한 완전한 통제권을 가졌습니다. 필요한 경우 대역폭을 절약하기 위해 변경할 수 있습니다!

+0

WCF 서비스에 대한 제어 권한은 얼마나 있습니까? 대신에 "WebAPI"로 변경할 수있는 기회가 있습니까? –

+0

@Dommer : 전적으로 제어 할 수 있습니다. 서비스와 클라이언트 모두 나에 의해 작성되었습니다. – Nawaz

답변

0

모든 것을 완벽하게 제어 할 수 있으므로 대신 WebAPI으로 변경하지 않으시겠습니까? 당신이 당신의 최종 결정하기 전에

이 문제를 살펴 보자 : WCF Compression를 사용하는 Do I need WCF if I can use ASP.net Web API

+0

WebAPI의 장점은 무엇입니까? 클라이언트 측 또는 서비스 측용입니까? 질문에 * 관련된 * 정보를 게시하십시오. – Nawaz

+0

내 모든 서버 측 구현은 이미 WCF를 사용합니다. 지금 그것을 바꾸는 것은 너무 많은 비용이들 것입니다. –

1

흠을 잘 내 첫 번째 방법이 될 것이다. 나는 너에게 경험이 없기 때문에 오직 너에게 그 링크를 줄 수있다. 그러나 나는 꽤 좋은 개선이라고 생각한다.

질문은 당신이 클라이언트에 영향을 미치는지입니다. 구성도 편집해야하기 때문입니다.

편집 : 귀하의 의견에 대한 질문에 답변되었습니다. : o)

+0

참고 : .NET 4 이상을 사용하는 경우이 문서의 '해결 방법'은 더 이상 필요 없으며 IIS에서 직접 압축을 사용할 수 있습니다. –

1

SOAP에 오신 것을 환영합니다. 많은 사람들이 무지로 만나요. XML도 좋지만 SOAP도 있지만 텍스트 기반의 표현 시스템을 사용하는 오버 헤드가 있습니다. 특히 작은 메시지의 경우에는 대역폭이 적습니다.

IIS에서 압축하지 않은 다음 soap/xml을 삭제하고 JSON으로 웹 API로 이동하는 방법은별로 많지 않습니다. 웹 servivec/soap 표준은 상당히 - hm - 명시 적이며 표준입니다. 그것을 우회 (드롭 요구 사항, 뭔가 다른 사용) 정말 그것을 처리하는 유일한 방법입니다.

+0

실제로 Json은 더 나쁠 수 있습니다. JSON도 XML도 최적화되어 있지 않습니다. 그들은 모두 인간의 소비를 위해 설계되었습니다. 바이너리는 훨씬 더 나은 직렬화 방법이지만 불행히도 WCF의 바이너리 DataContractSerializer는 SOAP과 동일한 직렬화 문제로 어려움을 겪고 있습니다. –

2

DataContracts, DataMembers 및 ServiceContracts에 이름과 네임 스페이스를 설정해보십시오.

예 :

:이 같은 XML 짧아, "A" "네임 스페이스에서" "와 속성으로 FullName으로 호출 할"로 사람을 호출 할 것

[DataContract(Name = "a", Namespace = "")] 
class Person 
{ 
    [DataMember(Name = "a")] 
    public string FullName; 
    [DataMember(Name = "b)] 
    public int Age; 
} 

<a> -- Represents the Person class 
    <a>Name of the person</a> -- Represents the FullName property 
    <b>38</b> 
</a> 

속성 및 클래스는 DataContract 및 DataMembers와는 다른 "짧은"이름을 가져야합니다.

참조 : https://bkiener.wordpress.com/2010/05/04/optimize-data-contracts-for-better-wcf-performance/

+0

와우. 이것은 큰 도움이됩니다. 그것은 너무나 명백하지만 나에게는 일어나지 않았다. –

관련 문제