Det kunne lugte af memory problemmer med php opsætningen... Og binære filer der leveres igennem php er sjældent rigtig godt - det skaber også et unødvendigt overhead på webserveren der kan undgåes...
Er det standard phpbb implemeteringen der anvendes her eller er det et plugin?
[FIXED] inline pic crop/dårlig load
- AnotherDan
- Forum Donator
- Indlæg: 2687
- Sted: Søborg
Re: Test af inline pic crop/dårlig load
A fancy tagline goes here...
.. det er sådan phpbb fungerer, da de ønsker at kontrollere hvem som kan se attachments, avatars, ect og derfor ikke kan linke direkte; jeg er meget enig i at det generer en masse overhead!
Jeg er 99,9% sikker på det ikke er et memory problem, men derimod noget som er betinget af hvilket http response serveren sender. Nu kan jeg ikke lige huske det helt præcist, men jeg mener det opstår når serveren sender "302" tilbage, som .. igen .. frit efter hukommelsen, siger at det burde være cachet på en eller anden måde. Problemet går i hvert fald (midlertidig) væk, hvis man enten tømmer sin cache eller laver et forced reload via Shift-F5 ..
.. det var ikke et issue på vores test-server, og det er nok tvivlsomt om det er en generel phpbb bug .. det er nok nærmere en kombination af forskellige server / php / zend opsætninger. Jeg kan prøve at rode lidt med det i weekenden, og se om jeg kan blive klogere på det
Dan, du er velkommen til at adde mig på facebook http://facebook.com/runeborup .. det gør det lidt mere "interaktivt" at troubleshoote, hvis du er frisk på at gi en hånd med
Jeg er 99,9% sikker på det ikke er et memory problem, men derimod noget som er betinget af hvilket http response serveren sender. Nu kan jeg ikke lige huske det helt præcist, men jeg mener det opstår når serveren sender "302" tilbage, som .. igen .. frit efter hukommelsen, siger at det burde være cachet på en eller anden måde. Problemet går i hvert fald (midlertidig) væk, hvis man enten tømmer sin cache eller laver et forced reload via Shift-F5 ..
.. det var ikke et issue på vores test-server, og det er nok tvivlsomt om det er en generel phpbb bug .. det er nok nærmere en kombination af forskellige server / php / zend opsætninger. Jeg kan prøve at rode lidt med det i weekenden, og se om jeg kan blive klogere på det
Dan, du er velkommen til at adde mig på facebook http://facebook.com/runeborup .. det gør det lidt mere "interaktivt" at troubleshoote, hvis du er frisk på at gi en hånd med
Rune Borup :: Producer / Sangskriver / Synth-hvisker @ FishCorp
Wow, det sker også her - netop efter refresh. Begge billeder var korrekte første gang, og da jeg trykkede refresh forsvandt bunden pludselig fra begge. (I Opera 35). Der sker ingen crop i Firefox. Jeg kan ikke teste i IE, for den crasher ved start-up på den her maskine. Sjovt nok bliver den også croppet hvis jeg viser den specifikt / separat i Firefox. Og jeg tror problemet er at serveren ikke sender hele billedet ud til browseren, for selvom http headers'ne siger at der burde komme 133718 bytes (er dette størrelsen på din png fil?) så ankommer der kun 105824 bytes til firefox. Wget får til gengæld hele filen fra din server, så der sker ikke det samme hver gang. Det er ret underligt.Holger skrev:Efter upload vises fuldt billede første gang (af den nederste/nye post). Efter refresh af side vises begge cropped.
Hvis det er til nogen hjælp, så er her de http headers som bliver sendt foran billedet:
Kode: Vælg alt
HTTP/1.1 200 OK
Date: Sat, 27 Feb 2016 14:04:20 GMT
Server: Apache/2
X-Powered-By: PHP/5.4.45
Cache-Control: public
Content-Disposition: inline; filename*=UTF-8''Screen%20Shot%202016-01-31%20at%2000.57.31.png
Set-Cookie: phpbb3_vetfem_u=1; expires=Sat, 12-Mar-2016 14:04:21 GMT; path=/; domain=.lydmaskinen.dk; HttpOnly
Set-Cookie: phpbb3_vetfem_k=; expires=Sat, 12-Mar-2016 14:04:21 GMT; path=/; domain=.lydmaskinen.dk; HttpOnly
Set-Cookie: phpbb3_vetfem_sid=063c61ded4b8c6add0b5baea1b88de86; expires=Sat, 12-Mar-2016 14:04:21 GMT; path=/; domain=.lydmaskinen.dk; HttpOnly
Last-Modified: Sun, 31 Jan 2016 00:09:58 GMT
Content-Length: 133718
Vary: Accept-Encoding,User-Agent
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: image/png
Jeg laver også gratis plugins: www.robotplanet.dk/audio_plugins
- AnotherDan
- Forum Donator
- Indlæg: 2687
- Sted: Søborg
Jeg har tilføjet dig Rune...
Jeg vil godt hjælpe i det omfang jeg kan Holger har også yderligere kontakt detaljer til mig hvis nødvendigt...
Det første jeg ville gøre i dette tilfælde var at forsøge at deaktivere OPcache hvis serverens konfig tillader, dette kan i nogle tilfælde lade sig gøre i .htaccess filen.
Jeg vil godt hjælpe i det omfang jeg kan Holger har også yderligere kontakt detaljer til mig hvis nødvendigt...
Det første jeg ville gøre i dette tilfælde var at forsøge at deaktivere OPcache hvis serverens konfig tillader, dette kan i nogle tilfælde lade sig gøre i .htaccess filen.
A fancy tagline goes here...
AnotherDan skrev:Ping!
Kode: Vælg alt
[29/Feb/2016:18:20:50 +0100] "GET /download/file.php?id=16207 HTTP/1.1" 200 133058 "http://lydmaskinen.dk/viewtopic.php (cut..)
[29/Feb/2016:18:20:50 +0100] "GET /download/file.php?id=16207 HTTP/1.1" 304 81535 "http://lydmaskinen.dk/viewtopic.php? (cut..)[29/Feb/2016:18:20:51 +0100] "GET /download/file.php?id=16207 HTTP/1.1" 304 105527 "http://lydmaskinen.dk/viewtopic.php (cut..)[29/Feb/2016:18:20:52 +0100] "GET /download/file.php?id=16207 HTTP/1.1" 304 105527 "http://lydmaskinen.dk/viewtopic.php (cut..)
Hvis man kigger på det i chrome, så er svaret fra severen "200" alle 4 gange. Så .. hvad mon der foregår? Jeg prøver lige at gøre det samme på vores test-server ..
edit:
test-serveren sender 200 hver gang - og dermed hele filen .. ingen drama der ..
Rune Borup :: Producer / Sangskriver / Synth-hvisker @ FishCorp
.. så skulle det være løst! Skud ud til AnotherDan for at jamme løsnings-modeller med mig!
For de interesserede så bestod balladen i, at serveren var forced til at gzip'e alt html, billeder, ect .. hvilket af een eller anden årsag lavede ged i attachments! Nu er det slået fra på billedsiden, hvilket faktisk burde medføre mindre belastning på serveren, og at billeder cacher korrekt (og dermed sparer lidt båndbredde). Everybody wins!
For de interesserede så bestod balladen i, at serveren var forced til at gzip'e alt html, billeder, ect .. hvilket af een eller anden årsag lavede ged i attachments! Nu er det slået fra på billedsiden, hvilket faktisk burde medføre mindre belastning på serveren, og at billeder cacher korrekt (og dermed sparer lidt båndbredde). Everybody wins!
Rune Borup :: Producer / Sangskriver / Synth-hvisker @ FishCorp
- Christoffer I. N.
- Lydmaskinist
- Indlæg: 35557
- Sted: Hørsholm
Fedt.
25. Oktober 2022 - ny musikalsk videolog - Mørkt og minimalt, 5-lags soundscape
-
Jeg er betatester for BABY Audio.
-
Jeg er betatester for BABY Audio.
- AnotherDan
- Forum Donator
- Indlæg: 2687
- Sted: Søborg
Godt gået - Rune.
A fancy tagline goes here...