Vraag Hoe laadt u testen en capaciteitsplanning voor websites?


Dit is een canonieke vraag over capaciteitsplanning voor websites.

Verwant:

Wat zijn enkele aanbevolen hulpmiddelen en methoden voor capaciteitsplanning voor websites en webapplicaties?

Voel alsjeblieft vrij om verschillende tools en technieken voor verschillende webservers, frameworks, etc. te beschrijven, evenals best-practices die van toepassing zijn op webservers in het algemeen.


111
2018-01-16 22:49


oorsprong




antwoorden:


Het korte antwoord is: niemand kan deze vraag beantwoorden behalve jij.

Het lange antwoord is dat het benchmarken van uw specifieke werkbelasting iets is dat u zelf moet ondernemen, omdat het een beetje lijkt op: "Hoe lang is een touwtje?".

Een eenvoudige statische website van één pagina kan op een Pentium Pro 150 worden gehost en elke dag nog duizenden vertoningen ontvangen.

De basisaanpak die u moet volgen om deze vraag te beantwoorden is om proberen het en kijk wat er gebeurt. Er zijn veel tools die je kunt gebruiken om je systeem kunstmatig onder druk te zetten om te zien waar het gespen is.

Een kort overzicht hiervan is:

  • Zet je scenario op zijn plaats
  • Toezicht toevoegen
  • Voeg verkeer toe
  • Evalueer de resultaten
  • Remediate op basis van resultaten
  • Spoel, herhaal tot redelijk gelukkig

Zet je scenario op zijn plaats

Kortom, om een ​​lading te testen, heb je iets nodig om te testen. Stel een omgeving in om te testen tegen. Dit moet, indien mogelijk, een redelijk close raden van uw productiehardware zijn, anders wordt uw gegevens extrapoleerd.

Stel uw servers, accounts, websites, bandbreedte, enz. In. Zelfs als u dit op VM's doet, is dat OK zolang u bereid bent om uw resultaten te schalen.

Dus ik ga een mid-powered virtuele machine (twee cores, 512 MB RAM, 4 GB HDD) opzetten en mijn favoriete load balancer installeren, haproxy binnen Red Hat Linux op de VM.

Ik ga ook twee webservers achter de load balancer plaatsen die ik ga gebruiken om de load balancer te testen. Deze twee webservers zijn identiek opgezet voor mijn live systemen.

Toezicht toevoegen

U hebt een aantal statistieken nodig om te controleren, dus ik ga meten hoeveel aanvragen doorkomen op mijn webservers en hoeveel verzoeken ik per seconde kan doornemen voordat gebruikers een responstijd van meer dan twee seconden krijgen.

Ik ga ook RAM-, CPU- en schijfgebruik controleren op de haproxy bijvoorbeeld om ervoor te zorgen dat de load balancer de verbindingen kan verwerken.

Hoe dit te doen hangt sterk af van uw platforms en valt buiten de reikwijdte van dit antwoord. Mogelijk moet u logbestanden van webservers controleren, prestatiemeteritems starten of vertrouwen op de rapportagemogelijkheid van uw stresstest-tool.

Een paar dingen die u altijd wilt controleren:

  • CPU gebruik
  • RAM-gebruik
  • Schijfgebruik
  • Disk latency
  • Netwerkgebruik

U kunt er ook voor kiezen om SQL-deadlocks te bekijken, tijden te zoeken enzovoort, afhankelijk van wat u specifiek test.

Voeg verkeer toe

Dit is waar dingen leuk worden. Nu moet u een testbelasting simuleren. Er zijn veel gereedschap dat kan dit, met configureerbare opties:

Kies een nummer, elk nummer. Laten we zeggen dat je gaat zien hoe het systeem reageert met 10.000 hits per minuut. Het maakt niet uit welk nummer u kiest, want u gaat deze stap vele malen herhalen, waarbij u dat aantal omhoog of omlaag aanpast om te zien hoe het systeem reageert.

