Целесообразно ли использовать HashSet в качестве статического глобала на веб-сервере?

2

Я хочу создать "временный поиск кэша", чтобы ускорить поиск файлов на моем веб-сервере.

Теперь у меня есть папка с изображениями, и если пользователь запрашивает изображение, я использую File.Exists(...), чтобы проверить, существует ли изображение. Если это не так, загрузите его с другого сервера и в любом случае перенаправьте пользователя на него.

Проблема заключается в том, что многие запросы сразу заставляют File.Exists() зависать. Я хотел бы сохранить быстрый и грязный HashSet имен файлов, которые, как известно, находятся в локальной папке, так что если пользователь запрашивает файл и существует в HashSet, просто перенаправляйте его, не делая File.Exists(), если он не существует int he HashSet, выполните File.Exists(), затем добавьте его.

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

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

Изменить в отношении условий гонки:
Да, я думал о гоночных условиях. Но возможно ли состояние гонки на одном HashSet? Так как он допускает только уникальные значения, не может ли вторая попытка добавить значение сбой? В какой момент я просто проигнорирую ошибку и продолжаю.

  • 0
    Да, у вас наверняка будут условия гонки, когда предметы добавлены в список. Необходимо обновить внутреннее состояние, уникальности клавиш недостаточно.
Теги:
caching
.net-3.5

2 ответа

3
Лучший ответ

Это имеет смысл. Однако убедитесь, что вы позаботились о возможных условиях гонки. Вы можете использовать ReaderWriterLockSlim class для управления доступом к объекту из разных потоков.

UPDATE:

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

Поделиться
  • 0
    В другом ответе вы упомянули, что Lock () {} не будет иметь проблем с производительностью. Какие преимущества предлагает ReaderWriterLockSlim по сравнению с Lock () {}?
  • 0
    Если вы используете lock , вам придется использовать ее каждый раз, когда вы читаете или пишете объекту. Только один поток может читать с объекта одновременно. Используя блокировку чтения-записи, только один писатель может получить доступ к объекту, но несколько читателей могут читать с него одновременно. Однако, если вы можете сохранить области блокировки достаточно маленькими, разница в производительности может быть незначительной, и оператор lock будет гораздо проще реализовать.
Показать ещё 6 комментариев
4

В дополнение к проблемам гонки, о которых говорили люди, вы задаете еще ряд проблем.

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

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

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

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

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню