“Нагрейте Кэш” на развертывании
Сначала попробуйте понять, как работает строка Connection Entity Framework, вы получите представление о том, что не так.
- У вас есть две разные модели: Entity и ModEntity
- означает, что у вас есть два разных контекста, каждый контекст имеет свою собственную модель хранилища, концептуальную модель и сопоставление между ними.
- . Вы просто комбинировали строки, но как контекст Entity будет знать, что он должен воспринимать entity.csdl и ModEntity будет pickup modentity.csdl? Ну, кто-то может написать какой-то интеллектуальный код, но я не думаю, что это основная роль команды разработчиков EF.
- Также machine.config - плохая идея.
- Если веб-приложения перемещаются на другую машину , или в общедоступную среду хостинга или для целей обслуживания, это может привести к проблемам.
- Каждый сможет получить к нему доступ, вы делаете его небезопасным. Если кто-либо может развернуть веб-приложение или любое приложение .NET на сервере, он получит полный доступ к вашей строке подключения, включая информацию о вашем конфиденциальном пароле.
Другой альтернативой является создание собственного конструктора для вашего контекста и передайте свою собственную строку соединения, и вы можете написать какое-либо условие if и т. д., чтобы загрузить значения по умолчанию из web.config
. Лучше всего было бы сделать, оставить строки соединения как есть, предоставить пул приложений идентификатор, который будет иметь доступ к вашему серверу базы данных и не включать имя пользователя и пароль в строку подключения.
4 ответа
Я установил интеграционные тесты, которые подтверждают, что все основные области сайта доступны (несколько сотен страниц всего). Они не делают ничего, что изменяется, данные - просто задерживают страницы и формы.
я в настоящее время не выполняю их, когда я развертываю свой производственный экземпляр, но теперь Вы упоминаете это - это может на самом деле быть хорошая идея.
Другая альтернатива должна была бы вытянуть каждую страницу, которая появляется в Вашей карте сайта (если Вы имеете один, который Вы, вероятно, должны). Должно быть действительно легко записать драгоценный камень / сценарий граблей, который делает это.
Вы могли использовать wget или другая программа пауку сайт. На самом деле этот вид сценария упоминается как одно из использования в его странице руководства:
Эта опция говорит Wget удалять каждый файл, который это загружает, сделав так. Это полезно для упреждающей выборки популярного, пролистывает прокси, например:
wget -r -nd --delete-after http://whatever.com/~popular/page/-r опция состоит в том, чтобы получить рекурсивно, и - без обозначения даты для не создания каталогов.
Preloading this way -- generally, with a cron job to start at 10pm Pacific to and terminate at 6am Eastern time -- is a nice way to load-balance your site.
Check out the spider_test rails plugin for a simple way to do this in testing.
If you're going to use the wget above, add the --level=, --no-parent, --wait=SECONDS and --waitretry=SECONDS options to throttle your load, and you might as well log and capture the header responses for diagnosis or analysis (change the path from /tmp if desired):
wget -r --level=5 --no-parent --delete-after \
--wait=2 --waitretry=10 \
--server-response \
--append-output=/tmp/spidering-`date "+%Y%m%d"`.log
'http://whatever.com/~popular/page/'
Я использую задачу rake, которая выглядит примерно так, чтобы обновить мою кэшированную карту сайта каждую ночь:
require 'action_controller/integration'
ActionController::Base::expire_page("/sitemap.xml")
app = ActionController::Integration::Session.new
app.host = "notexample.com"
app.get("/sitemap.xml")