Idealiter moet u deze 10.000 verzoeken over meerdere laadtestclients / knooppunten distribueren, zodat een enkele client geen knelpunt van verzoeken wordt. Bijvoorbeeld JMeter's Testen op afstand biedt een centrale interface van waaruit verschillende clients van een controlerende Jmeter-machine kunnen worden gestart.

Druk op de magie Gaan knop en zie je webservers wegsmelten en crashen.

Evalueer de resultaten

Dus nu moet je teruggaan naar je statistieken die je in stap 2 hebt verzameld. Je ziet dat met 10.000 gelijktijdige verbindingen, je haproxy box zweet nauwelijks, maar de reactietijd met twee webservers is een aanraking van meer dan vijf seconden. Dat is niet cool - onthoud dat uw responstijd twee seconden duurt. We moeten dus enkele wijzigingen aanbrengen.

saneren

Nu moet je je website met meer dan twee keer versnellen. U weet dus dat u moet opschalen of opschalen.

Opschalen, grotere webservers, meer RAM, snellere schijven.

Schaal meer servers op om uit te schalen.

Gebruik uw statistieken van stap 2 en testen om deze beslissing te nemen. Als u bijvoorbeeld ziet dat de latentie van de schijf enorm was tijdens het testen, weet u dat u moet opschalen en snellere harde schijven krijgt.

Als u zag dat de processor tijdens de test voor 100% zat, moet u misschien opschalen om extra webservers toe te voegen om de druk op de bestaande servers te verminderen.

Er is geen algemeen goed of fout antwoord, er is alleen wat goed voor je is. Probeer schaalvergroting, en als dat niet werkt, schaal in plaats daarvan. Of niet, het is aan jou en sommigen die buiten de kaders denken.

