Увеличение скорости за счет использования глобального кэша сборок - PullRequest
Новая
       36

Увеличение скорости за счет использования глобального кэша сборок

3 голосов
/ 03 июня 2009

Если бы у меня было по 1000 сайтов asp.net, каждый из которых содержал 30 DLL в своих папках / bin.

Поэтому 30 000 DLL.

Будут ли веб-сайты / веб-сервер / машина работать быстрее, если я зарегистрирую один набор библиотек DLL в глобальном кэше сборок и каждый сайт будет использовать библиотеки DLL в GAC?

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

Ответы [ 3 ]

7 голосов
/ 03 июня 2009

Даже если сборки находятся в GAC, они все равно будут загружаться оттуда в память отдельно для обеспечения изоляции. Другими словами, то, что сборки находятся в GAC, не означает, что эти копии являются общими для доменов приложений. Я полагаю, что mscorlib (и, возможно, несколько сборок BCL) могут быть общими для доменов приложений, но любые сборки, которые вы или я напишете, не будут.

Однако это хорошо: рассмотрите последствия использования типа Cache для всех доменов приложений.

1 голос
/ 03 июня 2009

На самом деле это будет намного быстрее, особенно если они тоже NGEN. Если вы выполняете NGEN, не помещая их в глобальный кэш сборок, вы на самом деле замедляете работу, поскольку CLR потребуется выполнить проверку сборки, чтобы убедиться, что она соответствует собственному образу. CLR пропускает эту проверку для сборок GAC и просто загружает и использует собственный образ.

Существуют также преимущества памяти для сборок NGEN, поскольку они могут совместно использовать кодовые страницы.

Вы также можете попытаться оптимизировать базовые адреса библиотек DLL, потому что, если все они используют значение по умолчанию, Windows необходимо перебазировать 30000 раз!

Вот отличная статья о преимуществах производительности NGEN.

http://msdn.microsoft.com/en-us/magazine/cc163610.aspx

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

На самом деле принятый ответ от @AndrewHare неверен. Размещение сборок в 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. Это оптимизирует использование памяти между приложениями, которые совместно используют сборки, а также обеспечивает повышение производительности при запуске приложения!

...