Получение юзера. FindByIdAsync или SingleOrDefaultAsync

@Serg34 · Регистрация: 20.09.2014

Author24 — интернет-сервис помощи студентам

Добрый день!

Есть два способа получения юзера по идентификатору:

C#

1	var user = await _userManager.FindByIdAsync(id);

C#

1	var user = await _db.Users.AsNoTracking().SingleOrDefaultAsync(u => u.Id == id);

На всякий случай вот контроллер:

C#

public class HomeController : Controller
{
    public HomeController(ApplicationDbContext context, UserManager<ApplicationUser> userManager)
    {
        _db = context;
        _userManager = userManager;
    }
 
    private ApplicationDbContext _db;
    private UserManager<ApplicationUser> _userManager;
 
...
}

Какой из этих способов предпочтительнее и какой создает меньше нагрузку на процессор?

@Usaga · 20.07.2018, 10:45

Serg34, вы могли бы сами замерять)

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

А разница из этих двух подходов не очевидна, ибо не известно, что происходит в FindByIdAsync.

Добавлено через 6 минут
Но по-хорошему, разницы не должно быть. В методе FindByIdAsync может быть какая-то дополнительная логика или кеширование, но даже в этом случае, разница будет крошечно (если вообще будет заметна).

А вот корректность - вопрос уже другой. Если в FindByIdAsync действительно предусмотрена некая логика, то ходить мимо неё вы просто не имеете права.

@Serg34 · 20.07.2018, 10:57 **[ТС]**

Сообщение от Usaga

Serg34, вы могли бы сами замерять)

Да, но это будет всего лишь один замер))
Я если честно ожидал ответа вроде "Все зависит от ситуации. В одних случаях нужно так, в других так"

Сообщение от Usaga

Очень странно, что у вас есть два пути получения пользователя.

_userManager используется как минимум для получения активного пользователя:

C#

1	var user = await _userManager.GetUserAsync(User);

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

Сообщение от Usaga

А вот корректность - вопрос уже другой.

Да, думаю, надо FindByIdAsync использовать.

@Usaga · 20.07.2018, 11:02

Сообщение от Serg34

Да, но это будет всего лишь один замер))

Заверните вызов метода в цикл с парой тысяч итераций и замеров станет больше.

Добавлено через 38 секунд

Сообщение от Serg34

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

А второй способ, принимающий ID пользователя, такой возможности не даёт?)

@kolorotur · 20.07.2018, 11:05

Сообщение от Serg34

Какой из этих способов предпочтительнее и какой создает меньше нагрузку на процессор

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

P.S. Я предполагаю, что UserManager в кишках использует метод Find.

@Usaga · 20.07.2018, 11:09

Сообщение от kolorotur

Я предполагаю, что UserManager в кишках использует метод Find.

Но если контекст создаётся на каждый запрос, то кеш будет пуст.

@kolorotur · 20.07.2018, 11:12

Сообщение от Usaga

Но если контекст создаётся на каждый запрос, то кеш будет пуст.

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

@Serg34 · 20.07.2018, 11:21 **[ТС]**

Сообщение от Usaga

кеш будет пуст

А когда очищается кэш?

Сообщение от kolorotur

время жизни контроллера

А когда заканчивается жизнь контроллера? Когда пользователь переходит в метод другого контроллера?

@Usaga · 20.07.2018, 11:25

Сообщение от kolorotur

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

По-хорошему, нет. Один запрос - один вызов метода.

Сообщение от Serg34

А когда очищается кэш?

Кеш объектов хранится внутри контекста. Контекст создаётся на каждый запрос заново.

Сообщение от Serg34

А когда заканчивается жизнь контроллера?

Когда заканчивается обработка запроса.

@Serg34 · 20.07.2018, 16:22 **[ТС]**

Сообщение от Usaga

вы могли бы сами замерять)

Думаю, это будет интересно: у меня получилось примерно в тысячу раз разница:

Получение юзера. FindByIdAsync или SingleOrDefaultAsync

Пробовал еще при помощи профилировщика производительности мерять, но он явно врал: 8 против 1500 мс, и второй способ явно больше полутора секунд длился.
Или я что не так замерил...

@Usaga · 20.07.2018, 16:31

Serg34, значит метод FindByIdAsync кеширует запись и в базу ходит только один раз. Ещё учитывайте, что во втором случае создаётся делегат с лямбдой на каждой итерации, что тоже даёт некий оверхед накапливающийся с каждой итерацией.

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

Если вы испытываете проблемы с производительностью, то совершенно не там ищете причину.

@Serg34 · 20.07.2018, 16:51 **[ТС]**

Usaga, Да, проблемы с производительностью, наверно, больше связаны с кривыми руками

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

@Usaga · 20.07.2018, 16:55

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

А вы уже наблюдаете сумму этих задержек: работа CPU + ожидание данных от СУБД.

@Serg34 · 20.07.2018, 17:05 **[ТС]**

Usaga, перепутал: не профилировщик производительности, а сообщение справа от кода во время отладки.

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

@Usaga · 20.07.2018, 17:09

