[PHP] Soms traag laden van pagina met veel includes*

[Verwijderd]

Beste

Al enkele jaren ben ik webdesigner en php programmeur voor websites. Tot hiertoe heb ik op al mijn problemen al raad geweten tot dit probleem.

Ik heb een website die database gestuurd is waarbij ik vele includes toepas van pagina's. Deze site vertoont sinds kort zeer rare kuren, soms wil hij de pagina niet openen of heeeel traag. Als je dan 5x F5 drukt lukt het weer wel en andere keren lukt het perfect!! Ik weet niet hoe dit in godsnaam kan komen, ik dacht eerst aan:

- teveel db connecties geopend met de includes

Heeft iemand dergelijke probleem al voorgehad? Kan iemand mijn helpen. Dit is een vrij drukbezochte site en zorgt dus voor veel hinder op men website

thxs Baj

[faabman]

dat kan van heel veel zaken afhangen zoals:
- je eigen internetverbinding
- configuratie van de webserver / databaseserver
- andere processen die draaien op de server

[whoami]

Ik heb je topictitel aangepast, zodat het duidelijker is wat je probleem is, en welke taal je gebruikt.
Let daar zelf ff op in het vervolg.

[Verwijderd]

faabman schreef op 17 april 2004 @ 20:07:
dat kan van heel veel zaken afhangen zoals:
- je eigen internetverbinding
- configuratie van de webserver / databaseserver
- andere processen die draaien op de server

Het probleem situeert zich niet enkel bij mij maar ook bij de medewerkers van onze site die net hetzelfde tegenkomen dus moet het ergens aan mijn scripts liggen.

sorry van de titel

[Mawlana]

Verwijderd schreef op 17 april 2004 @ 20:00:
- teveel db connecties geopend met de includes

Open je toevallig in ieder bestand een nieuwe db-connectie?

[Hans1990]

Probeer is geen include() te gebruiken maar include_once(). Dat zorgt ervoor dat elk bestand maar 1x word uitgevoerd. Of anders zal je moeten gaan overwegen om dat (grote) aantal includes te verminderen en je code te optimalizeren.

[NMe]

sylvesterrr schreef op 17 april 2004 @ 21:06:
Open je toevallig in ieder bestand een nieuwe db-connectie?

Daar dacht ik ook al aan... Verder kun je proberen boven elke include iets te echoen, zodat je weet waar het fout gaat. Of een andere server proberen...

Verder heeft 5x op F5 drukken geen zin, dan wordt er maar al te vaak in de cache gekeken, dus daarom gaat dit sneller.

[Tom-Eric]

Wat interessant is aan PHP is dat includes die buiten code zitten zoals if statements of functies veel sneller laden als includes die dynamisch geladen kunnen worden. Ook leuk is dat als je bijv. al je classes die je vaker nodig hebt in 1 file gooit en je include die, je vaak tot 30/40% snelheidswinst kan halen (vooral met een php cacher als mmcache).

[Verwijderd]

heb je de code als eens getimed en gekeken waar je bottleneck zit?

[Dennis]

Verwijderd schreef op 17 april 2004 @ 20:18:
Het probleem situeert zich niet enkel bij mij maar ook bij de medewerkers van onze site die net hetzelfde tegenkomen dus moet het ergens aan mijn scripts liggen.

Het is wel algemeen bekend volgens mij dat veel includes sites enorm veel trager maakt. Ik heb het wel eens getest, toen ik één include had scheelde dat enorm veel ten opzichte van de acht includes die ik eerder had.

React is ook een mooi voorbeeld. Ik dacht dat, omdat er natuurlijk enorm veel requests zijn, alle php-scripts dynamisch zijn samengevoegd zodat er helemaal geen includes zijn. Het scheelt namelijk echt enorm op zo'n druk forum zoals GoT.

Het is hier geen msn .

[Tom-my]

Verwijderd schreef op 17 april 2004 @ 20:00:
Beste

...

- teveel db connecties geopend met de includes
...

Euhm ik hoop dat je maar met 1 resource werkt? Beetje nutteloos om er meer aan te maken nl? Heb je ook continu dit staan:

$xxx = mysql_connect(); ?

En ligt het niet aan de traffic naar je website?

[ Voor 8% gewijzigd door Tom-my op 18-04-2004 11:01 ]

[Johnny]

Hoeveel is veel?

enkele, tientallen, honderden?

[Cavorka]

De grootte van de bestanden die je include is ook heel erg belangrijk!

Stukje uit een log van mij (benchmark):

code:

3. - Inclusion of a 40kb file vs a 2kb file.
1-9-2003 17:51 - Results:
500 cycles:
    40kb file:  26.94s, 1 cycle: 0.05389s
    2kb file:   0.5s, 1 cycle: 0.001s

Was trouwens allemaal data, array's, die ik includede (verleden tijd van include? ).

Hier met unset erbij:

code:

So I would say the difference is rather shocking.

500 cycles, with unsetting all variables each cycle:
    40kb file:  9.77s, 1 cycle: 0.01953s
    2kb file:   0.49s, 1 cycle: 0.001s

Factortje 20 dus.

[ Voor 44% gewijzigd door Cavorka op 18-04-2004 12:58 ]

[djluc]

Ik zit ook met dit probleem. Een druk op F5 werkt bij mij vrijwel altijd, maar het is zo vreemd dat het niet werkt. Ik heb teveel code om deze in minder bestanden te plaatsen, en zou dit vanwege het overzicht ook niet willen veranderen. Mijn parsetimes zijn echter erg goed, alles is zwaar geoptimaliseerd. De meeste pagina's laden binnen de 0.06sec. Dus dat is volgens mij niet de reden dat het fout gaat. Ook scriptingsfouten lijken mij vrijwel onmogelijk omdat er geen enkele error verschijnt.

[Thijsmans]

Ik zou het niet zoeken bij de php-code of de mysql-verbindingen. Als het de ene keer wel goed gaat, en de andere keer niet, dan betekent dat dus niet dat je script langzaam is. Ik zou eens kijken naar de serversoftware zelf. Luistert ie wel goed naar poort 80? Wat is de serverload? Staat ie het internet te indexeren?