2013-08-27 4 views
2

Nous avons un morceau de Javascript qui est servi quotidiennement à des millions de navigateurs. Afin de gérer la charge, nous avons décidé d'opter pour Google App Engine.Réduire les coûts de Google App Engine

Une chose particulière à propos de ce morceau de Javascript est qu'il est (très) légèrement différent par compagnie utilisant notre service.

Jusqu'à présent, nous traitons ce en servant tout par main.py qui va essentiellement: - Lire le fichier statique JS et l'imprimer - Imprimer code personnalisé

Nous le faisons à chaque charge, et les coûts commencer à vraiment ajouter.

En plus d'avoir une version statique du fichier par client, y a-t-il un autre moyen de réduire votre facture? L'utilisation de memcache au lieu de lire un fichier réduirait-elle le prix?

Merci beaucoup.

+0

sont des fichiers statiques il suffit de lire et imprimer ou lire, modifier et imprimer? ou c'est juste une recherche de quel fichier statique à utiliser? – Faisal

+0

Juste une recherche, il suffit de lire et d'imprimer, puis imprimer du code personnalisé supplémentaire. –

Répondre

2

Voici quelques façons de l'optimiser davantage sans utiliser de cdn.

Oui, ajoutez la couche memcache pour mettre en cache toute la sortie et ajouter un cache d'instance supplémentaire qui utilise la mémoire de l'instance. Cela peut simplement être fait en ajoutant un module global dict et en y ajoutant votre cache key/vals. Mais vous pouvez également utiliser une bibliothèque LRUCaching pour ne pas surcharger vos instances. Enfin, le moins cher serait d'utiliser un cdn et de pointer l'origine vers votre application App Engine, si votre sortie ne nécessite pas de modification trop fréquemment, vous pouvez mettre en cache ces résultats pour un temps court ou long.

Voici un blog sur la mise en cache par exemple Ben Kamens: http://bjk5.com/post/2320616424/layer-caching-in-app-engine-with-memcache-and-cachepy

3

Je suppose que vous payez beaucoup en heures d'instance. La lecture du système de fichiers GAE est plutôt lente. Ainsi, le moyen le plus simple d'optimiser est seulement de lire le fichier statique une fois au démarrage de l'instance, de conserver le fichier js en mémoire (c'est-à-dire une variable globale) et de l'imprimer. Deuxièmement, assurez-vous que votre js est mis en cache par les clients afin que lorsqu'ils rechargent votre page, vous ne devez pas les servir de nouveau inutilement.

La prochaine façon est de servir le fichier js en tant que fichier statique si possible. Cela vous permettrait d'économiser de l'argent si le fichier js est volumineux et que vous consommez des cycles d'UC simplement en l'imprimant. Dans ce cas, demandez à votre gestionnaire qui génère le code HTML d'insérer l'URL appropriée dans le fichier js approprié au lieu de régénérer l'intégralité du fichier js à chaque fois. Vous économiserez de l'argent parce que vous ne serez pas facturé des heures d'instance pour les fichiers servis en tant que fichiers statiques, plus ils peuvent être mis en cache dans le cache périphérique (CDN de GAE), et rien ne vous sera facturé.

0

Si vous utilisez Javascript en servant des fichiers statiques (je suppose que ce que vous faites maintenant).

  1. Vous pouvez utiliser memcache (cela réduit les coûts car le serveur accélère le serveur - moins d'instances).
  2. Vous pouvez utiliser webcache pour autoriser le cache simple example (cela réduit les relectures - pas les instances).
  3. Vous pouvez prendre en charge les en-têtes HTTP avancés enter link description here (besoin de réécrire Google Static Files Handler) (il réduit les relectures + accélère les relectures s'il n'est pas modifié - pas instance ou instances plus rapides et moins instances).
+0

Voir les champs pour la midification + eTags - c'est un peu difficile http://en.wikipedia.org/wiki/List_of_HTTP_header_fields – Chameleon