Хотя вы не предоставили общий доступ к соответствующему фрагменту кода, но, судя по описанию и симптомам, это результат синхронного (блокирующего) ввода-вывода, выполненного где-то в вашем коде, что вызывает конфликты потоков.

ОБНОВЛЯТЬ: В вашем общем коде я вижу вызов синхронизации ввода-вывода, например, в методах GetValidFunction и Get. Должно быть, как показано ниже, и вызывающий абонент должен ждать. Помните, полностью асинхронно.

public Task<T> GetAsync(Expression<Func<T, bool>> where)
    {
        return dbset.Where(where).FirstOrDefaultAsync();
    }

Ниже будет очень общий ответ на эту проблему, в основном полученный из антипаттерна синхронного ввода-вывода . Некоторые ссылки на старое приложение asp.net и старую облачную службу ниже могут быть устаревшими сегодня, но концепция по-прежнему актуальна.

Антипаттерн синхронного ввода/вывода

Блокировка вызывающего потока во время завершения ввода-вывода может снизить производительность и повлиять на вертикальную масштабируемость.

Описание проблемы

Синхронная операция ввода-вывода блокирует вызывающий поток, пока ввод-вывод завершается. Вызывающий поток переходит в состояние ожидания и не может выполнять полезную работу в течение этого интервала, тратя впустую ресурсы обработки.

Общие примеры ввода/вывода включают:

• Получение или сохранение данных в базе данных или постоянном хранилище любого типа.
• Отправка запроса веб-сервису.
• Публикация сообщения или извлечение сообщения из очереди.
• Запись или чтение из локального файла.

Этот антипаттерн обычно возникает потому, что:

• Это кажется наиболее интуитивным способом выполнения операции.
• Приложение требует ответа на запрос.
• Приложение использует библиотеку, которая предоставляет только синхронные методы ввода-вывода.
• Внешняя библиотека выполняет внутренние синхронные операции ввода-вывода. Один синхронный вызов ввода-вывода может заблокировать всю цепочку вызовов.

Следующий код отправляет файл в хранилище BLOB-объектов Azure. Есть два места, где кодовые блоки ожидают синхронного ввода-вывода, метод CreateIfNotExists и метод UploadFromStream.

var blobClient = storageAccount.CreateCloudBlobClient();
var container = blobClient.GetContainerReference("uploadedfiles");

container.CreateIfNotExists();
var blockBlob = container.GetBlockBlobReference("myblob");

// Create or overwrite the "myblob" blob with contents from a local file.
using (var fileStream = File.OpenRead(HostingEnvironment.MapPath("~/FileToUpload.txt")))
{
    blockBlob.UploadFromStream(fileStream);
}

Вот пример ожидания ответа от внешней службы. Метод GetUserProfile вызывает удаленную службу, которая возвращает UserProfile.

public interface IUserProfileService
{
    UserProfile GetUserProfile();
}

public class SyncController : ApiController
{
    private readonly IUserProfileService _userProfileService;

    public SyncController()
    {
        _userProfileService = new FakeUserProfileService();
    }

    // This is a synchronous method that calls the synchronous GetUserProfile method.
    public UserProfile GetUserProfile()
    {
        return _userProfileService.GetUserProfile();
    }
}

Вы можете найти полный код для обоих этих примеров здесь.

Как решить проблему

Замените синхронные операции ввода-вывода асинхронными операциями. Это освобождает текущий поток для продолжения выполнения значимой работы, а не блокировки, и помогает улучшить использование вычислительных ресурсов. Асинхронный ввод-вывод особенно эффективен для обработки неожиданного всплеска запросов от клиентских приложений.

Многие библиотеки предоставляют как синхронные, так и асинхронные версии методов. По возможности используйте асинхронные версии. Вот асинхронная версия предыдущего примера, которая отправляет файл в хранилище BLOB-объектов Azure.

var blobClient = storageAccount.CreateCloudBlobClient();
var container = blobClient.GetContainerReference("uploadedfiles");

await container.CreateIfNotExistsAsync();

var blockBlob = container.GetBlockBlobReference("myblob");

// Create or overwrite the "myblob" blob with contents from a local file.
using (var fileStream = File.OpenRead(HostingEnvironment.MapPath("~/FileToUpload.txt")))
{
    await blockBlob.UploadFromStreamAsync(fileStream);
}

Оператор await возвращает управление вызывающей среде во время выполнения асинхронной операции. Код после этого оператора действует как продолжение, которое запускается после завершения асинхронной операции.

Хорошо спроектированная служба должна также обеспечивать асинхронные операции. Вот асинхронная версия веб-службы, которая возвращает профили пользователей. Метод GetUserProfileAsync зависит от наличия асинхронной версии службы профилей пользователей.

public interface IUserProfileService
{
    Task<UserProfile> GetUserProfileAsync();
}

public class AsyncController : ApiController
{
    private readonly IUserProfileService _userProfileService;

    public AsyncController()
    {
        _userProfileService = new FakeUserProfileService();
    }

    // This is an synchronous method that calls the Task based GetUserProfileAsync method.
    public Task<UserProfile> GetUserProfileAsync()
    {
        return _userProfileService.GetUserProfileAsync();
    }
}

