Комментарии 9
Подскажите, можно ли какой-то из этих сценариев применить следующей ситуации: есть множество webapi сайтов-субдоменов (сейчас это независимые сайты и апппулы). Но они отличаются ТОЛЬКО значениями переменных в web.config (connectionString к БД и путь к логам и еще несколько переменных). А dll сборки я копипастю одинаковые во все сайты-папки. Поэтому хочется, чтобы bin папка была одна по сути, а субдомены цепляли свой персональный web.config
Как раз в Вашем случае эффект будет максимальный, так как переиспользуются одни и те же сборки.
Вы можете менять конфигурацию последовательно, оценивая вклад оптимизации на каждом шаге.
загрузка подписанных сборок в GAC
объединение сайтов в applicationPools
создание нативных образов для загруженных в GAC сборок
Поэтому хочется, чтобы bin папка была одна по сути, а субдомены цепляли свой персональный web.config
Касательно деплоя приложений: если содержимое папок bin ничем не отличается и вы не хотите каждый раз руками копировать недостающие сборки в папку bin, то самое простое это сделать symbol link через команду mklink.
1) деплой приложения
2) помещать сборки в GAC
3) создание нативных образов для загруженных в GAC сборок
я правильно понял?
Процесс деплоя менять не нужно. Идея состоит в том, чтобы придерживаться одного и того же номера версий сборок в своих сервисах, например:
- AutoMapper 6.1.0
… - Microsoft.AspNet.WebApi.Client 5.2.3
- Newtonsoft.Json 9.0.1
За счет этого и будет достигнут sharing между пулами и процессами. Однако если конкретному сервису потребуется специфичная версия, она будет загружена в специфичный домен и просто не будет шаринга.
Периодически нужно анализировать используемые сборки и помещать их в GAC
Можно что то подобное проделать используя Linux в качестве сервера ?
Есть ли в планах повторить эксперимент применимо к .NET Core?
Приложения написанные на .NET Core занимают значительно меньше оперативной памяти, в сравнении с .NET Framework и скорее всего такого выигрыша по памяти и CPU просто не будет (нет большого смысла оптимизировать память, когда сервис занимает 60 мб).
На stackoverflow есть интересный ответ на эту тему
Somewhat analogous to the GAC, .NET Core 2.0 introduces the "Runtime package store":
Sharing общих сборок между процессами и доменами в IIS