Currently I have a WCF data service that does some request validation in its OnStartProcessingRequest overload. When the request is deemed invalid, I currently throw a DataServiceException, and the service forwards the exception to the client as an HTTP status code. This works ok, except under heavy load with many "exceptional" requests. I'm finding that if I setup a load test with many successful requests (those returning 200 with some result data from a live database), it runs significantly faster than if I setup a load test with many unsuccessful requests (those returning 400, 404, etc..).
I would have expected the reverse to be true, given that the request should have been canceled before it was sent off to the data provider. Although the overhead is slight compared to the overall processing time of requests when you include the IO bound time, the difference in CPU-bound processing time is significant enough to be worrisome.
My current theory based on profiling is that the discrepancy comes from the DataServiceException throwing. Indeed even when I turn off all the validation code and simply throw the exception, the comparison from no-exception to with-exception is the same: exception requests are significantly slower when they should be as fast as or faster than successful requests. Perhaps this is due to the runtime inserting the stack trace, etc... into the exception?
If so, is there an alternative way of indicating that the request should fail with a particular status code, without actually throwing an exception (similar to what you might do in an HttpModule)? Setting the ProcessRequestArgs.OperationContext.StatusCode property has no effect. I know I could use an HttpModule underneath the data service, but then I would need to parse the bodies of batch requests in order to do my validation logic on each request in the batch, which would almost certainly be slower than the exception throwing version anyway.
Thanks!