Для библиотек, которые не предоставляют асинхронные версии операций, возможно создание асинхронных оболочек вокруг выбранных синхронных методов. Следуйте этому подходу с осторожностью. Хотя это может улучшить реакцию потока, который вызывает асинхронную оболочку, на самом деле он потребляет больше ресурсов. Может быть создан дополнительный поток, и накладные расходы связаны с синхронизацией работы, выполняемой этим потоком. Некоторые компромиссы обсуждаются в этой записи блога: Должен ли я предоставлять асинхронные оболочки для синхронных методов?

Вот пример асинхронной оболочки вокруг синхронного метода.

// Asynchronous wrapper around synchronous library method
private async Task<int> LibraryIOOperationAsync()
{
    return await Task.Run(() => LibraryIOOperation());
}

Теперь вызывающий код может ожидать в оболочке:

// Invoke the asynchronous wrapper using a task
await LibraryIOOperationAsync();

Соображения

• Операции ввода-вывода, которые, как ожидается, будут очень короткими и вряд ли вызовут конкуренцию, могут быть более производительными, чем синхронные операции. Примером может быть чтение небольших файлов на SSD-накопителе. Накладные расходы на отправку задачи в другой поток и синхронизацию с этим потоком после завершения задачи могут перевесить преимущества асинхронного ввода-вывода. Однако такие случаи относительно редки, и большинство операций ввода-вывода следует выполнять асинхронно.

• Повышение производительности ввода-вывода может привести к тому, что другие части системы станут узкими местами. Например, разблокировка потоков может привести к увеличению объема одновременных запросов к общим ресурсам, что, в свою очередь, приведет к нехватке ресурсов или регулированию. Если это становится проблемой, вам может потребоваться увеличить количество веб-серверов или разделов хранилищ данных, чтобы уменьшить конкуренцию.

Как обнаружить проблему

Для пользователей приложение может периодически переставать отвечать. Приложение может завершиться ошибкой из-за тайм-аута. Эти сбои также могут возвращать ошибки HTTP 500 (внутренний сервер). На сервере входящие клиентские запросы могут блокироваться до тех пор, пока поток не станет доступным, что приводит к чрезмерной длине очереди запросов, что проявляется в виде ошибок HTTP 503 (служба недоступна).

Вы можете выполнить следующие шаги, чтобы определить проблему:

1. Отслеживайте производственную систему и определяйте, ограничивают ли пропускную способность заблокированные рабочие потоки.

2. Если запросы блокируются из-за отсутствия потоков, проверьте приложение, чтобы определить, какие операции могут выполнять ввод-вывод синхронно.

3. Выполните контролируемое нагрузочное тестирование каждой операции, выполняющей синхронный ввод-вывод, чтобы выяснить, влияют ли эти операции на производительность системы.

Пример диагностики

В следующих разделах эти шаги применяются к примеру приложения, описанному ранее.

Отслеживание производительности веб-сервера

Для веб-приложений и веб-ролей Azure стоит отслеживать производительность веб-сервера IIS. В частности, обратите внимание на длину очереди запросов, чтобы определить, блокируются ли запросы в ожидании доступных потоков в периоды высокой активности. Вы можете собрать эту информацию, включив диагностику Azure. Для получения дополнительной информации см.:

• Мониторинг приложений в службе приложений Azure
• Создавайте и используйте счетчики производительности в приложении Azure

Инструментируйте приложение, чтобы увидеть, как обрабатываются запросы после их принятия. Отслеживание потока запроса может помочь определить, выполняет ли он медленные вызовы и блокирует ли текущий поток. Профилирование потоков также может выделять заблокированные запросы.

Нагрузочное тестирование приложения

На следующем графике показана производительность синхронного метода GetUserProfile, показанного ранее, при различных нагрузках до 4000 одновременных пользователей. Приложение представляет собой приложение ASP.NET, работающее в веб-роли облачной службы Azure.

Синхронная операция жестко запрограммирована на 2 секунды бездействия, чтобы имитировать синхронный ввод-вывод, поэтому минимальное время отклика составляет чуть более 2 секунд. Когда нагрузка достигает примерно 2500 одновременных пользователей, среднее время отклика выходит на плато, хотя объем запросов в секунду продолжает увеличиваться. Обратите внимание, что шкала для этих двух показателей является логарифмической. Между этой точкой и окончанием теста количество запросов в секунду удваивается.

В отдельности из этого теста не обязательно ясно, является ли синхронный ввод-вывод проблемой. При более высокой нагрузке приложение может достичь критической точки, когда веб-сервер больше не может своевременно обрабатывать запросы, что приводит к тому, что клиентские приложения получают исключения из-за тайм-аута.

Входящие запросы ставятся в очередь веб-сервером IIS и передаются потоку, работающему в пуле потоков ASP.NET. Поскольку каждая операция выполняет ввод-вывод синхронно, поток блокируется до завершения операции. По мере увеличения рабочей нагрузки в конечном итоге все потоки ASP.NET в пуле потоков выделяются и блокируются. В этот момент любые дальнейшие входящие запросы должны ждать в очереди доступного потока. По мере увеличения длины очереди запросы начинают истекать по тайм-ауту.

Реализовать решение и проверить результат

На следующем графике показаны результаты нагрузочного тестирования асинхронной версии кода.

Пропускная способность гораздо выше. За ту же продолжительность, что и в предыдущем тесте, система успешно справляется с почти десятикратным увеличением пропускной способности, измеряемой в запросах в секунду. Более того, среднее время отклика остается относительно постоянным и примерно в 25 раз меньше, чем в предыдущем тесте.