Уменьшает ли развертывание DLL в GAC использование памяти при совместном использовании более чем 100 веб-приложениями? - PullRequest
1 голос
/ 19 мая 2011

У меня есть приложение ASP.NET, размещенное для многих доменов, и все они сопоставлены с одной и той же корневой папкой, то есть с базой кода.Будет ли меньше памяти, если я загружу библиотеки DLL, в настоящее время расположенные в папке bin, в GAC?Какие-либо особые соображения по поводу кода, которые необходимо предпринять для загрузки библиотек DLL в GAC для совместного использования (кроме аспектов безопасности)?

Есть ли способ сделать библиотеки DLL доступными для совместного использования в среде .NET?

Спасибо

Kris

Ответы [ 3 ]

3 голосов
/ 19 мая 2011

Размещение DLL в GAC не поможет с использованием памяти.Библиотеки DLL по-прежнему должны быть загружены в каждый домен приложения, и они не будут находиться в общей памяти.

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

0 голосов
/ 11 октября 2018

На самом деле, принятый ответ от @Oded и другой от @LarsTruijens оба
неверен. Размещение сборок в GAC DOES помогает уменьшить использование памяти.

Это подтверждается Джеффри Рихтером (из Wintellect, который помогал разрабатывать CLR с командой .NET) в своей книге CLR через C # :

Установка сборок в GAC дает несколько преимуществ. GAC позволяет многим приложениям совместно использовать сборки, сокращая использование физической памяти в целом ....

Это также подтверждает Тесс Феррандез (Гуру памяти и производительности от Microsoft - https://blogs.msdn.microsoft.com/tess/2006/04/12/asp-net-memory-you-use-the-same-dll-in-multiple-applications-is-it-really-necessary-to-load-it-multiple-times).

По возможности строгое имя и установка в глобальный кэш сборок (GAC) любых сборок, которые используются более чем одним приложением ASP.NET. Это уменьшит потребление памяти.

Я также подтвердил это сам, протестировав (WinDbg, Task Manager и ProcExplorer) в качестве службы x64 WebAPI. Вы увидите, что частный рабочий набор ниже с приложением GAC'd. В случае с NGen вы снова увидите, что частный рабочий набор уменьшился. Тем не менее, ошибки страниц также значительно уменьшены в приложении NGen'd по сравнению с базовой линией (почти вдвое в моем тесте). Я не видел разницы в Page Faults между приложением GAC и приложением, не относящимся к GAC.

Обратите внимание, что в некоторых случаях наилучшим решением является объединение NGen и GAC путем установки сборок NGen'd в GAC. Это оптимизирует использование памяти между приложениями, которые совместно используют сборки, а также обеспечивает повышение производительности при запуске приложения!

0 голосов
/ 18 сентября 2014

Как Одед объяснил , просто поместить их в GAC не поможет. Что может помочь, это поместить их в GAC и NGEN. Смотрите здесь и здесь . Обязательно измерьте различное использование памяти, время загрузки и общую производительность, поскольку NGEN может оказать на них негативное влияние. См. здесь и здесь .

...