Another heavy-duty topic which is good to know about
is edge caching. To describe this, let's look at
the information flow for your App Engine application. First
of all, users that want to use your application are
connected to their internet service provider. This provider connects
to Google data center. After the DNS lookup has
determined that your application is hosted by Google, Google
then identifies the data center where your App Engine application
run, and starts talking to the App Engine front
end. If the content is dynamic, the App Engine front
end determines the instance that should manage the request.
So these are your App Engine instances that run your
application code. But if the request is for static
content, for example images or static HTML, the front end
can retrieve it directly from the static servers. And in
both cases, the response is returned back to the user.
So this is a good architecture. But as it looks
right now, all the requests have to be sent to
the data center, which hosts your App Engine application. It
would be much better if more content could be served
directly by this data center. First of all, it would
ease the load on this data center, but more importantly,
since it's closer to the users, the response would be
delivered faster. This is exactly what edge caching is all about.
Edge caching is a cache that sits in the
data center closest to the user. So whenever there is
a request, the result can be served directly from
the cache if it's available there, rather than going through
data center 2. That means less load on data
center 2 in your application, and faster responses to your
users. A win-win. So the question is, then, what
do you need to think about to use edge caching?
Well, there are two ways. The first one is
to set the cache-control header, in the HTTP response. This
should only be done if a subsequent request of this
kind would return the same result. The second option is
to define as much content as possible as static.
Since static content does not change, it's great for edge
caching. You can define which content is static through configuration
files. A good opportunity for you to look at the
online documentation. And remember, as most of the time
with caching, there are no guarantees that the content will
be cached, but when it is, it will be
good for both your application as well as your users.
هناك موضوع قوي آخر والذي يحسن أن تعرف معلومات عنه
وهو التخزين المؤقت الطرفي. لشرح هذا الموضوع، دعنا نلقي نظرة على
،تدفق المعلومات في تطبيق App Engine الخاص بك. أولاً
المستخدمون الذي يريدون استخدام تطبيقك يتصلون
بموفر خدمات الإنترنت الخاص بهم. يتصل هذا الموفر للخدمات
بمركز بيانات Google. بعد أن يؤكد البحث في DNS أن
تطبيقك يتم استضافته بواسطة Google، يقوم Google
بعد ذلك بتحديد مركز البيانات الذي يتم فيه تشغيل تطبيق App Engine الخاص
بك، ويبدأ في الحديث مع واجهة App Engine
الأمامية. إذا كان المحتوى ديناميكيًا، تحدد واجهة App Engine الأمامية
.المثيل الذي يجب أن يتولى إدارة الطلب
وتكون تلك هي مثيلات App Engine التي تقوم بتشغيل
التعليمة البرمجية لتطبيقك. لكن إذا كان الطلب لمحتوى
ثابت، على سبيل المثال، صور أو HTML ثابت، يمكن أن تسترده
الواجهة الأمامية مباشرة من الخوادم الثابتة. وفي كلتا
.الحالتين، يتم إعادة الاستجابة إلى المستخدم
وهذه تعتبر بنية جيدة. لكن كما يبدو الأمر
حاليًا، يجب إرسال جميع الطلبات إلى
مركز البيانات الذي يستضيف تطبيق App Engine الخاص بك. سيكون
الأمر أفضل بكثير إذا تم تقديم المزيد من المحتوى
مباشرةً بواسطة مركز البيانات هذا. أولاً، سيتم تقليل
،الحمل على مركز البيانات، ولكن الأكثر أهمية هو
بما أنه أقرب إلى المستخدمين، فسيتم تسليم الاستجابة
.بطريقة أكثر سرعة. هذا هو كل ما يعنيه مفهوم التخزين المؤقت الطرفي
التخزين المؤقت الطرفي هو نوع من التخزين المؤقت يتم
في مركز البيانات الأقرب إلى المستخدم. وبالتالي، كلما تم تقديم
طلب، يمكن توفير النتيجة مباشرةً من
التخزين المؤقت إذا كان متاحًا، بدلاً من الانتقال إلى
مركز البيانات رقم 2. يعني ذلك تقليل الحمل على مركز البيانات
رقم 2 في تطبيقك، وإرسال استجابات سريعة
إلى المستخدمين. فهو يحقق المكسب لجميع الأطراف. والسؤال الآن هو، ما الذي تحتاج إليه
كي تفكر في استخدام التخزين المؤقت الطرفي؟
حسنًا، توجد طريقتان لعمل ذلك. الطريقة الأولى هي
إعداد عنصر التحكم في التخزين المؤقت وذلك في استجابة HTTP. يجب عمل هذا
فقط إذا كان طلب تابع من هذا
النوع سيؤدي لإعادة النتيجة نفسها. الخيار الثاني هو
.تعريف أكبر قدر ممكن من المحتويات على أنها محتويات ثابتة
بما أن المحتوى الثابت لا يتغير، فيكون ملائمًا للتخزين
المؤقت الطرفي. يمكنك تحديد أي محتوى سيكون ثابتًا من خلال
ملفات التكوين. هناك فرصة رائعة كي تلقي نظرة على
الوثائق المتاحة على الإنترنت. وتذكر أنه كما هو الحال معظم الوقت
في التخزين المؤقت، لا توجد ضمانات تؤكد تخزين المحتوى
بصفة مؤقتة، ولكن عند حدوثه، سيكون
.مفيدًا لكل من تطبيقك ولجميع المستخدمين أيضًا
Otro tema de tarea pesada
que es bueno conocer
es el edge caching.
Para describir esto,
veamos el flujo de información
para tu aplicación de App Engine.
En primer lugar, los usuarios
que quieran utilizar tu aplicación
están conectados
a su proveedor de servicio de Internet.
Este proveedor se conecta
al centro de datos de Google.
Después que la búsqueda de DNS
ha determinado que tu aplicación
está alojada por Google,
Google luego identifica
el centro de datos donde se ejecuta
tu aplicación de App Engine
y comienza a hablar
con el front end de App Engine.
Si el contenido es dinámico,
el front end de App Engine
determina la instancia
que debe gestionar la solicitud.
Así que estas son las instancias
de App Engine que ejecutan
tu código de aplicación.
Pero si la solicitud
es por contenido estático,
por ejemplo, imágenes o HTML estático,
el front end puede recuperarlo
directamente de los servidores estáticos.
Y en ambos casos, la respuesta
se envía de vuelta al usuario.
Así que esta es una buena arquitectura.
Pero como se ve en este momento,
todas las solicitudes deben ser enviadas
al centro de datos que alberga
tu aplicación de App Engine.
Sería mucho mejor si más contenido
pudiera ser servido
directamente por este centro de datos.
En primer lugar, se aliviaría la carga
en este centro de datos,
pero lo más importante,
ya que está más cerca de los usuarios,
la respuesta
sería entregada más rápidamente.
Esto es exactamente
de lo que se trata el edge caching.
El edge caching es una memoria caché
que se encuentra en el centro de datos
más cercano al usuario.
Así que cada vez que hay una solicitud,
el resultado puede ser servido
directamente desde la caché
si está disponible allí,
en lugar de ir al centro de datos 2.
Eso significa menos carga
sobre el centro de datos 2
en tu aplicación,
y respuestas más rápidas a tus usuarios.
Es ganar-ganar.
Entonces la pregunta es ¿qué necesitas
para pensar en utilizar el edge caching?
Bueno, hay dos maneras.
La primera es establecer
el encabezado de control de caché,
en la respuesta HTTP.
Esto solo se debe hacer
si una solicitud posterior de este tipo
retornara el mismo resultado.
La segunda opción es definir
tanto contenido como sea posible
como estático.
Como el contenido estático no cambia,
es ideal para el edge caching.
Puedes definir qué contenido es estático
por medio de archivos de configuración.
Una buena oportunidad para que mires
la documentación en línea.
Y recuerda, como pasa casi siempre
con el almacenamiento en caché,
no hay garantías de que el contenido
sea almacenado en caché,
pero cuando lo sea, será bueno
tanto para tu aplicación,
como para tus usuarios.
もう1つ知っておくとよい重要なトピックは
エッジキャッシングです
これを説明するために
App Engineアプリケーションの
情報の流れを見てみましょう
まずアプリを使いたいユーザは
インターネットサービスプロバイダに
つながっています
プロバイダからGoogle
データセンタへつながります
DNSルックアップがGoogleによって
ホストされていると判断すると
GoogleはApp Engineのアプリが起動する
データセンタを突き止めます
そしてApp Engineのフロントエンドと通信します
内容が動的であればフロントエンドは
要求を処理すべきインスタンスを決定します
これがアプリケーションコードを起動する
App Engineのインスタンスです
しかしその要求が画像やHTMLなど
静的なものだった場合
フロントエンドは静的サーバから
直接取り戻すことができます
その両方のケースにおいて
要求はユーザに返されます
これはすばらしい構造ですが
すべての要求はデータセンタへ
送られなければなりません
それがApp Engineアプリケーションを
ホストしています
もしより多くのコンテンツが直接
こちらのデータセンタで
処理されたらもっとよいでしょう
そうすれば右側のデータセンタの負荷が減ります
またユーザに近いのでレスポンスも早くなります
まさにこれがエッジキャッシングです
エッジキャッシングはユーザに最も近い
データセンタにあるキャッシュです
ですからキャッシュが使用可能であれば
要求がある時はデータセンタ2を経由せずに
結果がキャッシュから直接出されます
つまりデータセンタ2の負荷も減り
ユーザへのレスポンスも早くなりwin-winです
エッジキャッシングを使うには
2つの方法があります
1つ目はHTTPレスポンスにキャッシュ
コントロールヘッダを設定する方法です
そのあとの要求が同じ結果を
返した場合にのみ行われます
2つ目はコンテンツを可能な限り
静的と定義する方法です
静的コンテンツは変化しないので最適です
どのコンテンツが静的かは
設定ファイルで確認できるので
オンラインドキュメンテーションを
活用してください
そしてキャッシングをする時に
そのコンテンツが必ずしも
キャッシュされる保証はないことを
覚えていてください
しかしキャッシュされればアプリにとっても
ユーザにとってもよい結果をもたらします
Outro tópico pesado sobre o qual é bom
ter conhecimento é o cache de borda. Para descrevê-lo, vamos dar uma olhada no
fluxo de informações do aplicativo do App Engine.
Antes de tudo, os usuários que querem usar o aplicativo são
conectados ao provedor de Internet. Esse provedor conecta-se
ao centro de dados do Google. Após a pesquisa de DNS
determinar que o Google hospeda o aplicativo, o Google
identifica o centro de dados onde o aplicativo do App Engine é
executado e se comunica com o front-end do
App Engine. Se o conteúdo for dinâmico, o front-end do
App Engine determinará que a instância deverá gerenciar a requisição.
Então, estas são as instâncias do App Engine que executam o código
do aplicativo. Mas se a requisição for um conteúdo estático
como, por exemplo, imagens ou HTML estático, o front-end
poderá recuperá-lo dos servidores estáticos.
Em ambos os casos, a resposta é retornada ao usuário.
Então, essa é uma boa arquitetura. Mas, do jeito que está
no momento, todas as requisições devem ser enviadas
ao centro de dados que hospeda o aplicativo do App Engine.
Seria muito melhor se mais conteúdos pudessem ser servidos
diretamente por este centro de dados. Antes de tudo, aliviaria
a carga neste centro de dados, mas, o mais importante,
é que a resposta seria mais rápida, já que está mais próximo
dos usuários. É exatamente para isso que serve o cache de borda.
O cache de borda é um cache que fica no
centro de dados mais próximo do usuário. Então, sempre que há
uma requisição, o resultado pode ser servido diretamente do
cache, se estiver disponível nele, em vez de passar pelo
segundo centro de dados. Isso significa uma carga menor no segundo
centro de dados do aplicativo e respostas mais rápidas para os
usuários. Todos saem ganhando. A pergunta é: o que
é necessário fazer para usar o cache de borda?
Bom, há duas opções. A primeira é
configurar o cabeçalho de controle de cache na resposta HTTP.
Isso deve ser feito somente se uma requisição subsequente desse
tipo retorna o mesmo resultado. A segunda opção é
definir a maior quantidade possível do conteúdo como estático.
Como o conteúdo estático não muda, ele é ótimo para o
cache de borda. Você pode definir quais conteúdos são estáticos nos arquivos de
configuração. Uma ótima oportunidade para você dar uma olhada na
documentação online. E lembre-se de que, como na maioria das vezes lidando
com cache, não há garantias de que o conteúdo será
armazenado em cache, mas, quando isso ocorrer, será
ótimo tanto para o aplicativo quanto para os usuários.
我们必须了解的另一个重量级话题就是
边缘缓存 为了描述该缓存
我们来看一看 App Engine 应用的信息流 首先
将想要使用你应用的用户
连接到其互联网服务供应商 再将此提供商
连接到 Google 数据中心 通过 DNS 查找
确定 Google 已托管了你的应用
随后 Google 会识别运行你的 App Engine 应用的
数据中心 并且开始与 App Engine 前端
进行对话 如果内容是动态的 则 App Engine 前端
确定应该管理请求的实例
因此 这些是运行你的应用代码
的 App Engine 实例 但是 如果请求静态内容
例如 图像或静态 HTML
则前端可以从静态服务器中直接检索 在
这两种情况下 将响应返回到用户
所以说 这是一个很棒的架构 但是现在看起来
必须将所有请求发送到
托管你的 App Engine 应用的数据中心 如果
此数据中心可以直接提供更多的内容
也是不错的 首先
这会缓解数据中心的负载 更重要的是
因为它离用户更近 所以响应的交付速度
会更快 这就是边缘缓存
边缘缓存是离用户更近的
数据中心中的缓存 所以 发出请求之后
如果缓存中的结果可用
那么会直接从该缓存返回结果
而不是从数据中心 2 中返回 这意味着 应用中数据中心 2 的
负载变小了 向用户交付响应的速度
更快了 这是双赢的结果 所以 我们要问
使用边缘缓存时你需要考虑什么?
这有两个方法 第一个方法是
在 HTTP 响应中设置缓存控制标题 只有当
此种类的后续请求返回相同的结果时
才可以这么做 第二种方法是
尽可能将更多的内容定义为静态内容
因为静态内容不需要更改 这对于边缘缓存来说
是最合适的 你可以通过配置文件定义
静态内容 这是让你阅读在线文档的
好机会 请记住 执行缓存时
大多数时候不会保证缓存内容
但是如果缓存了内容
这对你的应用和你的用户来说都是好事