Laten we zeggen dat we gaan opschalen. Dus ik besluit mijn twee webservers te klonen (het zijn VM's) en nu heb ik vier webservers.

Spoelen, herhalen

Begin opnieuw vanaf stap 3. Als u merkt dat de dingen niet gaan zoals u verwachtte (we hebben bijvoorbeeld de webservers verdubbeld, maar de reactietijden zijn nog steeds meer dan twee seconden), en kijk dan naar andere knelpunten. U hebt bijvoorbeeld de webservers verdubbeld, maar hebt nog steeds een waardeloze databaseserver. Of, je hebt meer VM's gekloond, maar omdat ze zich op dezelfde fysieke host bevinden, heb je alleen meer aandacht gekregen voor de servers.

U kunt deze procedure vervolgens gebruiken om andere delen van het systeem te testen. Probeer de webserver direct te raken in plaats van de load balancer te raken. of de SQL-server met behulp van een SQL-benchmarkingstool.


119
2018-04-29 14:05



Dit is uitstekend geschikt voor belastingtests, maar zegt weinig over capaciteitsplanning. Wie kan schrijven over de schaalbare architectuur van Google, die al in een vroeg stadium werd bedacht, of de alternatieven die minder en duurdere dozen gebruiken. - rleir


Capaciteitsplanning begint met meten, in dit geval reactietijd versus belasting. Als u eenmaal weet in welke mate de programma's langzamer werken met laden, wat GEEN lineaire functie is, kunt u een doel voor de responstijd selecteren en vervolgens ontdekken welke bronnen er nodig zijn om dat doel te bereiken voor een bepaalde hoeveelheid lading.

Prestatiemeting gebeurt altijd met tijd eenheden, als

  • ze zijn waar gebruikers om geven
  • ze kunnen op en neer worden geschaald

Zaken zoals% CPU en IOPS zijn systeemspecifiek, dus u gebruikt ze alleen wanneer u het systeem hebt gepland en hebt gemeten in de pre-productie, om te fungeren als een 'surrogaat' voor het ding waar u om geeft, tijd.


9
2018-04-21 22:32





Capaciteitsplanning is een lastig beest. Het is evenveel wetenschap als kunst (als het zeker een donkere is).

Uw beste geval is dat u weloverwogen beslissingen neemt en fortuin / geluk moedigt je aan door de realiteit te laten voldoen aan je aannames. Als je capaciteit aannames nodig heeft die overeenkomen met de werkelijkheid, zie je eruit als een mystieke yogi. Helaas, als uw aannames de realiteit overschrijden, lijkt het alsof u te ver bent gegaan en te veel hebt uitgegeven. Meer helaas, als je aannames onder de uiteindelijke realiteit liggen (of anderszins incorrect zijn), zul je de capaciteit missen die je nodig hebt, en zal je moeten klauteren om de mislukkingen van je kreunende infrastructuur te verzachten, waardoor je eruit ziet als een gebrek aan competentie.

Geen druk...

Helaas is de duistere kunst van capaciteitsplanning meer dan redelijkerwijs kan worden gedestilleerd in een enkel Server Fault-antwoord; echt, het is een onderwerp dat boeken waardig is.

Gelukkig is er zo'n boek: "De kunst van capaciteitsplanning"


8





Om het bericht van Mark Henderson uit te breiden, schrijf ik dit specifiek voor Apache. Om te herhalen wat hij zei: "Het korte antwoord is: niemand kan deze vraag beantwoorden behalve jij." De tekst van dit antwoord is zwaar ontleend aan mijn antwoord op een soortgelijke vraag over a De prestaties van Drupal-website.

Apache configureren met Mod_Prefork

Apache is aantoonbaar een van de (zo niet de) meest populaire webserver die beschikbaar is. Het is open source en wordt nog steeds actief onderhouden. Je kunt het zowel op Linux- als op Windows-besturingssystemen uitvoeren, maar is populairder in de Linux / Unix-wereld.

Je zou moeten nooit gebruik een kant-en-klare Apache-config. Je moet altijd Apache afstemmen op je site. Het belangrijkste Apache-configuratie bestand op CentOS bevindt zich op /etc/httpd/conf/httpd.conf, en het belangrijkste Apache-configuratiebestand op Ubuntu-systemen bevindt zich meestal op /etc/apache2/apache2.conf. Aanvullende configuratiebestanden worden gebruikt voor dingen zoals Virtuele hosts.

Zoals veel software is Apache gebouwd om flexibel te zijn en aangepast aan de behoeften van een specifieke website. Er zijn verschillende Multi-Processing Modules dat Apache kan worden geconfigureerd om te gebruiken om te binden aan een netwerkpoort en de verzoeken te accepteren en te verwerken.

Meestal op standaard Apache-installaties die bij CentOS- en Ubuntu-servers worden geleverd, is de MPM "mod_prefork"wordt gebruikt. Ervan uitgaande dat u mod_prefork gebruikt (als u het niet zeker weet, is dat waarschijnlijker, maar alleen u kunt dat bepalen) Hier zijn de basisprincipes voor het configureren:

  • Bereken de maximale hoeveelheid geheugen die Apache kan gebruiken.
  • Test uw website zwaar en bepaal hoeveel geheugen elk Apache-proces gebruikt (met behulp van de top).
  • Neem het Apache-proces bovenaan dat het meeste geheugen gebruikt, voeg er een klein beetje aan toe en deel dan je eerste nummer (maximale hoeveelheid geheugen dat je Apache wilt gebruiken) met dit nieuwe nummer.
  • Het nummer dat u krijgt, zou uw nummer moeten zijn MaxClients & ServerLimit variabelen.

Dit is zeker niet het antwoord op het einde. Uw Apache-server afstemmen kost tijd en vereist ervaring om precies goed te krijgen.


5



geheugengebruik alleen gebaseerd op de bovenkant is enigszins gebrekkig, controleer f.e. stackoverflow.com/questions/7880784/... bovendien zou je misschien het pythonscript "ps_mem.py" in plaats van top voor geheugengebruik willen gebruiken, of zelfs de waarden directy gebruiken die aan het proces onder / proc zijn gekoppeld - Dennis Nolte
Het hele antwoord is de moeite waard vanwege de notitie die je hebt toegevoegd: "Gebruik nooit een standaard Apache-configuratie". We kunnen dit nooit genoeg benadrukken. - ezra-s


Ik zou ook willen voorstellen om met de Architects & Engineers te spreken die de applicaties ontworpen / gebouwd hebben om knelpunten, single points of failure en licentiebeperkingen te identificeren.


0