Приложение хостится в AZURE. Запрос может выполняться 4-8 секунд (смотрю в браузере), хотя там нечему тормозить. Но всё-таки тормозит.

Как правильно собирать инфу? Вручную - понятно. Напихать в ответ timestamp-ов с пояснениями и изучать их уже на клиенте.

Ну а по взрослому?

hVostt скорее всего отдельные запросы к БД.

Там запросов то...

Когда сервер в азуре - всё еле шевелится. Если сервер у меня на машине (БД всё также в АЗУРЕ) - всё летает - не удержишь.

hVosttАгнец за бортомКогда сервер в азуре - всё еле шевелится.

Возможные проблемы низкой производительности:

- слабый канал
- отдельные медленные запросы
- большое количество маленьких запросов (SELECT N+1), обычно итог неправильной работы с ORM, при чём локально это может не всплывать, так как тестовых данных мало и БД лежит там же, где и само приложение, но при развёртывании проблема становится сильно ощутимой
- мало памяти
- мало процессорных ресурсов

БД не тестовая, а рабочая. Мне много тут накидали советов - буду смотреть, о результатах сообщу. Странно это всё, конечно.

Application Insight предложил мне внедрить какие-то SDK в мою апу. Какой-то перебор.

Но я наткнулся на Query DB Insight - рульная штука. Нашел запрос, который клал всю базу на лопатки и еще сверху на неё садился - всё залетало после переписывания оного.

Но.

Вопросы остались.

Как узнать:

1. Какие методы дергаются чаще всего?
2. Какие методы сильнее всех "отжирают" ресурсы (чтобы это не значило)
3. У запроса-поганца есть ID - как узнать - из какого метода сервиса он хотя бы пришел. Текст то я вижу, но искать его можно в куче мест.

И общий вопрос - а сколько у меня вообще ресурсов?



Вот у меня один запрос в секунду, выполняется 10ms. Это ок?
А если таких 50 000? Не ок?
А 500 000?

Как увидеть очередь к бд/сервису?

Ползунок в Азуре двигать проще всего.

На эти вопросы App Insight даст ответ? Библиотеки в приложение "вживлять" обязательно?