[Experts] Tips gevraagd voor grote website (PHP/MySQL)

[Verwijderd]

Beste Tweakers,

Ik ben momenteel bezig met een grote site met een aantal duizend leden. Nu heb ik wat vragen over PHP/MySQL technieken en functies en de CPU laadtijd daarbij.

Wie kan mij tips/informatie geven over de CPU laadtijd bij de volgende technieken en functies?

- include() of require() in PHP: Kost dit veel CPU laadtijd?
- fopen() om een bestand te schrijven: Kost dit veel CPU laadtijd?
- Is het veel beter om alles in één query te laden per pagina en hoe kan ik dit het beste aanpakken?
- Heeft iemand nog meer tips voor een grote site?

Alvast heel erg bedankt,

Jeroen

[ Voor 7% gewijzigd door Verwijderd op 13-05-2003 19:20 . Reden: Lijstje uitgebreid ]

[pjonk]

Verwijderd schreef op 13 May 2003 @ 19:15:
- include() of require() in PHP: Kost dit veel CPU laadtijd?

Dat hangt er vanaf. Indien je hele grote bestanden gaat includen kan dit best een behoorlijke laadtijd tot gevolg hebben. Probeer verschillende functionaliteit daarom in meerdere includes onder te brengen. Include alleen de functies die je daadwerkelijk gebruikt.

- Is het veel beter om alles in één query te laden per pagina en hoe kan ik dit het beste aanpakken?

Het is altijd een goed idee om zo min mogelijk queries per pagina te gebruiken. Bij elke query moet weer een request worden gedaan naar de (my)SQL server wat tijd kost.

Een tip bij queries:
Selecteer alleen de velden uit de database die je daadwerkelijk gebruikt. Kan ook een hoop performance schelen.

[Verwijderd]

zo min mogelijk query's maken, verdiep je eens in de wereld die mysql heet, en je zult je verbazen hoeveel dingen je al in een query kunt bepalen die je waarschijnlijk nu in een php script regelt.

zoals bijv. een query binnen een while(php) van een andere query, dan kan meestal met 1 query.
of bijv. gegevens uit 2 verschillende tables tegelijk halen, dmv:
SELECT t1.geslacht,t2.leeftijd FROM table1 t1,table2 t2 WHERE t1.naam = t2.naam

een ander punt is je database slim en goed indelen, maak gebruik van INDEX (zit ook in phpMyAdmin).

en zoals JonkieXL al zei, geen SELECT * FROM ... gebruiken, maar SELECT naam,leeftijd,geslacht FROM

enne fopen is niet zo supersnel als een paar 100 personen het script tegelijk oproepen, waar gebruik je dat voor??

www.yourme.nl

[Verwijderd]

Ik selecteer inderdaad alleen de velden die ik nodig heb, ook gebruik ik mysql_pconnect voor persistent connections, dit scheelt ook een heleboel.

Is het inderdaad de bedoeling dat alle informatie die je nodig hebt op een pagina (dus de leden informatie + de informatie van de pagina zelf) in één query binnenhaalt? Lijkt me nogal lastig.

Ik ga met cronjobs elke minuut/elk uur/elke dag informatie in HTML bestanden zetten, vandaar dat ik fopen() nodig heb.

[ Voor 57% gewijzigd door Verwijderd op 13-05-2003 19:36 ]

[Sybr_E-N]

Het kost de CPU weinig laadtijd, het is de Harddisk (file I/O) die een belangrijke factor speelt.

Tip voor voor goede queries: zorg voor een goede Database structuur, met indexen, database die genormaliseerd is, juiste primary key's zetten.

[Verwijderd]

Ik heb gelezen dat je alleen primary key's moet gebruiken als je ze echt nodig hebt, anders kost het laadtijd. Is dit zo?

[Creepy]

Verwijderd schreef op 13 May 2003 @ 19:42:
Ik heb gelezen dat je alleen primary key's moet gebruiken als je ze echt nodig hebt, anders kost het laadtijd. Is dit zo?

Nee. Het scheelt zelfs "laadtijd". Op een primary key kom standaard een index te staan, die index zorgt ervoor dat als je op een primary key selecteert/joint dat die key veel sneller opgezocht kan worden dan zonder index.

Misschien is het eens een idee om er een goed PHP en Database boek bij te zoeken? Daar staan dit soort dingen zeker wel in uitgelegd.

