[PHP] Performance verschillende OS

[vriesdude]

Voor op het intranet heb ik een werktijdenplanner geschreven,
er staan ongeveer 40 medewerkers in, elke dag bestaat uit 8 uur en er worden 5 dagen per week weergegeven.

In een database staat dus 1600 keer een code voor een dagdeel. Het geheel wordt door PHP netjes in een schema weergegeven. Dit alles op een flinke webserver.

Ik heb het geheel ontwikkeld op een Windows 2003 Server en getest op een XP client (op beide duurt het opbouwen van de pagina <2 seconden (netjes gezien de berg data)...

Nu wou ik het geheel bekijken op een Windows 2000 computer met daarop IE6 en het bouwen van de desbetreffende pagina duurt soms 5 seconde, soms wel 30 seconde. Het vreemde is dat het exact dezelfde code en output is (de output is HTML only, al het parse werk wordt gedaan op dezelfde Windows 2003 server.

Doormiddel van microtime(); heb ik aan het begin en aan het einde van de pagina een berekening laten doen, wat blijkt. Het maken (parsen) van de pagina duurt gemiddeld 5 keer zo lang als een Windows 2000 computer deze bezoekt (meerdere computers getest) dan als een Windows XP/2003 computer met dezelfde IE versie (6) de pagina bezoekt.

Waar zou ik de oorzaak moeten zoeken??

Het kan niet aan de MySQL server liggen, omdat op de windows 2003 server alles binnen 1 seconde geparst en weergegeven kan worden, dit geld ook voor de windows xp client. (iets langere tijd, maar dat komt omdat het nog over het netwerk heen moet ipv local)..

Ik kom er niet uit, help ?

[Tux]

Een zeer vaag probleem. De enige oorzaak die ik zou kunnen bedenken:

Die 2000 pc's zijn of zeer traag of hun netwerk is zeer traag, daardoor moet de verbinding met de server 2,5 maal langer open blijven, waardoor de parse tijden oplopen.

[.oisyn]

Wat gebeurt er als je de html file opslaat en dan opnieuw opent? Duurt het dan ook zo lang?

Het maken (parsen) van de pagina

Dat heet geen parsen, parsen is een stuk data begrijpen door het op te delen in kleinere blokjes

[ Voor 13% gewijzigd door .oisyn op 02-02-2005 16:51 ]

[elevator]

Een bekend probleem met 'parsetijd' op Windows is dat je de buffering aan moet staat - heb je in je php.ini op je Windows server dit wel aan staan? (output_buffering = on oid) ?

[easydisk]

Even met een download manager downloaden of zo, dan weet je of het aan de langzame windows 2000 computer ligt of aan de server.

[djc]

Eens zien: een Windows 2003 Server, met daarop Apache, MySQL en PHP (WAMP).
Een Windows XP client, initieel gebruikt om applicatie te testen.
Een Windows 2000 client, secundaire tests.

Hoe heb je de executietijd gemeten? In PHP? Hoe is je netwerktopologie (is er een reden waarom verbinding tussen 2k3 - XP sneller kan zijn dan 2k3 - 2k)? Hoe staat je output_buffering ingesteld?

[vriesdude]

Tux schreef op woensdag 02 februari 2005 @ 16:48:
Een zeer vaag probleem. De enige oorzaak die ik zou kunnen bedenken:

Die 2000 pc's zijn of zeer traag of hun netwerk is zeer traag, daardoor moet de verbinding met de server 2,5 maal langer open blijven, waardoor de parse tijden oplopen.

Alles zit op de lokale switch

.oisyn schreef op woensdag 02 februari 2005 @ 16:49:
Wat gebeurt er als je de html file opslaat en dan opnieuw opent? Duurt het dan ook zo lang?

Dan gaat het op alle workstations even snel (en dat is snel)

elevator schreef op woensdag 02 februari 2005 @ 16:51:
Een bekend probleem met 'parsetijd' op Windows is dat je de buffering aan moet staat - heb je in je php.ini op je Windows server dit wel aan staan? (output_buffering = on oid) ?

Dat ga ik proberen !,

edit: volgens mij deed dat het hem...

[ Voor 62% gewijzigd door vriesdude op 02-02-2005 17:06 ]

[vriesdude]

Nieuwe post (vind ik netter in dit geval)..

Het werkt nu, alleen krijg ik eerst een witte pagina voor een paar seconden, en vervolgens komt alles in één keer door (op een prima tempo (als ik alle weken van dit jaar weergeef = 6 MB komt dat in 12 seconden, meer dan tevreden).

Alleen zou ik de tijd van de witte pagina nog weg willen werken (Verkleinen), doe ik dit door de output buffer zo laag mogelijk in te stellen of zo hoog mogelijk. Ik had ook al gekeken om vanuit het script een flush te doen maar dit had geen merkbaar resultaat.

[Skaah]

Zo laag mogelijk. Als je zoveel data wilt oversturen, zou ik het opsplitsen in verschillende pagina's of gebruik maken van javascript om je pagina op te bouwen.

[vriesdude]

Skaah schreef op woensdag 02 februari 2005 @ 18:00:
Zo laag mogelijk. Als je zoveel data wilt oversturen, zou ik het opsplitsen in verschillende pagina's of gebruik maken van javascript om je pagina op te bouwen.

Verschilende pagina's heeft ook mijn voorkeur, maar gebruikers willen alles in 1 keer ...

met javascript webpagina's opbouwen heb ik nog niet veel kaas van gegeten. ik probeer de output buffer omlaag te zetten ..

Output buffer ON = 1, heb hem ook op 4096 gezet, allebei lange tijd witte pagina. ik zal hem morgen als ik op me werk ben eens op 8 of 16 zetten. (neem aan dat dit in bytes zijn en dat zodra de OB vol zit dat ie het verzend...


Wat ik me afvraag, is dit nou echt een bug of misconfiguratie in PHP wat betreft de snelheid op sommige Windows machine's ?

[Robinski]

Output buffer kan alleen maar ON of OFF zijn

vriesdude schreef op woensdag 02 februari 2005 @ 18:06:
[...]


Verschilende pagina's heeft ook mijn voorkeur, maar gebruikers willen alles in 1 keer ...

met javascript webpagina's opbouwen heb ik nog niet veel kaas van gegeten. ik probeer de output buffer omlaag te zetten ..

Output buffer ON = 1, heb hem ook op 4096 gezet, allebei lange tijd witte pagina. ik zal hem morgen als ik op me werk ben eens op 8 of 16 zetten. (neem aan dat dit in bytes zijn en dat zodra de OB vol zit dat ie het verzend...


Wat ik me afvraag, is dit nou echt een bug of misconfiguratie in PHP wat betreft de snelheid op sommige Windows machine's ?

[vriesdude]

Robinski schreef op donderdag 03 februari 2005 @ 01:06:
Output buffer kan alleen maar ON of OFF zijn


[...]

O, ben je daar wel helemaal zeker van ??

code:

; Output buffering allows you to send header lines (including cookies) even
; after you send body content, at the price of slowing PHP's output layer a
; bit.  You can enable output buffering during runtime by calling the output
; buffering functions.  You can also enable output buffering for all files by
; setting this directive to On.  If you wish to limit the size of the buffer
; to a certain size - you can use a maximum number of bytes instead of 'On', as
; a value for this directive (e.g., output_buffering=4096).
output_buffering = On

[elevator]

vriesdude schreef op woensdag 02 februari 2005 @ 17:22:
Alleen zou ik de tijd van de witte pagina nog weg willen werken (Verkleinen), doe ik dit door de output buffer zo laag mogelijk in te stellen of zo hoog mogelijk. Ik had ook al gekeken om vanuit het script een flush te doen maar dit had geen merkbaar resultaat.

Dit is eigenlijk afhankelijk van waar precies je vertraging zit. Als de processing-tijd in je PHP script zit, wil je dat er zo snel mogelijk data naar de client gestuurd wordt.

Als echter je vertraging in je verbinding/netwerk zit (wat bijna altijd zo zou moeten zijn) - ga je (op Windows) het PHP script vertragen door de output buffer heel klein te zetten, je PHP script gaat namelijk op elke 'echo' blocken tot dat de output overgestuurd is naar de client.

Op een 56k modem gaat dat dus erg lang duren

[vriesdude]

elevator schreef op donderdag 03 februari 2005 @ 08:50:
[...]

Dit is eigenlijk afhankelijk van waar precies je vertraging zit. Als de processing-tijd in je PHP script zit, wil je dat er zo snel mogelijk data naar de client gestuurd wordt.

Als echter je vertraging in je verbinding/netwerk zit (wat bijna altijd zo zou moeten zijn) - ga je (op Windows) het PHP script vertragen door de output buffer heel klein te zetten, je PHP script gaat namelijk op elke 'echo' blocken tot dat de output overgestuurd is naar de client.

Op een 56k modem gaat dat dus erg lang duren

Voor op het intranet heb......

En dan zeggen modjes dat je goed moet lezen (just kidding).
Ik ga nog wel het een en ander expirimenteren. Het bouwen van de pagina duurt nog maar minder dan een halve seconden, dus ik ben al meer dan tevreden (gezien de grote hoeveelheid data....)

[TheDane]

offtopic:
Meer uit interesse dan 'kritiek', maar hoe on earth kom je aan 6MB data met bovenstaande gegevens? Alle weken van dit jaar, ik neem aan 52 weken keer 1600 records per week (je startpost klopt volgens mij niet) = 83200 records op jaarbasis.

Dan zou je op basis van die 6mb zo'n 72kb per record aan data hebben
Lijkt me erg veel. Of hou je zoveel data bij?

[vriesdude]

TheDane schreef op donderdag 03 februari 2005 @ 09:48:

offtopic:
Meer uit interesse dan 'kritiek', maar hoe on earth kom je aan 6MB data met bovenstaande gegevens? Alle weken van dit jaar, ik neem aan 52 weken keer 1600 records per week (je startpost klopt volgens mij niet) = 83200 records op jaarbasis.

Dan zou je op basis van die 6mb zo'n 72kb per record aan data hebben
Lijkt me erg veel. Of hou je zoveel data bij?

Ik wil het wel even toelichten.. 40 medewerkers, 8 dagdelen per medewerker per dag, 5 dagen per week = 1600, 1600 * 52 weken is inderdaad 83200 records..

De velden uit de tabel +3 joins die ik selecteer zijn uit me hoofd dit: KEY (int), UserID (int), STATUS (int), TIME (int) (om date mee te berekenen), en WID (om dagdeel mee te bepalen)

6 MB = 6291456 Bytes, dat weer delen door 83200 = 72 Bytes per record.. Je was een stapje van MB naar Bytes vergeten...

72 Bytes per record is misschien 10 bytes uit de databse en 60 voor de opmaak.
De goedoplettende mist nog 2 bytes (table headers en html tages (2 * 52 = 104 bytes)....

[TheDane]

vriesdude schreef op donderdag 03 februari 2005 @ 09:57:
[...]


Ik wil het wel even toelichten.. 40 medewerkers, 8 dagdelen per medewerker per dag, 5 dagen per week = 1600, 1600 * 52 weken is inderdaad 83200 records..

De velden uit de tabel +3 joins die ik selecteer zijn uit me hoofd dit: KEY (int), UserID (int), STATUS (int), TIME (int) (om date mee te berekenen), en WID (om dagdeel mee te bepalen)

6 MB = 6291456 Bytes, dat weer delen door 83200 = 72 Bytes per record.. Je was een stapje van MB naar Bytes vergeten...

72 Bytes per record is misschien 10 bytes uit de databse en 60 voor de opmaak.
De goedoplettende mist nog 2 bytes (table headers en html tages (2 * 52 = 104 bytes)....

oh lol ik vond 't al absurd

maardannog, 6mb is aardig wat. Ik blijf 't raar vinden dat die gebruikers alle info van een heel jaar willen zien Ik neem aan vanaf vandaag en dan een heel jaar terug. Worden die gegevens dan echt nog gebruikt ? Behalve wellicht incidenteel om uren bij een bepaald project te tellen ofzo

[elevator]

vriesdude schreef op donderdag 03 februari 2005 @ 08:54:
En dan zeggen modjes dat je goed moet lezen (just kidding).

Met mijn uitleg ga ik er van uit dat je *zelf* die conclusie kan trekken, je geeft namelijk zelf niet aan wat je daadwerkelijke processing tijd van je script is geworden (enkel 'sneller' geef je aan), vandaar deze algemenere uitleg.

Ik ga nog wel het een en ander expirimenteren. Het bouwen van de pagina duurt nog maar minder dan een halve seconden, dus ik ben al meer dan tevreden (gezien de grote hoeveelheid data....)

Kijk ook eens of iets als gzip compressie je niet kan helpen

[vriesdude]

elevator schreef op donderdag 03 februari 2005 @ 13:29:
[...]


[...]

Kijk ook eens of iets als gzip compressie je niet kan helpen

going to look at it

edit: dat werkt alleen maar tegen, diverse settings geprobeerd, maar niet effect.

ik had mededeling gedaan dat het nu stuk sneller ging, komt er een gebruiker met een mededeling terug dat het pagina bouwen 270 seconde duurde (via adsl VPN )

[ Voor 37% gewijzigd door vriesdude op 03-02-2005 14:08 ]