Пакеты кэширования и веб-ферм

Я хотел бы знать последствия динамического изменения коллекции пакетов (скажем, во время загрузки страницы). Я попытался добавить новый файл сценария в коллекцию пакетов (изначально созданную в app_start). В моем первоначальном тесте он работал нормально. Одно отличие, которое я заметил, заключается в том, что браузер не кэширует связанный скрипт и стиль (отправляет новые запросы при каждом обновлении). Я хотел бы знать, есть ли способ принудительно кэшировать скрипт/стиль пакета после первоначальной выборки.

У меня есть статические скрипты и стили, загруженные в коллекцию пакетов в самом app_start. Но у меня есть фрагмент кода при загрузке главной страницы, чтобы проверить наличие скрипта или стилей для конкретной страницы (например, скажем, загружается страница ABC.aspx, этот код будет искать наличие ABC.js в папке Scripts и ABC.css в папке «Стили»). если он существует, он будет загружен в заголовок страницы. Здесь я попытался добавить его в пакеты. Как лучше всего сделать эти условные скрипты/стили частью коллекции пакетов по умолчанию?

Моя производственная среда — это веб-ферма. Итак, есть ли что-то, что я должен сделать специально, чтобы хэш URL-адреса V оставался одинаковым на всех серверах?

Я прочитал комментарий "Хао Кунг" здесь, объясняя проблему кэширования пакетов для веб-ферм (результаты 404), как лучше всего решить эту проблему?


person code_explorer    schedule 31.01.2014    source источник


Ответы (1)


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

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

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

Почему бы просто не создать отдельный пакет для каждой страницы? Таким образом, «общий» пакет со всем общим кодом будет кэшироваться и использоваться повторно, а при загрузке страницы ABC.aspx вы всегда загружаете свой пакет «abc», который будет выполнять собственный контроль версий содержимого, а не влияют на общие библиотеки.

Кроме того, есть дополнительный недостаток изменения пакета на каждой странице:

Если каждая страница предоставляет отдельный пакет, клиент будет получать весь код для ваших общих библиотек снова и снова, по одному разу для каждой страницы. Даже если кешируется. Например: не было бы смысла отправлять JQuery вместе с каждой страницей.

person Pablo Romeo    schedule 04.02.2014
comment
Спасибо Пабло за предложения. - person code_explorer; 04.02.2014
comment
Спасибо Пабло за предложения. Да, лучше, чтобы пакеты были как можно более статичными. Я согласен с этим. Мой другой вопрос заключается в том, есть ли какие-либо конкретные настройки, которые я должен сделать, чтобы статический хэш пакетов был одинаковым на всех серверах в веб-ферме? - person code_explorer; 04.02.2014
comment
Конечно вещь. Что касается серверов, то никаких настроек я не знаю. Он вычисляется на основе содержимого каждого файла, поэтому, если содержимое одинаковое, особых проблем быть не должно. Однако некоторые сообщают о проблемах, когда серверы работают с разными версиями .NET, например: stackoverflow.com/a/15071452/ 1373170 - person Pablo Romeo; 05.02.2014
comment
Спасибо. В моем случае гарантируется, что все ящики на ферме будут иметь одинаковую конфигурацию. Так что я думаю, что тогда я могу быть спокоен в этом вопросе :) - person code_explorer; 05.02.2014
comment
Да, я так думаю, но всегда полезно проверить это на всякий случай. У меня лично с этим проблем не было. Теперь, если вы все еще собираетесь динамически добавлять пакеты, остерегайтесь проблем, упомянутых в этой ссылке (ошибка 404). Я всегда сохранял их статичными, поэтому не могу точно сказать, как они будут вести себя в этом сценарии. - person Pablo Romeo; 05.02.2014