[whoami]

Primary keys heb je altijd nodig.
Je moet altijd een record uniek kunnen identificeren; daarnaast is het ook zo dat het selecteren op primary key de snelste manier is om een record op te halen.

[Verwijderd]

Ik heb een PHP boek en een MySQL boek en ik heb het idee dat dit aardige boeken zijn maar er wordt niets verteld over laadtijd van technieken en functies. Kennen jullie boeken waar dit wel in staat?

Dan nog een vraag over MySQL:
Als ik met een query informatie uit verschillende tabellen tegelijk selecteer, worden deze met elkaar samengevoegd. Hoe kan ik informatie uit verschillende tabellen tegelijk selecteren zonder dat ze worden toegevoegd, zodat ik gewoon 1 query heb?

Jeroen

[ Voor 43% gewijzigd door Verwijderd op 13-05-2003 19:59 . Reden: Vraag toegevoegd ]

[whoami]

Tip voor laadtijden van queries: maak zoveel mogelijk gebruik van indexen, maar plaats geen indexen waar het niet nodig is. Een index zorgt er nl. voor dat het inserten/updaten/deleten iets trager werkt.
Je plaatst best indexen op de kolommen waar je op zoekt, waar je op sorteert en waar je op joined.

Ik geloof dat er ook wel sites bestaan met specifieke tuning tips voor MySQL.


ps: je hoeft niet steeds de groeten, of je naam te zetten onder je post. Dit leest nl. niet gemakkelijk. (en is zelfs een beetje irritant)

[ Voor 16% gewijzigd door whoami op 13-05-2003 20:04 ]

[Verwijderd]

Sorry, ik ben het gewoon gewend.

[twiekert]

Verwijderd schreef op 13 mei 2003 @ 19:50:
Ik heb een PHP boek en een MySQL boek en ik heb het idee dat dit aardige boeken zijn maar er wordt niets verteld over laadtijd van technieken en functies. Kennen jullie boeken waar dit wel in staat?

Dan nog een vraag over MySQL:
Als ik met een query informatie uit verschillende tabellen tegelijk selecteer, worden deze met elkaar samengevoegd. Hoe kan ik informatie uit verschillende tabellen tegelijk selecteren zonder dat ze worden toegevoegd, zodat ik gewoon 1 query heb?

Jeroen

hmm ik vat het niet helemaal? het lijkt mij logisch dat je met een query alleen data ophaalt die aan elkaar gerelateerd is.

een query zoals bijvoorbeeld SELECT gebruiker.*, categorie.* FROM gebruiker, categorie haalt alle gebruikers en categorieen op. je hebt er alleen niet zoveel aan als die twee tabellen niets met elkaar te maken hebben.

logisch voorbeeld:
table groep
kolom ID (primary key, auto increment)
kolom omschrijving

table subgroep
kolom ID (primary key, auto increment)
kolom omschrijving
kolom groep_id

query:

code:

SELECT 
  groep.id, 
  groep.omschrijving,  
  subgroep.id,
  subgroep.omschrijving
FROM
  groep,
  subgroep
WHERE
  groep.id = subgroep.groep_id
ORDER BY
  groep.omschrijving,
  subgroep.omschrijving ASC

[Verwijderd]

Als ik op een pagina én de gebruikersgegevens wil opvragen én de MySQL gegevens van de betreffende pagina (als voorbeeld: statistieken) zijn deze niet gerelateerd aan elkaar. Kan ik ze dan wel het beste in 2 query's binnenhalen?

[bigtree]

whoami schreef op 13 May 2003 @ 19:47:
Primary keys heb je altijd nodig.
Je moet altijd een record uniek kunnen identificeren; daarnaast is het ook zo dat het selecteren op primary key de snelste manier is om een record op te halen.

Enige nuancering is hier wel op zijn plaats. Als ik een many-to-many relatie wil bewerkstellingen met een tussentabel met daarin 2 kolommen, ga ik toch echt geen primary key toevoegen. Wel een UNIQUE op die twee kolommen. Als ik ook nog een primary key zou hebben, zou ik naast een kolom te veel ook nog een index te veel hebben. Bij een tussentabel selecteer je nooit op de primary key dus is er geen enkele reden om een primary key te maken.

[ACM]

