none
WCF + WIF: Performance issue RRS feed

  • Question

  • Hello!

    We experience a problem with WCF service performance. 

    Environment:

    1) Intel Xeon X5660, 24 cores 2,8Ghz, 8 Gb RAM, 1 Gb Ethernet

         Server 2008 R2 SP1, IIS 7.5, .Net Framework 4.5.1

    2) WCF Service hosted in IIS. AppPool set to integrated mode + .net v4.0

       Service exposes endpoint with wsHttpBinding + authentication by SAML token, security mode = message, security context = false.

       We remove all our bussiness logic from service, so service methods are empty.

    3) For load testing we wrote utility. Test utility runs several threads making call to the service.

    Workflow is:

     a) each thread obtains SAML token from test STS.

     b) then it runs infinite loop

     c) on each iteration channel with issued SAML token is created.

         then we make a call to the service and close channel.

    for (int i = 0; i < roundSteps; ++i)
    {                
       wcfService = ssChannelFactory.CreateChannelWithIssuedToken((SecurityToken)clientCred);
       wcfService.CallMethod(...);
       ((IChannel)wcfService).Close();
    }

    So in this scenario we could achive only 130 req per second, and about 6% CPU.

    If we involve more client only message queue will grow up (watch by appcmd list requests).

    Some more information:

    a) Each request size is about 39Kb

    b) Request process time is about 15ms

    c) Connection setting on client hosts are tuned: ServicePointManager.DefaultConnectionLimit = 10;

    d) We tried some performance tuning on the Server - with no luck.

    Change <processmodel> settings; set ThreadPool.SetMinThreads; use SynchronizationContext in WCF

    If we change test scenario - we'll get much better result - about 1700 req per sec, 30-40% CPU:

     * change binding to use SecurityContext

     * client creates and opens channel only once (so clients work in sessions)

    What can be done to improve performance?

    Thanks


    • Changed type xmv.cp Wednesday, February 19, 2014 5:44 PM misunderstanding
    Wednesday, February 19, 2014 10:42 AM

All replies

  • For developers familiar with WCF, a WCF client is already federation aware. By configuring a WCF client with a WSFederationHttpBinding or similar custom binding, it is possible to enable federated authentication to a service.

    WCF takes care of obtaining the issued token behind the scenes, and uses this token to authenticate to the service. The primary limitation with this approach is that there is no visibility into the communications with the issuer. Since WCF takes care of the issuer leg behind-the-scenes, the RST to the issuer is automatically generated by WCF based on the issued token parameters on the binding. The limitations in this space include but are not limited to:

    a. Not possible to vary the RST parameters per request.

    b. Not possible to inspect the RSTR to get information such as display claims, etc.

    c. Not easy to cache the token for future use.

    As it stands today, the WCF client suffices for basic federation scenarios. However, considering that one of the mainline scenarios introduced by Windows Identity Foundation requires control over the RST at a level WCF does not easily allow, more flexibility is needed. Windows Identity Foundation ships several client side pieces that aim to remove the "magic" of WCF, and give developers complete control over communication with the issuer.

    Before we go into the details of the client side pieces, understand that the following federation scenarios are supported by WIF.

    1. Using a WCF client without any WIF dependencies to authenticate to a federated service.

    2. Augumenting a WCF client with WIF, to insert an ActAs or OnBehalfOf element into the RST to the issuer.

    3. Using WIF alone, obtain a token from the issuer. Then, enable a WCF client to authenticate with this token.

    Thursday, February 20, 2014 6:12 AM
  • Issue is performance of WCF service with authentication by SAML token. No matter how token has been obtained: by WS-Federation or out of the scope.

    Both cases (wsFederationBinding and wsHttpBinding with auth by token) show 130 req per sec and 6% CPU.

    Where is scalability?



    • Edited by xmv.cp Thursday, February 20, 2014 6:50 AM
    Thursday, February 20, 2014 6:49 AM