Performance analysis of IPipelineBehavior for validation

[arslanaybars]

I use IPipelineBehavior with FluentValidation for validating my requests.

Most of us probably already use ValidationBehavior like CleanArchitecture sample

But when I made a load test. I can receive three times as many responses without this pipeline behavior.

Example:

With IPipelineBehavior

Without IPipelineBehavior

I used k6 for load testing.

Is this expected result or are there any suggestions to make it better?

Here is my ValidationBehavior class

public class ValidationBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
    where TRequest : IRequest<TResponse>
{
    private readonly IEnumerable<IValidator<TRequest>> _validators;

    public ValidationBehavior(IEnumerable<IValidator<TRequest>> validators)
    {
        _validators = validators;
    }

    public async Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next)
    {
        if (!_validators.Any())
        {
            return await next();
        }
        
        var context = new ValidationContext<TRequest>(request);

        var validationResults = await Task.WhenAll(
            _validators.Select(v => v.ValidateAsync(context, cancellationToken)));
                
        var failures = validationResults
            .SelectMany(r => r.Errors)
            .Where(f => f != null)
            .ToArray();

        if (failures.Any())
        {
            throw new ValidationException(failures);
        }

        return await next();
    }
}

[neozhu]

try this, do not use await

public  Task<TResponse> Handle(TRequest request, RequestHandlerDelegate<TResponse> next, CancellationToken cancellationToken)
    {
        var context = new ValidationContext<TRequest>(request);
        var failrules = _validators
            .Select(validator => validator.Validate(context))
            .SelectMany(result => result.Errors)
            .Where(failrules => failrules != null)
            .ToList();
        if (failrules.Count != 0)
        {
            throw new ValidationException(failrules);
        }
        return next();
    }

[arslanaybars]

@neozhu I tried but it doesn't affect with a big difference

[kentaasvang]

If you're throwing a lot of exceptions during your stress-test than I would suspect that to be the culprit

[arslanaybars]

I made the test in the happy path case so it means I don't throw any exceptions. 🤔

[PeterKneale]

What work is actually being performed in your handler? At just 3ms i'd be curious if you are actually reading / writing anything out of process.

I did a quick investigation into the perf impact of using something similar for both validation and logging some time back but after benchmarking found that if my handler was performing an out of process action like reading or writing to a database, cache or filesystem then the impact of the pipeline components was almost imperceptable compared to the overall duration (ie XXms for handler and XXXus for the pipeline).

This is inline with what Jimmy says more succintly here:
https://jimmybogard.com/you-probably-dont-need-to-worry-about-mediatr/

My handlers always hit a database or something, so anything MediatR does is a drop in the bucket

[jbogard]

See #828 , it might help with this as I won't register the built-in behaviors if they're not needed

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stalled for 14 days with no activity.