euh...

Waarom zou je geen primairy key van die many-to-many relatie kunnen maken dan
Je bent echt niet verplicht om een primairy key als een autoincrement integer toe te voegen ofzo hoor...

De identificatie van een records zou je als primairy key kunnen beschouwen, bij een koppeltabel (voor de m-m relatie) IS die koppeling de identificatie en kan je prima een primairy key over die twee (of meer) koppelwaarden leggen. Geen enkele reden om geen primairy key, maar wel een unique key, te gebruiken...

[whoami]

Zoals ACM al zegt: die UNIQUE index op die 2 velden is dan je primary key. Of; die index definieer je dan beter als PK.

[Verwijderd]

Is het werken met templates zwaarder voor de server dan normaal?

1.

function MaakTabel($tekst) {
echo("<table><tr><td>$tekst</td></tr></table>");
}

MaakTabel("Dit is de tekst.");

2.
<?php $tekst = "Dit is de tekst."; ?>
<table><tr><td><?php echo $tekst; ?></td></tr></table>

Is 1 dus in feite zwaarder dan 2?

[bigtree]

ACM -> je hebt gelijk. Het enige verschil tussen een UNIQUE en PRIMARY is volgens de manual dat bij UNIQUE er nog NULL values mogen bestaan, bij PRIMARY mag dat niet. NULL values zullen wel niet voorkomen in een koppeltabel.

Ander voorbeeld dan. In een tabel met pageviews waar ik alleen een foreign key van de pagina en een datum/tijd veld heb, heeft een primary key geen meerwaarde. SELECTs worden niet sneller door het toevoegen van een primary key, als ik maar een index op beide kolommen heb.

[ACM]

Verwijderd schreef op 13 May 2003 @ 19:15:
Ik ben momenteel bezig met een grote site met een aantal duizend leden. Nu heb ik wat vragen over PHP/MySQL technieken en functies en de CPU laadtijd daarbij.

Wat is groot?
Als je op het piek tijdstip 1 request per seconde hebt, zou ik me pas druk maken over de laadtijden wanneer dat boven de 100a300ms uitschiet...

- include() of require() in PHP: Kost dit veel CPU laadtijd?

Dat hangt er helemaal vanaf wat je include (classes, grootte van files, etc) en of je elke keer domweg alles include, of dat je het splitst in kleinere hoeveelheden die niet bij elke request nodig zijn.

- fopen() om een bestand te schrijven: Kost dit veel CPU laadtijd?

Nee, fopen/fwrite is doorgaans erg snel, zeker als je OS een beetje efficient kan cachen en de DMA functionaliteit van de disks kan gebruiken (in geval van ide).
Let er wel op dat er geen twintig schrijvers tegelijk bezig zijn in dezelfde files...

- Is het veel beter om alles in één query te laden per pagina en hoe kan ik dit het beste aanpakken?

Als die query daardoor _veel_ meer zinloze data opstuurt is het niet gegarandeerd sneller. Als die query daardoor een stuk complexer wordt is het misschien zelfs wel
trager (nadeeltje van mysql) dan losse queries.

- Heeft iemand nog meer tips voor een grote site?

Maak hem eerst maar es en bekijk dan pas of ie snel genoeg is... Als er toevallig een actie is die wat langer duurt is dat niet perse slecht.
Pas als ie _te_ traag is (hoge serverloads enzo) moet je goed naar kijken _waar_ ie traag door is en dat eerst oplossen.

Bedenk dat als je 10 bezoekers per minuut hebt het nauwelijks uitmaakt dat een request er een seconde over doet om afgehandeld te worden, de gebruiker merkt er weinig van.
Het is natuurlijk wel dom om niet standaard al een beetje aandacht aan de performance te besteden

[ACM]

Verwijderd schreef op 13 May 2003 @ 20:50:
Is 1 dus in feite zwaarder dan 2?

Maak je eerst eens druk om de functionaliteit, beheersbaarheid en dat soort zaken...

Het verschil in tijd tussen jouw voorbeelden is nihil gok ik.

bigtree schreef op 13 May 2003 @ 20:53:
Ander voorbeeld dan. In een tabel met pageviews waar ik alleen een foreign key van de pagina en een datum/tijd veld heb, heeft een primary key geen meerwaarde. SELECTs worden niet sneller door het toevoegen van een primary key, als ik maar een index op beide kolommen heb.

