Вы описываете проблему, с которой я сталкивался раньше. Позвольте мне поделиться тем, что я знаю, что я подозреваю, и как мне поступить с устранением неисправностей вашего сценария.
Во-первых, звучит так, как будто вы подозреваете, что кеширование является потенциальным источником проблем. В случае набора функций публикации MOSS у вас действительно есть три различных механизма кэширования: кэш объектов, кэш BLOB и кэш вывода страницы. Единственный механизм, который должен быть в игре, если он включен с настройками по умолчанию, это кэш BLOB. Ни кэш объектов, ни кэш вывода страниц не должны касаться автономных таблиц стилей, как у вас.
Вы попытались очистить кэш-память, используя функцию очистки кэш-памяти BLOB-уровня на уровне фермы, и это даст команду MOSS сбросить все данные кеш-памяти BLOB. Вы можете убедиться в этом, просмотрев файловую систему, чтобы убедиться, что только три папки .bin остаются после сброса.
К вашему конкретному вопросу относительно IISRESET: нет, и IISRESET на самом деле не очистит кэш BLOB. Содержимое кэша BLOB сохраняется в течение срока службы пула приложений, обслуживающих веб-приложение. Вам нужно либо использовать функцию для очистки кэша (как вы это сделали), либо выполнить ручное удаление файла. Я не рекомендую последнее, если у вас нет абсолютно никакого другого курса действий. Если вы решите пойти по маршруту вручную, убедитесь, что вы выключили службу W3SVC перед удалением файлов из файловой системы. Если вы этого не сделаете, фактический процесс удаления файла может попасть в состояние состязания с переполнением кэша и привести к повреждению. После того, как вы удалили файлы с остановленным W3SVC, вы можете снова запустить W3SVC для резервного копирования.
Для получения дополнительной информации о внутренностях кеша BLOB и о том, как он работает, я укажу на мою статью в блоге: http://sharepointinterface.com/2009/06/18/we-drift-deeper-into-the-sound-as-the-flush-comes/
Чтобы увидеть, является ли кэш BLOB фактором, влияющим на поведение, которое вы видите, вы можете изменить web.config для ваших веб-приложений и настроить шаблон файла, удалив CSS из список типов файлов в элементе , а затем перезапустите IIS (или, по крайней мере, перезапустите пул приложений).
Другая возможность, основанная на опыте, заключается в том, что вы видите что-то кроме аномалий BLOB-кэша. Ключевое наблюдение для меня заключается в том, что вы наблюдаете, что прямой запрос таблицы стилей CSS возвращает только первые 100 байтов или около того.
Есть ли у вас случайно какое-либо интеллектуальное сетевое оборудование (то есть оборудование для обнаружения вторжений или что-либо, что может выполнять фильтрацию приложений / уровня 7) между WFE и вами, вызывающим абонентом? Системы обнаружения вторжений и IPS являются источником многих типов проблем, с которыми вы сталкиваетесь, и они являются одной из моих первых остановок, когда я вижу «странное» поведение, которое вы описываете. В случае с одним из моих клиентов я столкнулся с проблемой удовлетворения вашего описания (файлы CSS и JS усекаются) из-за промежуточного межсетевого экрана Juniper с активным IPS. Отключение IPS (для проверки) сразу все прояснило. После этого сетевая команда запросила обновление от Juniper для исправления проблемы, чтобы гарантировать, что IPS может оставаться активным.
Попробуйте отключить кэширование BLOB (или удалить расширение CSS из шаблона файла), чтобы увидеть, имеет ли это значение. Если нет, поговорите со своей сетевой командой, чтобы выяснить, происходит ли что-то с потоком ответов, возвращающимся к вам. Вот где я бы начал; надеюсь, одна из этих двух вещей поможет вам.
Небольшое примечание: если у вас есть свободный момент, и вы готовы, я хотел бы услышать о вашем опыте использования решения BlobCacheFarmFlush, которое вы отключили от CodePlex. Я написал это, и я хотел бы услышать ваши мысли - хорошие или плохие: -)
- Шон (sean@sharepointinterface.com)