Уборка динамического содержимого HTTP для создания репликации статического содержимого HTTP

Question

У меня медленно развивающийся динамический веб-сайт, обслуживаемый J2EE. Время ответа и емкость нагрузки сервера недостаточны для потребностей клиентов. Кроме того, специальные запросы могут неожиданно влиять на другие службы, запущенные на одном сервере приложений/базе данных. Я знаю причины и не могу их решить в краткосрочной перспективе. Я понимаю подсказки кеширования HTTP (expiry, etags ....), и для этого вопроса, пожалуйста, предположите, что я максимизировал возможности для снижения нагрузки.

Я собираюсь совершить обход грубой силы всех URL-адресов в системе, чтобы заполнить кеш, а затем скопировать содержимое кеша на серверы геодезистов кеш-памяти рядом с клиентами. Я думаю о Squid или Apache HTTPD mod_disk_cache. Я хочу настроить одну копию и (вручную) реплицировать содержимое кеша. Мне не нужна федерация или интеллект среди рабов. Когда данные меняются, аннулирование кеша, я обновляю свой мастер-кеш и обновляю ведомые версии, возможно, один раз в сутки.

Кто-нибудь это сделал? Это хорошая идея? Существуют ли другие технологии, которые я должен исследовать? Я могу программировать это, но я предпочел бы конфигурацию решения с открытым исходным кодом технологии

Благодаря

Answer 1

Я использовал Squid перед тем, чтобы уменьшить нагрузку на динамически созданный RSS-каналы, и она работала очень хорошо. Это просто требует некоторой тщательной настройки и настройки, чтобы заставить его работать так, как вы хотите.

Answer 2

Использование загрунтованного кеш-сервера - отличная идея (я сделал то же самое с помощью wget и Squid). Однако в этом сценарии, вероятно, нет необходимости.

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

1. Загрузка запроса базы данных на ваш сервер БД.
2. Загрузка бизнес-логики на ваш веб-сервер/сервер приложений.

Адрес JSP-specific overview of caching options.

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

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

Мой опыт работы с ASP, но те же самые механизмы доступны на страницах JSP. По моему опыту, даже с небольшим количеством кэширования вы можете ожидать увеличения в 5-10 раз максимальных запросов в секунду.

Answer 3

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

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