Er zijn altijd voorbeelden te bedenken waar een primary key niks toevoegt of zelfs in de weg zit
Maar in principe zou elke tabel een primary key moeten hebben "tenzij..." ipv dat ie in principe geen primary key moet hebben "tenzij..."

[Verwijderd]

ACM schreef op 13 May 2003 @ 20:56:
Bedenk dat als je 10 bezoekers per minuut hebt het nauwelijks uitmaakt dat een request er een seconde over doet om afgehandeld te worden, de gebruiker merkt er weinig van.
Het is natuurlijk wel dom om niet standaard al een beetje aandacht aan de performance te besteden

Er zijn momenteel zo'n 60 tot 80 hits per minuut, en ik merk dat live PHP/MySQL dat niet aan kan. Of doe ik iets grandioos fout?

[MrC4u]

Dat lijkt me niet zo'n probleem: 60 tot 80 hits per minuut, tenminste: als je hardware toereikend is: wat zijn je server specs eigenlijk? Als je niet van plan bent om te gaan upgraden / normaliseren, dan is waarschijnlijk de cron manier nog het snelst.

[ACM]

Verwijderd schreef op 13 mei 2003 @ 21:19:
Er zijn momenteel zo'n 60 tot 80 hits per minuut, en ik merk dat live PHP/MySQL dat niet aan kan. Of doe ik iets grandioos fout?

Ik krijg met gemak 60a80 hits per minuut uit mijn athlon 850, het hangt natuurlijk van de applicatie af hoe goed dat gebeurd.

Maar ik denk dat er dan inderdaad wel het een en ander aan verbeterd kan worden. Maar ook dan geldt: zoek uit waar het langzaam gaat.

Als jij een dag besteed aan het sneller maken van een functie en daarmee 1ms wint, terwijl je een stel queries hebt die in totaal 200ms bezig zijn, was die dag imho gewoon tijdverspilling

Sowieso zal het grootste deel van de tijd in de queries zitten, tenzij je hele rare constructies in php hebt.

Belangrijkste devies is gewoon het gebruiken van indices, hoe? Zie onder andere de voortreffelijke uitleg die MrX voor de P&W-FAQ heeft geschreven

[Verwijderd]

Je zou met getmicrotime() kunnen kijken waar je nu eigelijk een performance probleem hebt.
voor je het weet zit je de verkeerde onderdelen te optimaliseren.
ik denk trouwens ook dat het aan een verkeerde query/index ligt

Ik gebruik daarvoor soms code als dit:

PHP:

$time_start  = getmicrotime();
//include;requre files etc..
benchmark('including');
//doe iets-1
benchmark('doe-iets-1');
//doe iets-2
benchmark('doe-iets-2');
//doe iets
/*tonen resultaat*/
if ($benchmark){
    asort($benchmark);
    print_r($benchmark);
}   

function benchmark($desc){
    //uncomment to enable:
    global $time_end,$time_start,$benchmark;
    $time_end = getmicrotime();
    $time = $time_end - $time_start;    
    $benchmark[$desc] += $time; 
    $benchmark[total] += $time;
    $time_start = getmicrotime();
}

[ Voor 7% gewijzigd door Verwijderd op 14-05-2003 08:03 ]

[Verwijderd]

Hm. 60 a 80 hits per minuut. Uitgaand van 60 is dat 86400 hits in 24 uur. 's Nachts slapen we dus we gaan uit van een 45000 hits. Beste site vriend... (-:
Maar eerlijk gezegd lijkt mij dat dit, afhankelijk van je hosting, niet echt een probleem mag zijn voor een server? Pas als er hits komen die elkaar gaan overlappen, en dan hebben we het over microseconden, dan wordt het lastig allemaal...
Maar ik kan me niet echt voorstellen dat het nu misgaat? Wellicht zou je uit kunnen leggen wat er ongeveer 'mis' gaat of langzaam gaat?
Ik bedoel te zeggen dat de meeste hosting bedrijven, de goede, een grote hoeveelheid hits / dataflow aankunnen.

[Verwijderd]

Ik denk dat het laden van de informatie uit de database bij elke hit voor de problemen zorgt. De gebruikersinformatie moet worden geladen, de berichtenbalk, een paar statistieken en dan nog de pagina zelf waar ook weer veel dingen uit de database worden gehaald. Bedankt voor jullie tips.

