PDA

Bekijk Volledige Versie : site's laden soms traag



copyfile
20/02/11, 01:24
Ik draai al een tijdje een vps met onderstaande specs. Werkt prima maar merk dat somige van mijn site's vaak traag werken. Nu zijn dit wel site's die vrij druk bezocht worden en veel mysql connecties maken maar zou graag de echte oorzaak vinden om het op te lossen. Ik weet dat een hoop natuurlijk in een goede php code zit maar zou graag eerst de server kant bekijken. Die site b.v. doet er soms 4a5 sec. over om te laden en dan is het een site met weinig plaatjes. Ik vroeg me daarom af of jullie misschien met onderstaande screenshots van ServerDenisty kunnen zien of ergens iets fout gaat/het systeem te kort komt.

Specs :
Hoofd server details
CPU` s: 24 x Nehalem Quad core 2.26 Ghz
DDR3: 144 x 4096 MB ( 589 GB DDR3 )
SAN: 2 x 4 TB RAID6

Vps :
1 Core
1024 MB DDR
Centos 5.0* Server
1 IP-adres

Screenshots :
http://i51.tinypic.com/103fsiv.jpg

http://i56.tinypic.com/14yak9h.jpg

http://i54.tinypic.com/2hd87ir.jpg

xaban
20/02/11, 01:32
De server heeft zeer nette specs kwa CPU en Memory, wij weten echter niet uit hoeveel schijven de RAID 6 bestaat, dat kan een bottleneck zijn.

Voer het volgende eens uit en post de resultaten:
dd if=/dev/zero of=/tmp/test.bin bs=1M count=2000

Let er wel op dat je hiermee 2GB naar /tmp schrijft.

copyfile
20/02/11, 02:08
[root@ ~]# dd if=/dev/zero of=/tmp/test.bin bs=1M count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB) copied, 5.30985 seconds, 395 MB/s
[root@ ~]#

Lijkt me niet het probleem dus. Is die load die best vaak boven de 1.0 piekt geen probleem ? En hoe moet ik die file in tmp weer verwijderen ?

xaban
20/02/11, 02:50
[root@ ~]# dd if=/dev/zero of=/tmp/test.bin bs=1M count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2.1 GB) copied, 5.30985 seconds, 395 MB/s
[root@ ~]#

Lijkt me niet het probleem dus. Is die load die best vaak boven de 1.0 piekt geen probleem ? En hoe moet ik die file in tmp weer verwijderen ?

395MB/s is zeer netjes.

Verwijderen: rm -r /tmp/test.bin

rimote
20/02/11, 11:47
Op zich is een load boven de 1 niet erg, maar het kan wel een zekere vertraging rechtvaardigen. Je zou kunnen vergelijken hoe lang de laadtijd is van een specifieke pagina bij zowel een lage load (onder de 0.5) en als bij een hoge load (boven de 1). Hiervoor kan je wellicht Firefox plugin Firebug gebruiken met de 'Net' optie. Die geeft inzage in de wijze waarop jou site wordt geladen (incl. tijden). Leeg wel steeds eerst je cache voordat je test, dat is net iets realistischer.

Ik vraag me af waardoor de load komt. Ik mis een CPU-load grafiekje. Wellicht piekt de CPU naar 100% op de momenten van een hoge load. Dan zou het dat kunnen zijn. Ook een uitdraai van het commando 'top' op drukke momenten kan wat meer inzicht verschaffen. Je geheugen kan het in ieder geval niet zijn. Ook al is het in een virtuele omgeving vaak wel iets trager.

Ook het netwerkverkeer kan de oorzaak zijn. Wellicht is de switch/netwerkkaart een beetje overbelast. Bekijk eens je ping en doe een downloadtest van een groot bestand. Dit natuurlijk weer op momenten dat de load laag is en op momenten dat hij hoog is. Als de download langzaam gaat, kan je je site tijdelijk uit zetten (Firewall dichtzetten met jou IP gewhitelist. De load zal dan omlaag moeten gaan en als de download nog steeds traag is en de ping hoog dan is op drukke momenten het netwerk aardig belast.

Je kan het ook neerleggen bij je host. Vaak verplaatsen ze klanten die 'mopperen' op een snellere minder belaste server in het netwerk. Ook je SQL efficiƫnter maken en eventueel caching en andere websiteoptimalisatie-technieken kunnen je helpen weer sneller te worden.

basdoorn
22/02/11, 14:19
Performance problemen zijn altijd lastig te ontdekken, maar 4-5 seconden is zo lang dat het misschien wel doenbaar is in dit geval. Heb je die 4-5 seconden op willekeurige momenten, of vooral als je de server weer voor het eerst na een tijdje aanspreekt? Een load onder de 3 lijkt me niet genoeg reden voor een vertraging van 4-5 seconden zoals je aangeeft, tenzij het de harddisk is die langzaam reageert. Wat dat betreft is toegangstijd ook een heel ander beest dan MB/s. Als het incidenteel is zou je bijvoorbeeld een uur lang prima reactietijden kunnen hebben van 10-20ms voor een random disk read, met eens per uur opeens 5 seconden vertraging. Je kunt misschien een apache load test starten en kijken wat je gemiddelde en maximale reactietijd is. Anders zou je iets als nagios kunnen installeren en een scriptje maken dat de harddisk benadert en de reactietijd rapporteert, met een waarschuwing wanneer dit te lang duurt. Als je dan ziet dat je daarbij soms (enorme) pieken hebt kun je weer verder zoeken op de server en/of de leverancier daarmee confronteren.

Is dit trouwens vanaf meerdere locaties en bij meerdere mensen het geval, of merk je het alleen vanaf 1 plek? In dat laatste geval moet je zeker ook de eigen internetverbinding en daar gebruikte DNS servers niet uitsluiten, vooral DNS servers met kuren kunnen nog wel eens zo'n effect geven, wanneer je pas de 2e keer een IP adres voor de hostname krijgt zit daar vaak 2-5 seconden vertraging in. Om dit uit te sluiten zou je de website eens op IP adres kunnen benaderen, of de naam-IP koppeling tijdelijk in je hosts file opnemen als dat eerste geen optie is.

copyfile
20/03/11, 18:58
Ben nog steeds met dit probleempje bezig en heb vandaag een test server thuis online gehad op mijn Ziggo 10mbit upload lijn (Dell R200 Xeon 3.0ghz dualcore, 4gb geheugen). Heb wat mensen laten testen en komen met mijn vps op laadtijden van rond de 8 sec. en op mijn thuis server hooguit 1 sec. Scheelt dus wel enorm ! Nu kwam ik er bij het over zetten van de database achter dat deze database 15mb is. Zou hier ook niet een grote bottleneck zitten ? Want het is nu wel duidelijk dat mijn vps niet voldoende meer is voor mijn site's !

t.bloo
20/03/11, 20:01
15 MB is niets voor een database, heb hier vele databases van honderden MB die gewoon snel presteren.

The-BosS
20/03/11, 21:34
15 MB is niets voor een database, heb hier vele databases van honderden MB die gewoon snel presteren.

15MB is inderdaad niets, ik heb zelf een mysql database van 8GB en die doet het even vlug of een database van 100MB. Let er wel op dat je goede index en query's gebruikt, anders kan dit wel een bottleneck zijn.

maikelh87
20/04/11, 13:35
Kan ook te maken hebben met de opbouw van de site. Dit veroorzaakt meestal veel http requests hierdoor wordt een site traag.

brammetjeh
20/04/11, 13:53
Zitten er veel flash elementen in de site of misschien koppelingen met andere media? bijvoorbeeld twitter facebook en dergelijke. Hier zitten vaak ook vertragingen op

Pantsy
20/04/11, 14:36
De sites die er last van hebben zijn neem ik aan enkel dynamic sites? (dus geen statische) Word er toevallig gebruik gemaakt van een kant en klaar (opensource) software pakket? Ik noem even wat resource vreters wanneer deze (en de server/vps) niet zijn geoptimaliseerd: joomla, magento, wordpress.

Ramon Fincken
20/04/11, 15:12
Geef de URL(s) eens?

@Pantsy: WP werkt prima hoor, maar caching haalt gewoon altijd je load omlaag :)

Pantsy
20/04/11, 19:00
Klopt... vandaar de little remark "wanneer deze niet zijn geoptimaliseerd" =)