Как «разогреть» Entity Framework? Когда становится «холодно»?

Нет, ответ на мой второй вопрос - не зима.

Предисловие:

В последнее время я проводил много исследований Entity Framework, и что-то, что меня беспокоит, - это его производительность, когда запросы не разогреваются, так называемые холодные запросы.

Я просмотрел статью о производительности для Entity Framework 5.0. Авторы представили концепцию теплых и холодных запросов и их различия, что я тоже заметил, не зная об их существовании. Здесь, наверное, стоит упомянуть, что за моей спиной всего полгода опыта.

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

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

Мы будем переходить на Windows Server 2012, IIS8 и SQL Server 2012, и, будучи младшим, я действительно получил возможность протестировать их раньше остальных. Я очень рад, что они представили модуль разминки, который подготовит мое приложение к этому первому запросу. Однако я не уверен, как продолжить разогрев Entity Framework.

То, что я уже знаю, стоит сделать:

• Создавайте мои просмотры заранее, как было предложено.
• Со временем перенесу свои модели в отдельную сборку.

Что я считаю своим делом, исходя из здравого смысла, вероятно, неправильным подходом :

• Выполнение фиктивных данных для чтения при запуске приложения, чтобы разогреть, сгенерировать и проверить модели.

Вопросы:

• Каков наилучший подход к обеспечению высокой доступности моей Entity Framework в любое время?
• В каких случаях Entity Framework снова становится "холодным"? (Перекомпиляция, повторное использование, перезапуск IIS и т. Д.)

• Каков наилучший подход к обеспечению высокой доступности моей Entity Framework в любое время?

Вы можете использовать сочетание предварительно созданных представлений и статических скомпилированных запросов.

Статические CompiledQuerys хороши тем, что их легко и быстро писать, и они помогают повысить производительность. Однако с EF5 нет необходимости компилировать все ваши запросы, поскольку EF автоматически компилирует запросы. Единственная проблема в том, что эти запросы могут потеряться при очистке кеша. Таким образом, вы по-прежнему хотите хранить ссылки на свои собственные скомпилированные запросы для тех, которые встречаются очень редко, но стоят дорого. Если вы поместите эти запросы в статические классы, они будут скомпилированы, когда они потребуются впервые. Это может быть слишком поздно для некоторых запросов, поэтому вы можете принудительно скомпилировать эти запросы во время запуска приложения.

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

Не используйте много наследования TPT (это общая проблема производительности в EF). Ни в коем случае не выстраивайте иерархию наследования слишком глубоко или слишком широко. Только 2-3 свойств, относящихся к некоторому классу, может быть недостаточно, чтобы требовать собственный тип, но их можно обрабатывать как необязательные (допускающие значение NULL) свойства для существующего типа.

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

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

• В каких случаях Entity Framework снова становится "холодным"? (Перекомпиляция, повторное использование, перезапуск IIS и т. Д.)

По сути, каждый раз, когда вы теряете свой AppDomain. IIS выполняет перезапуск каждые 29 часов , поэтому вы никогда не можете гарантировать наличие ваших экземпляров. Также после некоторого времени бездействия AppDomain также отключается. Вам следует снова попытаться быстро подняться. Возможно, вы можете выполнить некоторую инициализацию асинхронно (но остерегайтесь проблем с многопоточностью). Вы можете использовать запланированные задачи, которые вызывают фиктивные страницы в вашем приложении в периоды, когда нет запросов, чтобы предотвратить смерть AppDomain, но в конечном итоге это произойдет.

Я также предполагаю, что когда вы измените свой файл конфигурации или измените сборки, произойдет перезагрузка.

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

В общем, вы должны стремиться разрабатывать распределенные архитектуры, требующие запросов данных на основе ввода-вывода только тогда, когда локально кэшированная информация становится устаревшей или должна быть транзакционной. Любой запрос данных "по сети" обычно занимает в 10-1000 раз больше времени для получения, чем получение локального запроса в кэше памяти. Уже один этот факт часто делает обсуждение «холодных и теплых данных» несущественным по сравнению с вопросом «локальные или удаленные» данные.

Общие советы.

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

Теперь объясним, почему фиктивные запросы не являются неправильным подходом .

• Меньше сложности - вы разогреваете приложение таким образом, чтобы оно работало независимо от изменений во фреймворке, и вам не нужно выяснять, возможно, фанковые API / внутренности фреймворка, чтобы сделать это правильно .
• Большее покрытие - вы прогреваете сразу все уровни кеширования, связанные с медленным запросом.

Чтобы объяснить, когда кэш становится "холодным".

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

• Когда когда-либо кеш должен быть проверен после потенциального изменения, которое делает кеш устаревшим, это может быть тайм-аут или более интеллектуальный (например, изменение кэшированного элемента).
• Когда элемент кэша вытесняется, алгоритм для этого описан в разделе «Алгоритм вытеснения кэша» в статье о производительности, которую вы связали , но вкратце.
  • Кэш LFRU (наименее часто - недавно использованный) по количеству обращений и возрасту с ограничением в 800 элементов.

Другие вещи, о которых вы упомянули, в частности, перекомпиляция и перезапуск IIS, очищают либо части, либо все кеши памяти.

Как вы заявили, используйте "предварительно сгенерированные представления", это действительно все, что вам нужно сделать.

Извлечено из вашей ссылки : «Когда представления создаются, они также проверяются. С точки зрения производительности, подавляющая часть затрат на создание представлений фактически приходится на проверку представлений»

Это означает, что при построении сборки модели произойдет снижение производительности. Затем ваш объект контекста пропустит «холодный запрос» и останется отзывчивым в течение всего жизненного цикла объекта контекста, а также последующих контекстов нового объекта.

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

Ярлык ...

1. Пропустите всю эту дополнительную работу с предварительно созданными представлениями
2. Создайте свой объектный контекст
3. Запустите этот сладкий неуместный запрос
4. Затем просто сохраните ссылку на контекст вашего объекта на время всего процесса (не рекомендуется).

У меня нет опыта в этой сфере. Но в других контекстах, например, в Solr, полностью фиктивные чтения не будут иметь большого смысла, если вы не сможете кэшировать всю БД (или индекс).

Лучшим подходом было бы регистрировать запросы, извлекать из журналов наиболее распространенные и использовать их для разогрева. Просто убедитесь, что не регистрировали запросы на прогрев и не удаляли их из журналов, прежде чем продолжить.