[ACM]

dat is alvast een stap.

Nu dus per query kijken of ie lang duurt en of dat te verbeteren is, oa met indexen.

[Verwijderd]

Is het het beste om zoveel mogelijk al in MySQL te doen?

Is dit:

SELECT Datum, YEAR(CURRENT_DATE)-YEAR(Datum)-IF(DAYOFYEAR(CURRENT_DATE)+1>DAYOFYEAR(Datum),0,1) AS Leeftijd FROM Tabel

...dus beter dan het pas uit te rekenen in PHP?

[ Voor 4% gewijzigd door Verwijderd op 14-05-2003 19:24 . Reden: Foutje :-$ ]

[ACM]

ja in principe wel

[CubicQ]

Maar dat heeft wel weer als nadeel dat je database-server zwaarder belast wordt. Webservers zijn relatief makkelijk bij te plaatsen, dus als je echt gaat groeien kan ik me voorstellen dat je graag een iets hogere totaaltijd voor lief neemt voor een lagere databaseload.

[Verwijderd]

Heeft het nut om mysql_free_result() te gebruiken of zal hierdoor de server load niets of nauwelijks minder worden?

[Yo-han]

Je kan altijd even je slow log in mysql aanzetten om te checken of je query's lopen als je zou willen. Mocht dit niet het geval zijn kan je precies zien waar het fout gaat.
Verder proberen zoveel mogelijk query's tegelijk uitvoeren zodat je maar 1 keer een connectie hoeft te maken.

Als je met een groot aantal hits werkt en veel selects moet draaien kan je er zelfs over na denken om een master->slave netwerk op te zetten...

[ACM]

Verwijderd schreef op 22 May 2003 @ 19:01:
Heeft het nut om mysql_free_result() te gebruiken of zal hierdoor de server load niets of nauwelijks minder worden?

Als je veel results opent en weer hergebruikt enzo zal het zeker nut hebben.
't Scheelt iig actief geheugen, 't is alleen een beetje jammer dat php niet zo netjes met geheugen-vrijmaken omgaat... Magoed, het zal iig geen kwaad kunnen

[hobbit_be]

ik weet niet of er in jouw site plaats is voor 'caching' / of gedeeltelijk caching. Maar dit kan absurde performance improvements teweeg brengen. Je kan cachen op heel wat niveaus: per html file, per parsed html file (bijvoorbeeld deze pagina bevat een lekkere ingewikkilde query, maar hij is op te splitsen in een 'Hun' (ie alle msg + user info) en jouw gedeelte (ie edit message, log in / log out) dus kun je bijhouden (eventueel in mySQL) of jouw 'page' view van HUN kant moet worden updated of niet), of cached query. Dat laatste is met PHP vast geen optie wat wel jammer is (in Java is dat NoProb) - of zoek misschien naar een caching layer tussen PHP en mySQL. Dat voor caching geheugen nodig is lijkt me wel duidelijk.

Iets heel doms maar werkt wel - is gewoon de gegeneerde HTML klein houden en natuurlijk gezipt doorpompen (ook het doorsturen kost allemaal tijd) net zoals Google doet.

Maar gewoon eerst profilen. Overigens ben ik het niet echt eens met mySQL en ingewikkelde queries (ie met een hele boel functie spul, niet echt over multiple joins) - daar is ie niet echt goed op en kun je wellicht beter effe checken.

Nog tips: gebruik Unix TimeStamps voor Date-Time, ik denk wel dat mySQL dit intern zo zal doen, maar je kan nooit weten (ie heel gemakkelijk heel snel met datums werken). of gewoon een int(32). Gebruik geen TEXT un mySQL tenzij het moet (VarCHar(len)) en wat in numbers kan doe je ook zo ipv strings ('cijferlijk' > 'letterlijk'). Persistant connection heb je al dat zou meestal ook erg helpen.

[twiekert]

hobbit_be schreef op 22 mei 2003 @ 22:34:
...of cached query. Dat laatste is met PHP vast geen optie wat wel jammer is (in Java is dat NoProb) -> 'letterlijk'). Persistant connection heb je al dat zou meestal ook erg helpen.

