Amazon laat Cloudfront dynamische content serveren
Amazon Web Services heeft zijn clouddienst Cloudfront, dat bedoeld is voor contentdistributie, voorzien van de mogelijkheid om dynamische content te serveren. Tot nu toe was het alleen mogelijk om statische content aan te bieden.
Cloudfront, dat in 2008 zijn deuren opende, wordt als content delivery network ingezet door websites die grote hoeveelheden statische content willen aanbieden, zoals afbeeldingen, video's of muziekbestanden. De content wordt daarbij opgeslagen in zogenaamde buckets die via een url oproepbaar zijn. Amazon gebruikt voor het aanbieden van content via zijn Cloudfront-platform wereldwijd circa dertig datacenters.
Inmiddels laat Amazon weten dat het zijn contentdistributiedienst van de mogelijkheid heeft voorzien om voortaan ook dynamische content te serveren. Hierdoor kan voor elke bezoeker van een website bepaald worden welke content voor hem of haar beschikbaar is.
Om dynamische content via Cloudfront te serveren, zou een websitebeheerder via de AWS Management Console slechts enkele stappen hoeven te doorlopen. Doordat Cloudfront nu in een url een query string herkent, kan vervolgens dynamische content naar de eindgebruiker gestuurd worden.
Amazon claimt dat het diverse verbeteringen aan Cloudfront heeft doorgevoerd om het aanbieden van dynamische content te versnellen. Zo wordt er gebruik gemaakt van persistent tcp-verbindingen, kan content uit meerdere bronnen opgehaald worden en de time-to-live-waarde voor caching is voortaan te verlagen tot 0.
Reacties (19)
[Reactie gewijzigd door cornedor op maandag 14 mei 2012 20:01]
CF is een CDN met heel veel nodes. Als je content opvraagt wordt het geserveerd vanuit de node die het dicht bij de requester is. Je hebt dus lagere latency. Verder kan je CF dus niet gebruiken als opslag. Het is een soort reverse proxy, met heel veel end points.
Het mechanisme is vrij simpel, iemand doet een http request naar CF, de desbetreffende node kijkt of de content lokaal beschikbaar is, zonee, dan wordt het aan de upstream leverancier gevraagd (je eigen web server). Daarna wordt het doorgestuurd naar de persoon die het opvraagt. Als de data wel lokaal beschikbaar is, dan wordt het direct verstuurd, zonder contact met de upstream leverancier.
Voor het invalideren van de lokale cache zijn eigenlijk 2 mogelijkheden:
- de cache headers die je eigen web server meegeeft worden gerespecteerd
- je kunt op url niveau invalidatie requests sturen. Hiervoor moet je in de regel wel betalen.
wat betreft he serveren van een site zoals tweakers zou ik niet zo snel voor een cloud oplossing kiezen. Het aantal bezoekers is redelijk voorspelbaar en constant. Fysieke servers in eigen beheer geven je een stuk meer controle (performance tuning, hardware keuze, software keuze, etc), mits je er de kennis voor hebt. Vrij grote kans dat het ook goedkoper is.
Voor sterk wisselende en/of lastig voorspelbare loads is het schalen van de cloud oplosingen van amazon natuurlijk jeen uitkomst!
[Reactie gewijzigd door borft op maandag 14 mei 2012 20:34]
/mijnvideo.mp4?v=1,2,3
niet heel fraai maar wel praktisch :-)
Beiden hebben zo hun voor- en nadelen.
Het is redelijk briljant dat je met een sim[pel shellscriptje opeen 20 machines erbij kunt booten en die automatisch achter je loadbalacer kunt hangen. Waarbij de loadbalancer automatisch opschaalt naarmate het dataverkeer toeneemt! Maar alles heeft wel zijn prijs natuurlijk.
Ik vraag me bijvoorbeeld af wat de io performance is van de zwaarste instanties, zelf als je meerdere ELB's in raid opstellingen gebruikt. En fysieke machine met een stuk of 10 ssd's in raid10 haalt toch echt fokking veel iops
Het laatste is in theorie iets sneller, maar lastiger te implementeren omdat de webapplicatie ervoor moet zorgen dat de content in S3 komt. Wanneer de website enkel statisch is, maakt dat natuurlijk niet uit. Je kunt zelfs een 'index' file specificeren, waarmee je dus wel degelijk een volledige statische website kan hosten. Of dat rendabel is, is een heel andere vraag.
Een ander groot voordeel van een CDN is dat je content krijgt geserveerd vanaf de dichtstbijzijnde edge-locatie. Wanneer je de website vanuit NL bezoekt, krijg je dus waarschijnlijk een CF server in A'dam te pakken. Wanneer je vanuit België komt wellicht een server in Brussel. Dat is dus vooral zinvol wanneer je een sterk internationaal georiënteerde website host.
[Reactie gewijzigd door jn0077 op maandag 14 mei 2012 21:30]
Of wanneer je gewoon een hele hoge uptime nodig hebt. Een aardbeving in Amsterdam waardoor je datacenter onbereikbaar is, is dan geen probleem.Een ander groot voordeel van een CDN is dat je content krijgt geserveerd vanaf de dichtstbijzijnde edge-locatie. Wanneer je de website vanuit NL bezoekt, krijg je dus waarschijnlijk een CF server in A'dam te pakken. Wanneer je vanuit België komt wellicht een server in Brussel. Dat is dus vooral zinvol wanneer je een sterk internationaal georiënteerde website host.
Praktisch elke webserver, bekijkt tijdens het opstarten welke statische bestanden er zijn, gzipt die in een cache en serveert die zodra er een gzip header wordt meegestuurd.
Het dynamisch gzippen, oftewel bij elke request de content gzippen veroorzaakt zinloze cpuload. Je CPU doet immers bij elke request exact dezelfde bewerkingen en genereert dezelfde output....
(je kan via een om weg alle bestanden als GZIP uploaden en de headers goed zetten maar niet zo handig helaas.)
Maar het zou mooier zijn als AWS gewoon GZIP en non-GZIP ondersteund....
http://docs.amazonwebserv...#RequestCustomCompression[Reactie gewijzigd door Lex_brugman op dinsdag 15 mei 2012 11:56]
weer wat geleerd Overigens kijken ze dus niet naar alle headers die de client meestuurt, maar dus wel naar de compression headers.
[Reactie gewijzigd door borft op dinsdag 15 mei 2012 12:24]
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
