none
(413) Request Entity Too Large and the ASP.NET Development Server RRS feed

  • Question

  • I have a WCF service that i am writing unit tests for with the purpose of testing speed of large datasets being transferred (i.e. 100,000 contract instances, batched in 100 contract instance increments).

    As you can probably guess, i started to see the 413 error that is somewhat common for this type of operation (large data over WCF). The main difference between myself and the others is that I am not running this on a dedicated IIS server, just using the visual studio asp.net development server.  The problem here is that it seems the dev server doesn't respect the system.webserver/serverRuntime overrides that i am providing. Pretty much all the solutions to this problem indicate a need to bump the uploadReadAheadSize higher (which i can agree with). But the dev server doesn't care what i use to override, it seems to be stuck at around 64k.

    i have the following in my web.config:

      <system.webServer>
        <modules runAllManagedModulesForAllRequests="true"/>
        <serverRuntime uploadReadAheadSize="2147483646"/>
        <security>
          <requestFiltering>
            <requestLimits maxAllowedContentLength="2147483646"/>
          </requestFiltering>
        </security>
      </system.webServer>

    So any suggestions on how to modify the uploadReadAheadSize for the dev server?  In production we would definitely allow larger datasets to be sent over WCF, so i would like to simulate that with the dev server if at all possible.

    Wednesday, March 13, 2013 12:17 AM

Answers

  • On 3/13/2013 12:43 PM, Pat Sissons wrote:

    Haha, so the load tests i am speaking of are specifically designed to confirm that WCF (and really, also on IIS) can handle the load. These are not supposed to be testing any business logic. The real unit tests do not make use of WCF, and simply test the actual functions.

    You have to assume that WCF and IIS can handle the load, but you can test it by just making a classlib test project and testing the WCF service with IIS as a test-harness.

    About the only problem you would have is if the WCF settings are not sufficient to handle large loads. However, you'll have to look at can the server itself (the machine) can it handle the load and not IIS and WCF per say.

    <http://www.codeproject.com/Articles/133738/Quick-Ways-to-Boost-Performance-and-Scalability-of>

    <http://www.codeproject.com/Articles/186233/Utilize-gzip-compression-in-IIS>  You can find other articles concerning the above. Maybe you test it once or as need be.  But to do it in some kind of a auto build process?
     MS VS Unit Testing will not be able to host the classlib that is consuming a WCF Web service, but Reshape can do it with debugging and the whole 9 yards.

    Wednesday, March 13, 2013 6:00 PM