waarom niet ik gebruik het ook en cached queries werken perfect in mysql. de result van een query wordt gecached in mysql, vraagt een volgende client om data met exact dezelfde query dan krijgt tie de gecachede results terug. bij een update / insert / delete wordt de gecache result set uiteraard weggehaald.


en ik zou zeker de mogelijkheid bekijken om de pagina te gzippen, dit scheelt echt gigantisch.

een pagina van een website met duizend artikelen was ongecomprimeerd 325KB, in ge gzipped was dat 32KB, in zippen kost uiteraard wat performance maar verwaarloosbaar ivm de compressie factor

[ACM]

Bovenstaande is overigens pas vanaf mysql 4.0 zo
Bij oudere mysql's is er wel wat cacheing, maar niet van de exacte query resultaten.

[hobbit_be]

offtopic:
wel grappig dat het steeds 'bovenstaand is' - ik zet de order altijd nieuwste eerst, ben blijkbaar de enige. Iedereen is voor mij dus 'onderstaand', helaas niet op intellectueel vlak

Dat de nieuwe MySQL een query cached wist ik niet - grandioos - maar de roundtrip (Server -> Script -> API -> MySQL -> API -> SCript -> HTML ) kost ook veel tijd. Met caching doelde ik het bijhouden van de results VOOR de database (ie dus op 'script' niveau, dus zero time delay, in Java allemaal mooi in een HashMap, al dan niet synched(ie waitforwrite) ).

[alienfruit]

Ik zag stored procedures laatst in MySQL 5 supervet, is gewoon compatible met SQL standaard en zijn nu bezig om het compatible te maken met Oracle

[Verwijderd]

volgens de PHP docs kan het gebruik van include() ipv require() soms perofrmance verbetering tot gevolg hebben. Dit omdat een ge-require()-de file ALTIJD wordt ingelezen (vergelijk: compile-time) en een ge-include()-de file ALLEEN ALS PHP ook daadwerkelijk bij het include commando aankomt (dit is niet altijd zo).

Het zal je niet enorm veel helpen denk ik, maar probeer het op een paar files en gebruik de benchmark methode van hierboven

[twiekert]

ik heb het ff getest maar ik snap nou niet wat je nou bedoeld met een require wordt altijd ingelezen.. :

ik heb ff een test.php gemaakt die een file required zodra er een get var test aanwezig is.

ik include dan een 111K groot bestand waarin staat $arraytest[0] = random cijfer t/m arraytest[4999] = random cijfer .

brak parsetime meten script:

code:

<?
$total_timeparts = explode(" ",microtime());
$total_starttime = $total_timeparts[1].substr($total_timeparts[0],1);


if (isset($_GET['test'])) {
        require("includetest.inc.php");

}

  $total_timeparts = explode(" ",microtime());
  $total_endtime = $total_timeparts[1].substr($total_timeparts[0],1);
  $total_parsetime = number_format(($total_endtime-$total_starttime),4);

echo $total_parsetime;
?>

zonder GET var test: 0.0001

met GET var test: 0.1467

[Erkens]

twiekert schreef op 23 May 2003 @ 22:21:
ik heb het ff getest maar ik snap nou niet wat je nou bedoeld met een require wordt altijd ingelezen.. :

ik heb ff een test.php gemaakt die een file required zodra er een get var test aanwezig is.

ik include dan een 111K groot bestand waarin staat $arraytest[0] = random cijfer t/m arraytest[4999] = random cijfer .

..

zonder GET var test: 0.0001

met GET var test: 0.1467

doe ook eens met include (ik heb geen zin om een grote file te maken )

[twiekert]

Erkens schreef op 23 mei 2003 @ 22:59:
[...]

doe ook eens met include (ik heb geen zin om een grote file te maken )

ook gedaan

include, include_once, require en require_once maakt allemaal geen kont uit

[Verwijderd]

twiekert schreef op 24 mei 2003 @ 01:34:
include, include_once, require en require_once maakt allemaal geen kont uit

En als je het 1000 keer doet ipv 1 keer?
Maar maakt idd weinig uit... Het includen op zich brengt wel tijd met zich mee, maarja je moet wel...

Daarnaast is chachen echt aan te raden,
ik doe het nu ook extreem (ik cache soms zelfs in de db, beter een serialized array dan een ingewikkelde query) en onze servers trekken nu 33.000 bezoekers per dag ipv 17.000

