GAE: включение Edge Cache с помощью webapp2 (Python)

На YouTube появилось это новое видео, демонстрирующее силу EdgeCaching в архитектуре GAE, и в этом конкретном месте видео они демонстрируют, насколько легко его использовать: http://www.youtube.com/смотреть?v=QJp6hmASstQ#t=11m12

К сожалению, это не так просто...

Я хочу включить пограничное кэширование, используя структуру webapp2, предоставленную Google.

Я звоню:

self.response.pragma = 'Public'
self.response.cache_expires(300)

но кажется, что это перекрывается чем-то другим.

Заголовок, который я получаю:

HTTP/1.1 200 OK
Pragma: Public
Cache-Control: max-age=300, no-cache
Expires: Sat, 23 Feb 2013 19:15:11 GMT
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
X-AppEngine-Estimated-CPM-US-Dollars: $0.000085
X-AppEngine-Resource-Usage: ms=39 cpu_ms=64
Date: Sat, 23 Feb 2013 19:10:11 GMT
Pragma: no-cache
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Cache-Control: no-cache, must-revalidate
Vary: Accept-Encoding
Server: Google Frontend
Content-Length: 600

Я использую ndb верхнего уровня:

app = ndb.toplevel(webapp2.WSGIApplication(...

Я попробовал методы, описанные здесь, но они, похоже, не применимы к webapp2: http://code.google.com/p/googleappengine/issues/detail?id=2258#c14

Я также просмотрел этот пост: https://groups.google.com/d/topic/webapp2/NmHXoZZSVvo/discussion

Пытался установить все вручную, безрезультатно. Что-то переопределяет мои настройки кеша.

Есть ли способ заставить его работать с webapp2? Любой другой вариант приветствуется.

EDIT: я использую URL-адрес с префиксом версии: http://version.appname.appspot.com, и это, вероятно, причина моей проблемы.


google-app-engine webapp2
person sanx    schedule 23.02.2013    source источник
comment
пограничный кеш доступен только для доменов Google Apps, не влияет на appspot.com Смотрите этот пост   -  person Deleplace    schedule 22.10.2014

Ответы (3)


arrow_upward
6
arrow_downward

Это должно быть все, что вам нужно:

self.response.cache_control = 'public'
self.response.cache_control.max_age = 300
person Greg    schedule 24.02.2013
comment
На dev_appserver работает, а на appengine все равно не кеширует. Вот заголовок: Cache-Control →max-age=300, public, no-cache, must-revalidate Content-Encoding →gzip Content-Length →600 Content-Type →application/json; charset=utf-8 Date →Mon, 25 Feb 2013 19:12:44 GMT Expires →Fri, 01 Jan 1990 00:00:00 GMT Pragma →no-cache Server →Google Frontend Vary →Accept-Encoding X-AppEngine-Estimated-CPM-US-Dollars →$0.000079 X-AppEngine-Resource-Usage →ms=215 cpu_ms=64 - person sanx; 26.02.2013
comment
Я использую префикс версии: version.appname.appspot.com и, кажется, поэтому это не заводится. - person sanx; 26.02.2013
comment
Вы пытались выйти из своей учетной записи администратора, чтобы проверить это? - person Dinoboff; 27.09.2014

arrow_upward
3
arrow_downward

Дополнительные сведения см. в разделе кэширования. Возможно, вы нарушили какие-то правила. Следующая лучшая часть:

Ответ может быть сохранен в кэшах Cloud CDN, только если выполняются все следующие условия:

  • Он обслуживался серверной службой с включенным кэшированием.
  • Это был ответ на запрос GET.
  • Код состояния: 200, 203, 300, 301, 302, 307 или 410.
  • Он имеет директиву Cache-Control: public.
  • Он имеет заголовок Cache-Control: s-maxage, Cache-Control: max-age или Expires.
  • Он имеет либо заголовок Content-Length, либо заголовок Transfer-Encoding.

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

  • Он имеет заголовок Set-Cookie.
  • Его тело превышает 4 МБ.
  • Он имеет заголовок Vary со значением, отличным от Accept, Accept-Encoding или - Origin.
  • У него есть Cache-Control: директива no-store, no-cache или private.
  • В соответствующем запросе была директива Cache-Control: no-store.
person Daniel De León    schedule 11.01.2017

arrow_upward
1
arrow_downward

Я предполагаю, что вы смешиваете две связанные, но разные идеи.

Первая идея, о которой говорится в видео, на которое вы ссылаетесь, заключается в том, чтобы определенные файлы в вашем приложении обслуживались пулом серверов App Engine, которые специализируются на обслуживании статического контента. Это быстрее, чем если бы ваше приложение обслуживало эти файлы, так как не будет задержки для запуска нового экземпляра вашего приложения для обслуживания статического файла. (Настоятельно рассмотрите возможность обслуживания ваших .js и .css таким образом.) Это статическое средство обслуживания полностью контролируется во время обновления (загрузки) приложения с помощью объявлений, которые вы делаете в app.yaml (или appengine-web.xml для приложений Java).

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

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

person Dave W. Smith    schedule 23.02.2013
comment
Ссылка указывала не на то время в видео, я его отредактировал. Спасибо, что указали на это. видео Я рассматриваю вторую идею, используя заголовки ответа http . - person sanx; 26.02.2013