У нас есть несколько OData API, использующих Entity Framework и AutoMapper.Они подключаются к локальной базе данных SQL через виртуальную сеть.GET-запросы этого API не являются асинхронными для каждого найденного примера здесь .Масштабирование установлено на S2.Мы всегда включали.
Иногда запросы выполняются за 500 мс.Иногда одни и те же запросы занимают 40 секунд.Мы пытались уменьшить масштаб, но это не дает ощутимой выгоды.Мы попытались сделать функцию GET на контроллерах асинхронной.Мы попытались отключить аутентификацию.Мы попытались посмотреть на стек вызовов приложений в приложении Profiler, но иногда код зависает при одном вызове, а другой - при другом.Мы даже нашли 39-секундный вызов String.Replace ().Мы попробовали Kudu, но, похоже, не можем получить от него никаких знаний.
Кроме того, мне одному удается поднять сервер на колени, просто спамом F5 по относительно простому запросу, блокирующим процессорна 100%.S2 кажется довольно высоким, и мы ошеломлены тем, что сервер, очевидно, не может справиться с этим.И это также не всегда тот случай, когда низкая загрузка ЦП на сервере равняется быстрым запросам.Иногда эти запросы также занимают необычайное количество времени.
Мы пытались посмотреть на данные аналитики приложения, но становимся все более запутанными, поскольку некоторые данные предполагают, что одна вещь виновата, а другие - нет.
Высокая загрузка ЦП в плане обслуживания приложения.
Загрузка ЦП в динамических показателях обычно остается низкой.
Это говорит о том, что виноват SQL.Но мы почти исключили это, поскольку, если мы рассылаем спам по API в одном плане обслуживания приложения и отправляем один и тот же запрос в другой план обслуживания приложения, мы немедленно получаем результат.
Это говорит о том, что код или сервер неисправен.
Как мы можем диагностировать эту проблему и найти узкое место?