Ninject и производительность - PullRequest
Новая
       0

Ninject и производительность

8 голосов
/ 18 апреля 2011

Я делаю обзор кода на веб-сайте, на котором будет много одновременных пользователей, ок.100 000 аутентифицированных пользователей.

Я нашел следующий код типа: 

    [Inject]
    public BusinessLayer.ILoginManager LoginManager { get; set; }

И в global.asax.cs: 

   protected Ninject.IKernel CreateKernel()
    {
        return new StandardKernel(new ServiceModule());
    }


    internal class ServiceModule : NinjectModule
    {

        public override void Load()
        {
             Kernel.Bind<IReportProxy>().To<ReportProxy>().InRequestScope();
        }
    }

Вопрос:использование Ninject влияет на производительность?В каких ситуациях вам не следует использовать Ninject из-за производительности?

Ответы [ 3 ]

7 голосов
/ 18 апреля 2011

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

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

3 голосов
/ 15 апреля 2015

Ninject вызвал у нас большое горе от работы над проектом.Это один из самых медленных DI, и я настоятельно рекомендую рассмотреть другой механизм DI (например, https://github.com/ninject/ninject/issues/84)

Несколько других замечаний о Ninject:

  1. Unbind / Rebind не являются потокобезопасными (AFAIK нигде не указан в xmldocs). Симптом: периодически вы можете потерять некоторые привязок из-за дублирования ключа во внутреннем словаре Kenrel.

  2. Ссылка на объект пользовательской области из целевого объекта привязки может привести к утечке памяти (на самом деле это разумно, но Ninject ни в коей мере не помогает в обнаружении проблемы).

Стоит также помнить, что переключение на другой DI может оказаться невозможным в зависимости от набора функций, который вы в конечном итоге будете использовать (например, местоположение службы, условные привязки, пользовательские области,динамические привязки и т. д.). Даже если другая структура DI имеет аналогичный набор функций (например, LightInject)синтаксис может быть слишком разным.

0 голосов
/ 22 марта 2018

Я наткнулся на этот вопрос, когда заметил, что внедрение свойства (через [Inject] и kernel.Inject(instance) в контроллере заняло около 3 секунд, что очень сильно задерживает обработку запросов для определенного контроллера. Большинство других контроллеровбыли затронуты в меньшей степени.

Короткий ответ

Да, Ninject явно приносит накладные расходы, но я обнаружил, что зависит от трех факторов: версия библиотеки, размер дерева зависимостейи как решается зависимость.

Стремитесь к большей версии (3.3.4+), убедитесь, что зависимость не вызывает много зависимостей, которые нужно решить, и что вы используете внедрение конструктора, а не внедрение свойства.

Длинный ответ

1. Схема внедрения - Я столкнулся с проблемами производительности при использовании инъекции свойства. Быстрый выигрыш состоял в том, чтобы заменить его prop => kernel.Get<IFoo>(), ноэтот шаблон не рекомендуется (3.3.4 помечает прямое использование ядра как устаревшее), однако он сокращает время, необходимое дляСсылка без проведения рефакторинга.

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

3.Версия библиотеки - Я обновил библиотеку с 3.2.0 до 3.3.4 и заметил значительное улучшение производительности.Однако я заплатил за множественные изменения внутри приложения (переход с NinjectWebCommon на MvcApplication и обновление различных библиотек, таких как Castle.Core, Ninject.MockingKernel, Ninject.MockingKernel.NSubstitute, Ninject.Web.Common.WebHost)

...