[Я спросил об этом на stackoverflow.com, но они подумали, что этот список будет лучше]
У меня медленно развивающийся динамический веб-сайт, обслуживаемый J2EE. Время отклика и грузоподъемность сервера неадекватны потребностям клиента. Более того, специальные запросы могут неожиданно повлиять на другие службы, работающие на том же сервере / базе данных приложений. Я знаю причины и не могу их устранить в ближайшее время. Я понимаю подсказки кеширования HTTP (истечение срока, etags ....), и для целей этого вопроса предположим, что я максимально использовал возможности для снижения нагрузки.
Я подумываю выполнить полный перебор всех URL-адресов в системе, чтобы заполнить кеш, а затем скопировать содержимое кеша на геодисперсные серверы кеша рядом с клиентами. Я думаю о Squid или Apache HTTPD mod_disk_cache. Я хочу загрузить одну копию и (вручную) реплицировать содержимое кеша. Мне не нужна федерация или разум среди рабов. Когда данные изменяются, делая кеш недействительным, я обновляю свой главный кеш и обновляю подчиненные версии, вероятно, раз в ночь.
Кто-нибудь настраивал http-кеш, а затем реплицировал его? Это хорошая идея? Есть ли другие технологии, которые мне следует изучить? Я могу запрограммировать это, но я бы предпочел конфигурацию решения с открытым исходным кодом.
Спасибо
ps context: Основная проблема, безусловно, в следующем:
Время ответа часто составляет несколько десятков секунд (пожалуйста, не спрашивайте). Как уже упоминалось, я не могу решить их в краткосрочной перспективе (вернее, я обращаюсь к ним, но их очень много, и они не основаны на JSP и ....). У меня есть клиенты из США, Европы и Азии, поэтому я бы очень хотел воспроизвести кеш, как только я его заправлю. Для внутренних корпоративных пользователей подобный Akamai не подходит. Я хотел бы заархивировать, заархивировать кеш и отправить по FTP обратно подчиненным. В других случаях кеш-сервер, но не приложение, должен находиться в DMZ.
Теоретически большой wget -r с последующим архивированием может помочь. Проблема в том, что на практике, если вы можете обойтись с запуском wget (без фактического изменения содержимого), вы обычно можете так же легко создать в значительной степени статический сайт (заменить динамические страницы статическими).
Если бы вы не были так увлечены геолокацией, настройку лака с чрезмерным кэшированием могли бы сделать эту работу - вы можете делать замечательные вещи с лаком, связанные с автоматическим аннулированием записей кеша при изменении данных, поддерживающих кешированную страницу. Я не уверен, что вам нужно для геолокации. Если вы думаете, что это изменит производительность с «неприемлемой» на «приемлемую», это очень маловероятно; в то время как, если вам нужна геолокация по причине, не связанной с вашими текущими проблемами с производительностью, это может быть вопрос выбора меньшего из двух зол - исправить проблемы с производительностью вашего сайта с помощью лака или исправить то, что должно быть исправлено с помощью геолокации . С сайтом, который отображает страницу за секунды (!), Должно быть что-то довольно серьезное, чтобы иметь более высокий приоритет для исправления.
Я видел, как покупатель проделал этот трюк с ужасно неэффективным сайтом Tomcat, на котором работал интернет-магазин; они кэшировали bejesus из всего (с ESI, чтобы сделать материал для входа клиентов) и имели в интерфейсе администратора prod varnish, чтобы сказать «очистить эти URL-адреса» всякий раз, когда кто-то вносил изменения, скажем, в цену или описание продукта. Это было некрасиво, но работало достаточно хорошо, чтобы держать их на плаву, пока их приложение не будет исправлено.
Вы рассматривали возможность использования http://memcached.org/ ?