Localhost of eigen db-server

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

.NET Developer / Innovatieve software / Virtual Re

Functieomschrijving Als .Net developer werken aan innovatieve software waar onder andere gebruik gemaakt wordt van Virtual Reality? Bijdragen aan een organisatie waar je uitgedaagd wordt om continu verbeteringen en ontwikkelpunten te ontdekken en door te voeren? Werken in de omgeving Putten? Reageer dan nu voor meer informatie! Het pro-actief aandragen van verbeteringen voor de bestaande applicatie; Ontwikkelen van nieuwe functionaliteiten; Doorvoeren van aanpassingen en wijzigingen; Verantwoordelijk voor koppelingen met andere systemen; Op de hoogte blijven van technische ontwikkelingen. Functie-eisen Hbo werk- en denkniveau; Een afgeronde IT gerelateerde opleiding; Minimaal 1 jaar professionele ervaring als developer; Aantoonbare kennis van C#; Initiatiefrijke

Bekijk vacature »

George van Baasbank

George van Baasbank

22/12/2012 12:01:53
Quote Anchor link
Goededag allemaal,

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
 
PHP hulp

PHP hulp

17/09/2019 03:33:20
 
Bart V B

Bart V B

22/12/2012 12:12:38
Quote Anchor link
als je localhost moet opgeven, dan zit de database server op de zelfde server dan waar jou site op word gehost.
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
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

22/12/2012 19:32:07
Quote Anchor link
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.
 

22/12/2012 21:05:23
Quote Anchor link
Of als je bij mijn domein zit, kan je indien mogelijk beter sqlite gebruiken :)
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.
Gewijzigd op 22/12/2012 21:13:27 door
 
George van Baasbank

George van Baasbank

22/12/2012 21:17:28
Quote Anchor link
Een van mijn queries doet er bij mijndmein 3 seconden over en bij de localhost-provider ruin 32 seconden.
 

22/12/2012 22:22:22
Quote Anchor link
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?
Gewijzigd op 22/12/2012 22:23:04 door
 
Bart V B

Bart V B

23/12/2012 07:45:07
Quote Anchor link
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..
 
George van Baasbank

George van Baasbank

23/12/2012 09:29:40
Quote Anchor link
Hallo,
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.
 
Bart V B

Bart V B

23/12/2012 09:56:22
Quote Anchor link
Juist..
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:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
mysql -u [ USERNAME ] -p
(password)...
USE [ DATABASENAAM ]
en dan je query uitvoeren
Gewijzigd op 23/12/2012 09:57:38 door Bart V B
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

23/12/2012 10:59:48
Quote Anchor link
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:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
<?php
//$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
 
Bart V B

Bart V B

23/12/2012 16:26:01
Quote Anchor link
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:

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. ;)
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

23/12/2012 17:59:38
Quote Anchor link
Als ik George goed begrijp wil ie de 'prestaties' van 2 hostproviders vergelijken.
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.
 
George van Baasbank

George van Baasbank

24/12/2012 08:40:26
Quote Anchor link
De door mij opgegeven tijden zijn handmatig met een horloge gemeten gewoon via beide websites. Dus geen tools e.d.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

24/12/2012 08:57:15
Quote Anchor link
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.
 
George van Baasbank

George van Baasbank

27/12/2012 08:59:37
Quote Anchor link
Ik heb mijn queries nog eens nader bekeken. Onderstaande query is de boosdoener. Het uitvoeren van deze query duurt 18 seconden.

Heb ik hier nu iets onjuist gedaan?

Code (php)
PHP script in nieuw venster Selecteer het PHP script
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
// 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);
 
No One

No One

27/12/2012 09:04:00
Quote Anchor link
Heb je die Joins echt nodig? tenslotte heb je alleen s.text nodig...
 
George van Baasbank

George van Baasbank

27/12/2012 09:09:25
Quote Anchor link
Oorzaak wellicht gevonden: Indexen op de zgn ON-velden leveren een tijdwinst van 18 seconden op.

Bedankt voor de discussie en suggesties.


George
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

27/12/2012 13:39:11
Quote Anchor link
Het execution plan uit een ander topic van jou:
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?


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
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.