Стоит ли заменять Ninject по соображениям производительности?

У меня есть веб-приложение ASP.NET MVC/WebApi разумного размера (~ 100KLOCS), которое немного скрипит под нагрузкой (около 1MM запросов/день). Например, для загрузки обычно требуется 2-3 секунды, что неплохо от оптимального. Поскольку я начал оглядываться по поводу возможных узких мест, я не могу не заметить, что Ninject, мой контейнер IOC, считается самым медленным по очень здоровому краю:

http://www.palmmedia.de/Blog/2011/8/30/ioc-container-benchmark-performance-comparison https://github.com/ninject/ninject/issues/84

Кто-нибудь еще был в этом положении и попытался заменить Ninject на что-то еще, например LightInject, SimpleInject, или что-то в этом роде? Это стоило усилий? Ninject, кажется, самый популярный, с большим количеством поддержки сообществ и фреймворков, и я вовсе не хочу, чтобы я сам потупил проект, который в конечном итоге будет неподдерживаться. Кроме того, я не уверен, как проверить, будет ли в приложении реального мира производительность контейнера IOC даже замечена.

У кого-нибудь есть реальные истории или шрамы, которые стоит разделить? Или предложения о том, как определить, является ли Ninject узким местом?

Ответ 1

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

Это очень выгодно. Когда я работаю с клиентом, где гибкость и расширяемость являются ключевыми, обычно внутренняя линия бизнес-приложений, я использую Ninject. Когда я работаю над небольшими сфокусированными компонентами, где производительность является ключевой, например, внешние внешние веб-службы с большим объемом, я использую что-то более быстрое, например SimpleInjector. Тем не менее, я снова и снова обнаружил, что мне не хватает, когда мне нужно сделать что-то более продвинутое и в конечном итоге заменить его. Однако, когда я адаптирую свои методологии к подходу, основанному на микро-сервисе, я стал больше ценить в меньших рамках.

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

Ответ 2

"Стоит этого" может быть решено только вами. У вас есть профайлер на вашем сайте, чтобы узнать, где наихудшие узкие места? Возможно, даже Ниндег не будет вашим худшим преступником.

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

SimpleInjector вряд ли скоро будет прекращен, так как основным разработчиком является известный парень.

StructureMap - еще один хороший выбор, хотя он в середине пакета в производительности, он хорошо поддерживается и имеет хорошее сообщество.

Ответ 3

Любой, кто снова заходит по этому вопросу, может попробовать и DryIoC. Производительность ближе к SimpleInjector, но немного более расширяемая. MS на самом деле использует его для нескольких своих внутренних служб, например, Azure Durable.