All replies

  • Hi,

    To make it working when WCF service will transfer large amount of data in operations, there are various configuration settings you need check, maxReceivedMessageSize, <readerQuotas> settings,  MaxItemsInObjectGraph property etc. You may check a detail reply by Steven in this post.

    http://forums.asp.net/t/1795600.aspx/1

    If the issue still exists, I would suggest you turn on wcf tracing for your service to help to dignose the issue and analyze diagnostic traces with SvcTraceViewer.exe.

    #How to enable WCF tracing

    http://blogs.msdn.com/b/madhuponduru/archive/2006/05/18/601458.aspx

    Best Regards.


    Haixia
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, March 13, 2013 8:03 AM
    Moderator
  • I guess i should have been more explicit. This is absolutely 100% an IIS issue. I of course have all the WCF limits and quotas set, and can confirm that WCF is able to send the large data graphs when i host the service outside of IIS.

    Within IIS, however, any time that i need to send a data graph over 64k to the WCF service, the 413 error occurs. Receiving data graphs larger than 64k is not an issue.

    Wednesday, March 13, 2013 3:07 PM
  • On 3/12/2013 8:17 PM, Pat Sissons wrote:

    I have a WCF service that i am writing unit tests for with the purpose of testing speed of large datasets being transferred (i.e. 100,000 contract instances, batched in 100 contract instance increments).

    I hate to be picky, but that is not unit testing. It is integration testing.

    <http://www.andreas-schlapsi.com/2009/09/20/when-is-a-test-a-unit-test/>


    As you can probably guess, i started to see the 413 error that is somewhat common for this type of operation (large data over WCF). The main difference between myself and the others is that I am not running this on a dedicated IIS server, just using the visual studio asp.net development server.  The problem here is that it seems the dev server doesn't respect the system.webserver/serverRuntime overrides that i am providing. Pretty much all the solutions to this problem indicate a need to bump the uploadReadAheadSize higher (which i can agree with). But the dev server doesn't care what i use to override, it seems to be stuck at around 64k.
    i have the following in my web.config:

         <system.webServer>
             <modules runAllManagedModulesForAllRequests="true"/>
             <serverRuntime uploadReadAheadSize="2147483646"/>
             <security>
                 <requestFiltering>
                     <requestLimits maxAllowedContentLength="2147483646"/>
                 </requestFiltering>
             </security>
         </system.webServer>

    So any suggestions on how to modify the uploadReadAheadSize for the dev server?  In production we would definitely allow larger datasets to be sent over WCF, so i would like to simulate that with the dev server if at all possible.

    I think you are going to have to come away from the VS development server and use IIS. I have never seen the VS development server being used for WCF. It's either been IIS or WCF service was switched between TCP/IP for code development and testing on the development machine. And then the WCF service was switched to use IIS when deployed to Test and Production servers.

    Wednesday, March 13, 2013 3:49 PM
  • technically, it is an automated load test, using the visual studio unit test framework.

    I did fear that this could be the recommended solution. I don't really want to go the full IIS server approach because it would involve extra complexity in the automation.  My original plan was to just run the WCF service in a console host, but i haven't figured out an easy method to include the startup/shutdown of the service in the automation.  

    I think what i may have to do is simply host the WCF service within the automated test process. I've never tried that before so i'm not sure if that would work (or if it is even recommended).

    The reason for initially using the dev server is that the setup is negligible and the ability to step into the WCF service for debugging the automated tests.

    Wednesday, March 13, 2013 3:57 PM
  • On 3/13/2013 11:57 AM, Pat Sissons wrote:

    technically, it is an automated load test, using the visual studio unit test framework.

    I did fear that this could be the recommended solution. I don't really want to go the full IIS server approach because it would involve extra complexity in the automation.  My original plan was to just run the WCF service in a console host, but i haven't figured out an easy method to include the startup/shutdown of the service in the automation.

    So why not make the development and auto build testing use WCF over TCP/IP? it's just matter of using app.config as opposed to a Web.config.


    I think what i may have to do is simply host the WCF service within the automated test process. I've never tried that before so i'm not sure if that would work (or if it is even recommended).

    I think the above is what most shops would do.


    The reason for initially using the dev server is that the setup is negligible and the ability to step into the WCF service for debugging the automated tests.

    Well why do that? If you put the BLL and DAL behind the WCF service, then you can test the BLL and DAL without involving WCF. WCF is just a pass through in that type of design of sending and receiving data, which is really what WCF is about.

    If you were to look at Web Service Factory 2010 as an example, you will see that the BLL and DAL are setting behind the WCF service.

    With the BLL and DAL sitting behind the WCF service, then you can test the BLL and DAL for automated unit and integration testing. Frankly, I have never see anyone test the Web service on the client-side as the WCF service is mocked out in unit testing.

    And no one that I have seen tests the WCF service in a auto integration testing in a build process. One has to assum that every thing is tested in front of the WCF service and behind the WCF service, as the WCF service is just a pass-through.  The integration and unit testing should be based on the BLL and DAL, and not the WCF service.

    Wednesday, March 13, 2013 4:34 PM
  • Haha, so the load tests i am speaking of are specifically designed to confirm that WCF (and really, also on IIS) can handle the load. These are not supposed to be testing any business logic. The *real* unit tests do not make use of WCF, and simply test the actual functions.
    Wednesday, March 13, 2013 4:43 PM
  • On 3/13/2013 12:43 PM, Pat Sissons wrote:

    Haha, so the load tests i am speaking of are specifically designed to confirm that WCF (and really, also on IIS) can handle the load. These are not supposed to be testing any business logic. The real unit tests do not make use of WCF, and simply test the actual functions.

    You have to assume that WCF and IIS can handle the load, but you can test it by just making a classlib test project and testing the WCF service with IIS as a test-harness.

    About the only problem you would have is if the WCF settings are not sufficient to handle large loads. However, you'll have to look at can the server itself (the machine) can it handle the load and not IIS and WCF per say.

    <http://www.codeproject.com/Articles/133738/Quick-Ways-to-Boost-Performance-and-Scalability-of>

    <http://www.codeproject.com/Articles/186233/Utilize-gzip-compression-in-IIS>  You can find other articles concerning the above. Maybe you test it once or as need be.  But to do it in some kind of a auto build process?
     MS VS Unit Testing will not be able to host the classlib that is consuming a WCF Web service, but Reshape can do it with debugging and the whole 9 yards.

    Wednesday, March 13, 2013 6:00 PM