[ Voor 26% gewijzigd door Verwijderd op 24-05-2003 03:58 ]

[Verwijderd]

Verwijderd schreef op 24 May 2003 @ 03:57:
Daarnaast is chachen echt aan te raden,
ik doe het nu ook extreem (ik cache soms zelfs in de db, beter een serialized array dan een ingewikkelde query) en onze servers trekken nu 33.000 bezoekers per dag ipv 17.000

offtopic:
Dus door het cachen heb je meer bezoekers gekregen

[Verwijderd]

Hoe stel je dan in dat er gecached moet worden? Of bedoel je 'gewoon' cachen met HTML bestanden?

[ACM]

Hij bedoeld dat je zelf de uiteindelijke resultaten opslaat zodat je die niet bij elke view opnieuw hoeft te genereren.
Het nadeel van zoiets is dat het niet werkt als elke view verschillend is van de anderen, voor andere gebruikers.

[chem]

Als je trouwens PHP 4.3.x draait zou ik eens xdebug installeren en daarmee aan de slag gaan.

Het lijkt me zaak een complete outline van je app te maken, en vv gestructureerd oplossingen en/of verbeteringen te zoeken.
maw: vertel in hoofdlijnen hoe je app werkt (zet evt de source online), welke queries, welke EXPLAINs een probleem vormen etc.

[Verwijderd]

Als ik uit een tabel van 3 kolommen (Gebruikersnaam,Aanmelddatum,Wijzigdatum) met 4500 rijen dit doe, is het dan normaal dat mijn MySQL op 10% CPU load springt?

SELECT Gebruikersnaam,Aanmelddatum FROM Leden ORDER BY Aanmelddatum,Gebruikersnaam DESC LIMIT 10
SELECT Gebruikersnaam,Wijzigddatum FROM Leden ORDER BY Wijzigdatum,Gebruikersnaam DESC LIMIT 10

Ik gebruik deze tabel overigens niet normaal, dit is alleen om te testen. Alleen vind ik 10% MySQL CPU load wel hoog.

[Verwijderd]

Ik heb ooit ergens een test gelezen op een site dat de load time van include_once, require_once, include en require test. Uit deze test bleek dat er een groot verschil was tussen deze verschillende manieren.

Om gegevens uit meerdere tabellen te halen in SQL is JOIN ook wel erg handig. Vooral LEFT JOIN gebruik ik vaak.

Als ik uit een tabel van 3 kolommen (Gebruikersnaam,Aanmelddatum,Wijzigdatum) met 4500 rijen dit doe, is het dan normaal dat mijn MySQL op 10% CPU load springt?

SELECT Gebruikersnaam,Aanmelddatum FROM Leden ORDER BY Aanmelddatum,Gebruikersnaam DESC LIMIT 10
SELECT Gebruikersnaam,Wijzigddatum FROM Leden ORDER BY Wijzigdatum,Gebruikersnaam DESC LIMIT 10

Ik gebruik deze tabel overigens niet normaal, dit is alleen om te testen. Alleen vind ik 10% MySQL CPU load wel hoog.

Dit lijkt mij normaal. En 10% is niet eens veel. SQL mag best het uit uiterste van je PC trekken.

[Bosmonster]

Verwijderd schreef op 28 mei 2003 @ 22:18:
Als ik uit een tabel van 3 kolommen (Gebruikersnaam,Aanmelddatum,Wijzigdatum) met 4500 rijen dit doe, is het dan normaal dat mijn MySQL op 10% CPU load springt?

SELECT Gebruikersnaam,Aanmelddatum FROM Leden ORDER BY Aanmelddatum,Gebruikersnaam DESC LIMIT 10
SELECT Gebruikersnaam,Wijzigddatum FROM Leden ORDER BY Wijzigdatum,Gebruikersnaam DESC LIMIT 10

Ik gebruik deze tabel overigens niet normaal, dit is alleen om te testen. Alleen vind ik 10% MySQL CPU load wel hoog.

10% increase voor zo'n simpele select vind ik persoonlijk wel veel hoor (al weet ik niet wat voor CPU je draait ) Heb je wel indexen op gebruikersnaam, wijzigdatum en aanmelddatum?

[ Voor 4% gewijzigd door Bosmonster op 29-05-2003 16:57 ]