schaalbare-website

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
schaalbare-website [2017/04/26 11:06]
matthias aangemaakt
schaalbare-website [2020/10/17 11:12] (current)
Line 1: Line 1:
 ===== Do's en dont's voor een schaalbare website ===== ===== Do's en dont's voor een schaalbare website =====
 +\\ 
 +{{:​resources.jpg?​nolink&​400|}} 
 +\\
 Do's Do's
  
Line 7: Line 9:
   - Probeer de applicatie/​databaseserver zoveel mogelijk te ontzien   - Probeer de applicatie/​databaseserver zoveel mogelijk te ontzien
   - Voor grote files zoals video'​s het download platform gebruiken   - Voor grote files zoals video'​s het download platform gebruiken
 +  - Gebruik voor de front-end een performance benchmark-tool
 +  - Grote afbeeldingen optimaliseren
 +  - Gebruik optimalisaties voor je CMS
  
  
Line 13: Line 18:
   - Uitgaande calls naar andere websites   - Uitgaande calls naar andere websites
   - de applicatieserver alle inkomende requests af laten handelen.   - de applicatieserver alle inkomende requests af laten handelen.
- 
-Lees vooral eerst het verhaaltje over 
-[[.:​cluster-hosting#​http_loadbalancing|load balancing]]. Hopelijk geeft dit voldoende duidelijkheid zodat de onderstaande maatregelen wat duidelijker worden. Maar eerst nog wat meer uitleg over wat de frontproxies zijn en doen: 
  
  
 +Voor de liefhebbers hebben wij een wat meer in-depth uitleg over [[.:​schaalbare-website_loadbalancing|load balancing]]. Het belangrijkste om te weten dat de loadbalancers ervoor zorgen dat de frontproxies redundant kunnen worden uitgevoerd. Maar eerst nog wat meer uitleg over wat de frontproxies zijn en doen:
 +\\
 +Specifiek voor Wordpress heeft Nginx een [[https://​www.nginx.com/​blog/​9-tips-for-improving-wordpress-performance-with-nginx/​|interessant artikel]] geschreven.
 ==== (front-)Proxies ==== ==== (front-)Proxies ====
  
Line 24: Line 29:
 Achter deze front proxies bevinden zich de applicatie servers (workers), Achter deze front proxies bevinden zich de applicatie servers (workers),
 hier draaien de ruby, php, java, applicaties. hier draaien de ruby, php, java, applicaties.
-__De proxies kunnen statische content (plaatjes ​enzo) direct zelf uitserveren__;​+__De proxies kunnen statische content (plaatjes, css etc.) direct zelf uitserveren__;​
 zaken die ze niet zelf af kunnen handelen moeten ze doorzetten naar de zaken die ze niet zelf af kunnen handelen moeten ze doorzetten naar de
 workers/​applicatieservers. ​ Deze workers zijn workers/​applicatieservers. ​ Deze workers zijn
-geoptimaliseerd ​om hun rekenwerk zo snel mogelijk te kunnen doen,+geschikt ​om hun rekenwerk zo snel mogelijk te kunnen doen,
 __maar ze zijn niet ingericht om veel verbindingen tegelijkertijd open te hebben __maar ze zijn niet ingericht om veel verbindingen tegelijkertijd open te hebben
-staan.__ ​(want daar hebben we de proxies voor)+staan.__ ​Dit komt doordat een worker over het algemeen veel meer resources nodig heeft per connectie. ​
 \\ \\ \\ \\
  
Line 40: Line 45:
 \\ \\ \\ \\
 **Optimale Applicatieserver/​worker performance** \\ **Optimale Applicatieserver/​worker performance** \\
-Als er werk door een worker gedaan moet worden is het belangrijk dat deze dit zo snel mogelijk doet. Want het aantal ​webserver ​slots in de+Als er werk door een worker gedaan moet worden is het belangrijk dat deze dit zo snel mogelijk doet. Want het aantal ​'slots' van de
 workers is maar beperkt; hoe korter een webserver slot in een worker bezet wordt gehouden voor het afhandelen van een request, hoe meer requests een workers is maar beperkt; hoe korter een webserver slot in een worker bezet wordt gehouden voor het afhandelen van een request, hoe meer requests een
 worker per seconde kan afhandelen. Zolang een worker geen externe afhankelijkheden heeft, is de snelheid waarmee deze requests kan afhandelen worker per seconde kan afhandelen. Zolang een worker geen externe afhankelijkheden heeft, is de snelheid waarmee deze requests kan afhandelen
 puur beperkt door de CPU snelheid van het systeem waar de worker op draait. Als een worker request moet doen naar een database of andere website is die '​externe bron' de beperkende factor. Dat betekent dat alle acties waarbij een worker weer zaken aan iemand anders gaat vragen een risico zijn.  ​ puur beperkt door de CPU snelheid van het systeem waar de worker op draait. Als een worker request moet doen naar een database of andere website is die '​externe bron' de beperkende factor. Dat betekent dat alle acties waarbij een worker weer zaken aan iemand anders gaat vragen een risico zijn.  ​
  
-**Database queries.**+===== Dont's ===== 
 + 
 +**Inefficiente ​Database queries.**
 Stel bijvoorbeeld dat een worker een query naar een database doet. Op zich heel Stel bijvoorbeeld dat een worker een query naar een database doet. Op zich heel
 normaal natuurlijk. __Maar terwijl de worker op antwoord van de normaal natuurlijk. __Maar terwijl de worker op antwoord van de
Line 81: Line 88:
  
 Hoe valt dit nou allemaal te voorkomen? Hoe valt dit nou allemaal te voorkomen?
 +
 +===== Do's =====
  
 === Site statisch maken === === Site statisch maken ===
 Door zoveel mogelijk werk aan de proxies te laten wordt al een hoop gewonnen. Door zoveel mogelijk werk aan de proxies te laten wordt al een hoop gewonnen.
 Zorg ervoor dat plaatjes direct door de proxies uitgeserveerd kunnen worden, Zorg ervoor dat plaatjes direct door de proxies uitgeserveerd kunnen worden,
-zonder dat dit door HTTP hoeft.+zonder dat dit door PHP hoeft.
 Idem voor platte html, stylesheets e.d. Idem voor platte html, stylesheets e.d.
 +Daarom zorgen wij er standaard voor dat files met de extensies *.gif, *.html, *.htm, *.jpg, *.png, *.css, *.js, *.txt, *.swd, *.flv, *.xml, *.ico, *.pdf, *.gz, *.mp3 door de proxy uitgeserveerd worden.
 +
 +=== Data pre-renderen ===
 +Data die wel wijzigt, maar voor alle bezoekers hetzelfde is kan
 +ge-pre-rendered worden. Dat wil zeggen dat er een achtergrondproces
 +("een cronjob"​) is die van tijd tot tijd een nieuwe versie van de data
 +rendered en ergens neerzet waar deze als statische data uitgeserveerd
 +kan worden. Op die manier hoeft deze data niet voor elke indiciduele
 +bezoeker apart gerendered te worden, wat veel belasting scheelt.
  
 === File Caching + herschrijfregels === === File Caching + herschrijfregels ===
Line 116: Line 134:
 Goed werkende HTTP Caching is mogelijk vanaf apache-2.4, maar het is onze ervaring dat Nginx de caching nog effectiever afhandelt. ​ Goed werkende HTTP Caching is mogelijk vanaf apache-2.4, maar het is onze ervaring dat Nginx de caching nog effectiever afhandelt. ​
   * De [[#​gouden_frontproxy_regels_mbt_java_hosting|regels]] mbt java hosting en caching zijn hier ook van toepassing   * De [[#​gouden_frontproxy_regels_mbt_java_hosting|regels]] mbt java hosting en caching zijn hier ook van toepassing
 +
 +=== Gebruik voor de front-end een performance benchmark-tool ===
 +
 +Op [[https://​varvy.com|varvy pagespeed]] is niet alleen een benchmarktool beschikbaar,​ ook heeft deze site uitleg over alle elementen die invloed hebben op de performance. ​
 +
 +[[http://​yellowlab.tools]] is de meest kritische benchmarktool. ​
 +
 +[[https://​developers.google.com/​speed/​pagespeed/​insights/​ | Pagespeed Insights van Google ]] is de minst uitgebreide tool, maar wordt wel veel gebruikt. ​
 +
 +Belangrijke kanttekeningen voor deze tools: alleen de frontend performance wordt gemeten; niet de backend. De schaalbaarheid wordt hier niet mee gemeten. Sterker nog er worden aanbevelingen gedaan die de schaalbaarheid verslechteren zoals mod_gzip/​compressie. ​
 +
 +=== Gebruik optimalisaties voor je CMS ===
 +Bijvoorbeeld:​
 +  * [[https://​www.keycdn.com/​blog/​speed-up-drupal/​ | Drupal optimalisatie]] //De snelle hosting bieden wij al en wat men onder een CDN verstaat is vergelijkbaar met onze proxy setup. //
 +Er zijn voor veel populaire CMS'en modules beschikbaar die plaatjes kunnen optimaliseren of resizen, caching kunnen doen en andere optimalisaties. ​
  
 === Memcached === === Memcached ===
Line 121: Line 154:
 zeer geschikt om zware database queries in te cachen, om zo de load zeer geschikt om zware database queries in te cachen, om zo de load
 op de database te verminderen en daarmee de workers sneller te maken. op de database te verminderen en daarmee de workers sneller te maken.
 +
  • schaalbare-website.1493197617.txt.gz
  • Last modified: 2020/10/17 11:11
  • (external edit)