Localhost of eigen db-server
Ik heb een vraag over het gebruik van de databaseserver door het hostingbedrijf.
Zelf zit ik bij MijnDomein en daar moet ik als databaseserver mijn "eigen" databaseserver opgeven, in de trant van db.eigensite.nl. Bij het hostingsbedrijf van onze vereniging geef ik als databaseserver "Localhost" op.
Wat is nu het essentiële verschil hiertussen?? Zelf heb ik het gevoel dat het gebruik van Localhost minder performance danwel CPU-ruimte heeft als een "eigen" databaseserver.
Is mijn veronderstelling juist? De vereniging overweegt evt. over te stappen naar een andere hoster.
George
Als je die apart moet aangeven dan zal waarschijnlijk de database server op een andere server staan.
Het voordeel is dat de server apart staat van de httpd server, dus daar zou snelheidswinst kunnen zitten.
Ook als de server er een keer mee ophoud heb je maar een deel dat plat ligt.
(hoewel zoiets altijd vervelend is natuurlijk.)
Een server heeft een bepaald stuk geheugen, dus als deze httpd, database, en mail bijvoorbeeld moet afhandelen, dan loopt dat al aardig vol. Met maar 1 taak(lees server(computer) per onderdeel) heb je dat niet zo.
Gewijzigd op 22/12/2012 12:16:03 door Bart V B
Bart V B op 22/12/2012 12:12:38:
Het voordeel is dat de server apart staat van de httpd server, dus daar zou snelheidswinst kunnen zitten.
Dan moet je wel een zeer supersnel netwerk hebben, en dan heb ik niet over 1 gbit.
Dit aangezien ik in het verleden heb meegemaakt met een klant van mij dat hun db server er meer uit ligt dan online is :)
Over het algemeen bevind de database zich op dezelfde server bij normale webhosting, bij sommigen niet zoals mijn domein. Is opzicht geen enkel probleem. Dus hierbij is het niet localhost maar de db server die zij aanbieden. Helaas is/was het bij de genoemde provider wel zo dat hun db server er regelmatig uitlicht.
Een van mijn queries doet er bij mijndmein 3 seconden over en bij de localhost-provider ruin 32 seconden.
Quote:
Een van mijn queries doet er bij mijndmein 3 seconden over en bij de localhost-provider ruin 32 seconden.
En betreft het dezelfde query met dezelfde database, waarbij het enigste verschil is dat ze op een andere server(s) staan?
Quote:
Een van mijn queries doet er bij mijndmein 3 seconden over en bij de localhost-provider ruin 32 seconden.
Hoe controleer je dat?
via de commandline? Of via een zgn. handig tooltje zoals PMA?
Verder is het van belang dat je weet welke versie erop staat.
Verschil zou ook kunnen zitten in de hardware. Zoals geheugen, harddisks e.d.
Dus met alleen het verschil van 1 regeltje code zou het niet moeten zijn.
Daar zou je meer van de achtergrond moeten weten..
Ik test m.b.v. Phpmyadmin. Beide platforms hebben dezelfde bestanden en databases. Ik heb beide applicaties tijdens de test gelijktijdig openstaan en ik draai de query naast elkaar.
Daar was ik dus al bang voor.
Zo kun je niet meten.
Wat je nu aan het doen bent, is appels met peren vergelijken.
Met een redelijk eenvoudige query volstaat PMA (nog) wel, maar worden ze wat groter dan zal je dus anders moeten testen.
Om het zuiver te doen doe je dat met de mysql server zelf.
Dus op commandline. Dan heb je geen vervuiling van andere dingen zoals het php, en apache.
Je weet nl niet welke hardware er word gebruikt. Hoeveel geheugen hebben de machines?
Dus om het goed te testen zal je op de commandline moeten geraken.
Ik weet niet of je daar bij kunt? Is het een dedicated, VPS of shared hosting?
Want bij Shared hosting krijg je namelijk vaak (beter gezegd, nooit) die rechten niet.
Je zou het eventueel lokaal kunnen testen afhankelijk van je OS zou het iets moeten zijn als:
Gewijzigd op 23/12/2012 09:57:38 door Bart V B
Nu weet ik niet hoe PMA de tijd berekent, maar als er twijfels zijn kan je ook zelf een testje maken:
Code (php)
1
2
3
4
5
6
7
2
3
4
5
6
7
<?php
//$sql = de query
$start = microtime(true);
$result = mysql_query($sql);
if ($result !== false) {
echo microtime(true) - $start;
?>
//$sql = de query
$start = microtime(true);
$result = mysql_query($sql);
if ($result !== false) {
echo microtime(true) - $start;
?>
Als dan het verschil nog zo groot is, draait die ene host op een roestbak.
Gewijzigd op 23/12/2012 16:42:11 door Ger van Steenderen
Quote:
Ik vraag me af waarom je stelt dat je persee op de commandline moet testen, het gaat tenslotte om de totale performance en niet van de query op zich.
Nu weet ik niet hoe PMA de tijd berekent, maar als er twijfels zijn kan je ook zelf een testje maken:
Nu weet ik niet hoe PMA de tijd berekent, maar als er twijfels zijn kan je ook zelf een testje maken:
true, maar om zeker ervan te zijn dat het niet aan de query's ligt zou ik eerst kijken zonder de dingen wat zou kunnen vertragen. Een ranzig stukje php code zou al voor veel vertraging kunnen zorgen.
Dan kunnen we wel de schuld in de schoenen schuiven van de mysql server, maar dat is dan zeker uitgesloten.
Je zou dan nog iets van een eigen scriptje kunnen gebuiken zonder enig bagage zoals je laat zien.
Dan test je i.i.g. zuiverder dan met 2x phpmyadmin voor je neus en "klik" lijkt me. ;)
Als je MySQL vanaf de commandline benadert fungeert het ook als een client, maar dan je ben je altijd lokaal bezig.
Zoals ik al zei weet ik niet hoe PMA de query tijd berekent, maar het verschil tussen 3 of 32 seconden is toch wel erg groot.
De door mij opgegeven tijden zijn handmatig met een horloge gemeten gewoon via beide websites. Dus geen tools e.d.
Om een accurater resultaat te krijgen je zou mijn bovenstaande scriptje kunnen gebruiken. Dat meet de tijd die nodig is om de query naar de server te sturen en het resultaat terug te ontvangen.
Heb ik hier nu iets onjuist gedaan?
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// Bronvermelding huwelijk
if($cGeslachtPersoon == "M") {
$sql = "SELECT
s.text AS bronvermelding
FROM
ftphp__fam AS f
JOIN
ftphp__even as e
ON
f.fid = e.ifid
JOIN
ftphp__cit as c
ON
e.eid = c.lid
JOIN
ftphp__sour as s
on
c.sid = s.sid
WHERE
f.husb = '$cIdPersoon'
LIMIT 1";
} elseif($cGeslachtPersoon == "F") {
$sql = "SELECT
s.text AS bronvermelding
FROM
ftphp__fam AS f
JOIN
ftphp__even as e
ON
f.fid = e.ifid
JOIN
ftphp__cit as c
ON
e.eid = c.lid
JOIN
ftphp__sour as s
on
c.sid = s.sid
WHERE
f.wife = '$cIdPersoon'
LIMIT 1";
}
$cResultBronHuwelijk = mysql_query($sql);
if($cGeslachtPersoon == "M") {
$sql = "SELECT
s.text AS bronvermelding
FROM
ftphp__fam AS f
JOIN
ftphp__even as e
ON
f.fid = e.ifid
JOIN
ftphp__cit as c
ON
e.eid = c.lid
JOIN
ftphp__sour as s
on
c.sid = s.sid
WHERE
f.husb = '$cIdPersoon'
LIMIT 1";
} elseif($cGeslachtPersoon == "F") {
$sql = "SELECT
s.text AS bronvermelding
FROM
ftphp__fam AS f
JOIN
ftphp__even as e
ON
f.fid = e.ifid
JOIN
ftphp__cit as c
ON
e.eid = c.lid
JOIN
ftphp__sour as s
on
c.sid = s.sid
WHERE
f.wife = '$cIdPersoon'
LIMIT 1";
}
$cResultBronHuwelijk = mysql_query($sql);
Heb je die Joins echt nodig? tenslotte heb je alleen s.text nodig...
Bedankt voor de discussie en suggesties.
George
George van Baasbank op 19/12/2012 09:07:58:
Ik krijg bij explain het volgende te zien:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE n ALL NULL NULL NULL NULL 7519 Using temporary; Using filesort
1 SIMPLE i ALL NULL NULL NULL NULL 7519 Using where; Using join buffer
1 SIMPLE f ALL NULL NULL NULL NULL 3539 Using where; Using join buffer
1 SIMPLE e ALL NULL NULL NULL NULL 22514 Using where; Using join buffer
Wat kan ik hiermee?
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE n ALL NULL NULL NULL NULL 7519 Using temporary; Using filesort
1 SIMPLE i ALL NULL NULL NULL NULL 7519 Using where; Using join buffer
1 SIMPLE f ALL NULL NULL NULL NULL 3539 Using where; Using join buffer
1 SIMPLE e ALL NULL NULL NULL NULL 22514 Using where; Using join buffer
Wat kan ik hiermee?
Als je nu een EXPLAIN op bovenstaande query doet, zal je zien dat er geen ALL meer staat bij type maar ref of const, en dat er waardes verschijnen in possible_keys, key en key_len. Type ALL wil zeggen een full table scan en dit moet je waar mogelijk zien te vermijden.
Gewijzigd op 27/12/2012 13:39:40 door Ger van Steenderen