Могу ли я иметь раздел App_Code, который компилируется отдельно от остальной части папки? - PullRequest
3 голосов
/ 25 января 2011

У нас есть веб-сайт с огромным количеством кэшированных объектов, хранящихся в статических переменных внутри App_Code.Всякий раз, когда мы помещаем изменение App_Code в наши производственные веб-серверы, оно перезапускает пул IIS и очищает кэш.Однако он не очищает кэш, когда мы выгружаем изменения в файлы .aspx и .aspx.cs.

Мне нужно несколько классов, которые будут обновляться несколько раз в день, чтобы на них можно было ссылатьсяв App_Code.Я хотел бы либо раздел моего App_Code, который я могу обновлять несколько раз в день, не задействуя IIS и не очищая кэш, либо возможность ссылаться на классы вне App_Code из App_Code.

Есть ли решение, которое подходитмоя проблема?

Ответы [ 2 ]

4 голосов
/ 25 января 2011

Обновления App_Code или / bin / всегда перерабатывают ваши пулы приложений, я считаю. Если вы говорите, что у вас есть сценарий развертывания, где обновления файла .aspx.cs не перерабатывают пул приложений, и если вы можете ссылаться на сам тип страницы, возможно, вы можете переместить свой код в .aspx. CS файлы, чтобы предотвратить повторную переработку. Это может быть уродливым выбором, хотя.

Одно из предложений - пересмотреть ваш дизайн, чтобы уменьшить количество ежедневных обновлений исходного кода. Возможно, используйте XML или хранилище базы данных, и сделайте ваше приложение немного более универсальным и менее подверженным двоичным обновлениям.

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

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

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

Частые обновления происходят только потому, что происходит много изменений в разработке?

2 голосов
/ 26 января 2011

Другим подходом будет использование решения распределенного кэша вместо кэша HttpRuntime.

Кэш HttpRuntime имеет два основных недостатка:

1) Он сбрасывается при перезагрузке домена приложения.В любом случае это по умолчанию выполняется каждые 29 часов, даже если вы не изменяете App_Code.

2) Он локализован на одном веб-сервере.Поэтому, если ваш веб-сервер должен масштабироваться до более крупной веб-фермы, ваш кэш становится все менее и менее эффективным, поскольку записи в кэше не синхронизируются между всеми веб-серверами.

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

Примеры решений:

  • memcached
  • redis
  • Oracle Coherence (коммерческий)

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

...