Serg34, да, эта штука просто замеряет время выполнения, не различая на что оно ушло.

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	20.07.2018, 16:55	13
	Serg34, смотря как и что вы им замеряли... Если речь о времени затрачиваемы CPU на ваше приложение, то имейте в виду, что операции ввода-вывода (сеть, диски, работа с железом) в показания профилировщика не попадают, ибо в это время ваше приложение ждёт и ничего не делает. А вы уже наблюдаете сумму этих задержек: работа CPU + ожидание данных от СУБД. 0

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	20.07.2018, 10:45	2
	Serg34, вы могли бы сами замерять) Очень странно, что у вас есть два пути получения пользователя. Если есть специальный сервис для работы с юзерами, то нужно работать через него, а не лезть в базу напрямую (вопрос здравого смысла, а не производительности). А разница из этих двух подходов не очевидна, ибо не известно, что происходит в `FindByIdAsync`. Добавлено через 6 минут Но по-хорошему, разницы не должно быть. В методе `FindByIdAsync` может быть какая-то дополнительная логика или кеширование, но даже в этом случае, разница будет крошечно (если вообще будет заметна). А вот корректность - вопрос уже другой. Если в `FindByIdAsync` действительно предусмотрена некая логика, то ходить мимо неё вы просто не имеете права. 1

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	20.07.2018, 11:02	4
	Сообщение от Serg34 Да, но это будет всего лишь один замер)) Заверните вызов метода в цикл с парой тысяч итераций и замеров станет больше. Добавлено через 38 секунд Сообщение от Serg34 Но и еще дает дополнительную возможность получения других пользователей... А второй способ, принимающий ID пользователя, такой возможности не даёт?) 0

@kolorotur 17688 / 12873 / 3366 Регистрация: 17.09.2011 Сообщений: 21,138
	20.07.2018, 11:05	5
	Сообщение от Serg34 Какой из этих способов предпочтительнее и какой создает меньше нагрузку на процессор Главное различие в том, что при использовании первого варианта запрос к базе будет произведен только в том случае, если в контексте уже не закэширован объект с эти Id (был загружен ранее). Во втором случае запрос к базе будет производиться в любом случае, то есть всегда будет получена свежая информация в рамках текущей транзакции. P.S. Я предполагаю, что UserManager в кишках использует метод Find. 2

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	20.07.2018, 11:09	6
	Сообщение от kolorotur Я предполагаю, что UserManager в кишках использует метод Find. Но если контекст создаётся на каждый запрос, то кеш будет пуст. 1

@kolorotur 17688 / 12873 / 3366 Регистрация: 17.09.2011 Сообщений: 21,138
	20.07.2018, 11:12	7
	Сообщение от Usaga Но если контекст создаётся на каждый запрос, то кеш будет пуст. Верно, но у ТСа контекст передаетя в конструктор контроллера и хранится в поле класса. Подозреваю, что он может быть использован многократно за время жизни контроллера. 1

@Serg34 100 / 100 / 33 Регистрация: 20.09.2014 Сообщений: 457 Записей в блоге: 3
	20.07.2018, 11:21 [ТС]	8
	Сообщение от Usaga кеш будет пуст А когда очищается кэш? Сообщение от kolorotur время жизни контроллера А когда заканчивается жизнь контроллера? Когда пользователь переходит в метод другого контроллера? 0

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	20.07.2018, 11:25	9
	Сообщение от kolorotur Подозреваю, что он может быть использован многократно за время жизни контроллера. По-хорошему, нет. Один запрос - один вызов метода. Сообщение от Serg34 А когда очищается кэш? Кеш объектов хранится внутри контекста. Контекст создаётся на каждый запрос заново. Сообщение от Serg34 А когда заканчивается жизнь контроллера? Когда заканчивается обработка запроса. 1

@Serg34 100 / 100 / 33 Регистрация: 20.09.2014 Сообщений: 457 Записей в блоге: 3
	20.07.2018, 16:22 [ТС]	10
	Сообщение от Usaga вы могли бы сами замерять) Думаю, это будет интересно: у меня получилось примерно в тысячу раз разница: Пробовал еще при помощи профилировщика производительности мерять, но он явно врал: 8 против 1500 мс, и второй способ явно больше полутора секунд длился. Или я что не так замерил... 0

@Usaga 12079 / 8388 / 1281 Регистрация: 21.01.2016 Сообщений: 31,601
	20.07.2018, 16:31	11
	Serg34, значит метод FindByIdAsync кеширует запись и в базу ходит только один раз. Ещё учитывайте, что во втором случае создаётся делегат с лямбдой на каждой итерации, что тоже даёт некий оверхед накапливающийся с каждой итерацией. Я рекомендую на париться замерами этих двух способов ибо между ними не будет разницы ровно никакой в реальной работе. Контекст будет создаваться заново на каждый запрос, соответственно кеш контекста бесполезен, а на создание делегата с лямбдой оходят микросекунды. Если вы испытываете проблемы с производительностью, то совершенно не там ищете причину. 0

@Serg34 100 / 100 / 33 Регистрация: 20.09.2014 Сообщений: 457 Записей в блоге: 3
	20.07.2018, 16:51 [ТС]	12
	Usaga, Да, проблемы с производительностью, наверно, больше связаны с кривыми руками. А сейчас я в общеобразовательных целях все это исследую. Про профилировщик было странно - почему он такие данные выдавал и можно ли ему верить... 0

	20.07.2018, 17:09

@Serg34 100 / 100 / 33 Регистрация: 20.09.2014 Сообщений: 457 Записей в блоге: 3
	20.07.2018, 17:05 [ТС]	14
	Usaga, перепутал: не профилировщик производительности, а сообщение справа от кода во время отладки. Насколько я понимаю, оно показывает именно время работы, включая всё, даже остановку выполнения. 0