Showing Revision 6 created 09/29/2014 by Fran Ontanaya.

1. Title:
   05-28 Edge Caching
2. Description:

   05-28 Edge Caching

3. 210 0:00 - 0:03
   Otro tema de tarea pesada
   que es bueno conocer
4. 2800 0:03 - 0:04
   es el edge caching.
5. 4260 0:04 - 0:07
   Para describir esto,
   veamos el flujo de información
6. 6646 0:07 - 0:09
   para tu aplicación de App Engine.
7. 8832 0:09 - 0:11
   En primer lugar, los usuarios
   que quieran utilizar tu aplicación
8. 11470 0:11 - 0:14
   están conectados
   a su proveedor de servicio de Internet.
9. 14400 0:14 - 0:17
   Este proveedor se conecta
   al centro de datos de Google.
10. 16960 0:17 - 0:20
    Después que la búsqueda de DNS
    ha determinado que tu aplicación
11. 20286 0:20 - 0:23
    está alojada por Google,
    Google luego identifica
12. 23096 0:23 - 0:26
    el centro de datos donde se ejecuta
    tu aplicación de App Engine
13. 25693 0:26 - 0:29
    y comienza a hablar
    con el front end de App Engine.
14. 28644 0:29 - 0:32
    Si el contenido es dinámico,
    el front end de App Engine
15. 31529 0:32 - 0:34
    determina la instancia
    que debe gestionar la solicitud.
16. 34350 0:34 - 0:37
    Así que estas son las instancias
    de App Engine que ejecutan
17. 36530 0:37 - 0:39
    tu código de aplicación.
18. 38710 0:39 - 0:41
    Pero si la solicitud
    es por contenido estático,
19. 41270 0:41 - 0:44
    por ejemplo, imágenes o HTML estático,
20. 44040 0:44 - 0:48
    el front end puede recuperarlo
    directamente de los servidores estáticos.
21. 48050 0:48 - 0:52
    Y en ambos casos, la respuesta
    se envía de vuelta al usuario.
22. 51960 0:52 - 0:54
    Así que esta es una buena arquitectura.
23. 53590 0:54 - 0:57
    Pero como se ve en este momento,
    todas las solicitudes deben ser enviadas
24. 57000 0:57 - 1:00
    al centro de datos que alberga
    tu aplicación de App Engine.
25. 60230 1:00 - 1:03
    Sería mucho mejor si más contenido
    pudiera ser servido
26. 62850 1:03 - 1:05
    directamente por este centro de datos.
27. 65090 1:05 - 1:08
    En primer lugar, se aliviaría la carga
    en este centro de datos,
28. 68350 1:08 - 1:11
    pero lo más importante,
    ya que está más cerca de los usuarios,
29. 71370 1:11 - 1:14
    la respuesta
    sería entregada más rápidamente.
30. 73780 1:14 - 1:17
    Esto es exactamente
    de lo que se trata el edge caching.
31. 77210 1:17 - 1:20
    El edge caching es una memoria caché
    que se encuentra en el centro de datos
32. 80440 1:20 - 1:22
    más cercano al usuario.
33. 81930 1:22 - 1:25
    Así que cada vez que hay una solicitud,
    el resultado puede ser servido
34. 84880 1:25 - 1:27
    directamente desde la caché
    si está disponible allí,
35. 87086 1:27 - 1:29
    en lugar de ir al centro de datos 2.
36. 89242 1:29 - 1:32
    Eso significa menos carga
    sobre el centro de datos 2
37. 91900 1:32 - 1:35
    en tu aplicación,
    y respuestas más rápidas a tus usuarios.
38. 95480 1:35 - 1:37
    Es ganar-ganar.
39. 97166 1:37 - 1:42
    Entonces la pregunta es ¿qué necesitas
    para pensar en utilizar el edge caching?
40. 102232 1:42 - 1:44
    Bueno, hay dos maneras.
41. 104180 1:44 - 1:47
    La primera es establecer
    el encabezado de control de caché,
42. 106660 1:47 - 1:49
    en la respuesta HTTP.
43. 108780 1:49 - 1:52
    Esto solo se debe hacer
    si una solicitud posterior de este tipo
44. 111820 1:52 - 1:54
    retornara el mismo resultado.
45. 113800 1:54 - 1:57
    La segunda opción es definir
    tanto contenido como sea posible
46. 116786 1:57 - 1:58
    como estático.
47. 118292 1:58 - 2:02
    Como el contenido estático no cambia,
    es ideal para el edge caching.
48. 121610 2:02 - 2:05
    Puedes definir qué contenido es estático
    por medio de archivos de configuración.
49. 125202 2:05 - 2:09
    Una buena oportunidad para que mires
    la documentación en línea.
50. 129306 2:09 - 2:12
    Y recuerda, como pasa casi siempre
    con el almacenamiento en caché,
51. 132040 2:12 - 2:15
    no hay garantías de que el contenido
    sea almacenado en caché,
52. 134820 2:15 - 2:18
    pero cuando lo sea, será bueno
    tanto para tu aplicación,
53. 137970 2:18 - 2:20
    como para tus usuarios.