[php] foto resize script geeft te hoge load, alternatief ?

[Verwijderd]

Even terug heb ik een scriptje gemaakt dat bepaalde foto's op basis van wat argumenten resized, real-time.
Heel handig voor bijvoorbeeld fotoalbum-achtige software...
Niet dus

Want de server lijkt (heb geen shell-toegang dus weet het niet zeker, maar sommige foto's verschijnen niet en de frontpage gaat afentoe offline) een aardig hoge load te krijgen als je dus een pagina opvraagt met zo'n 25 verwijzing naar dat script.
Na wat test met php5-cli blijkt dat script voor grotere foto's ongeveer 1 seconde (!!) in beslag te nemen.
Kleinere foto's vallen dan nog mee met ~0.2 sec.

Nu heb ik aan de hand daarvan nog wat getest.
Maar nu lijkt het toch weer mee te vallen.
Ik heb gewoon wat foto's gepakt, en een versimpelde versie doet meestal ongeveer 0.07 sec over.
En of ik die foto nog verklein of niet heeft bijna geen invloed.

Wat ik me nu afvraag, is het wel dat script wat de problemen veroorzaakt?
Het is een geshared servertje, maar als ik flink ga f5-en dan gaat het toch niet goed.

En wat is de bottle neck van dit script, er zit ook nog een mysql-query in, maar voor de test heb ik die even weg-gecomment.
Het resizen heeft in mijn (onbetrouwbare, niet-representative) tests niks uitgemaakt.
Is het alleen het feit dat php het bestand van de hdd afhaald en verzend zo zwaar, zo apache zelf dat beter kunnen?

Kortom, maak ik me druk om niks, of is er wel degelijk iets niet helemaal goed.

Is de source nog van belang?

[Voutloos]

Als voor elke pageview dezelfde resize acties plaats moeten vinden, sla het resultaat dan gewoon ergens op. Is ook wel zo sociaal qua performance richting de andere gebruikers op die sharded hosting bak.

[Verwijderd]

Klopt, het zijn veelal dezelfde resoluties die worden weergegeven.
Maar wat ik me dus eigenlijk afvraag is:
Is het wel verstandig php gebruiken voor het verzenden van foto's en andere bestanden?

Heb nu dit voorbeeld gevonden.
Heeft iemand hier ervaring met een vergelijkbaar script?

[djc]

Als je plaatjes op diverse groottes wil laten zien is het een nette oplossing om die verschillende versies bij voorbaat te maken, ze op te slaan op de harde schijf en er direct naar verwijzen (haal ze dus niet door een PHP-script).

[MBV]

@Manuzhai: ik gebruik het rechtstreeks doorgeven van de cache, mag dat wel?

@TS: Het probleem zit hem in de GD library, zoals ook in de FAQ is te lezen. GD is namelijk erg traag. Als je geen shell-access hebt zal je dus zoieso moeten cachen. De imagemagick library is 2x zo snel, en dat is degene die ik nu gebruik voor mijn site op linux. Maar ook dat is eigenlijk alleen maar te doen met cachen.

[Soultaker]

GD is traag; ImageMagick is sneller, maar nog blijft het ondoenlijk om steeds alle plaatjes te resizen. Je zult ze echt ergens moeten cachen.

Wat ik zelf het meest praktische vind, is een cache tabel aanleggen in de database. Ik genereer dan niet alle plaatjes vooraf, maar on-demand. Het resultaat gaat in de cache tabel, en kan later gebruikt worden. Eens in de zoveel tijd mik je de hele cache tabel leeg. Overigens werkt deze aanpak vooral goed als je genoeg webruimte hebt (dedicated hosting bv).

Het voordeel van het systeem is dat het heel flexibel is, en je nooit fouten krijgt van plaatjes die ontbreken of de verkeerde grootte hebben. In het ergste geval (als je de cache net geleegt hebt) moet je alle plaatjes ter plekke genereren, net zoals nu, maar in de meeste gevallen kun je een plaatje gewoon uit de cache vissen.

Manuzhai schreef op dinsdag 29 augustus 2006 @ 19:54:
Als je plaatjes op diverse groottes wil laten zien is het een nette oplossing om die verschillende versies bij voorbaat te maken, ze op te slaan op de harde schijf en er direct naar verwijzen (haal ze dus niet door een PHP-script).

Het probleem hiermee is dat als je ergens een resolutie aanpast, je alle bestaande plaatjes opnieuw moet genereren. Verder is PHP snel genoeg. Zeker als je lokale bestanden via fpassthru servet, maar zelfs als je ze uit een database haalt, is PHP niet de bottleneck, maar het resizen.

[ Voor 48% gewijzigd door Soultaker op 30-08-2006 01:23 ]

[Verwijderd]

Soultaker schreef op woensdag 30 augustus 2006 @ 01:19:
verhaal

Klinkt als een goed idee.
Bottleneck is dus als ik het goed begrijp:

PHP:

$img = imagecreatefromjpeg("./foto.jpg");
imagejpeg($img);

Bedankt allemaal, kan ik voorlopig weer verder

[netvor]

Mijn ervaring is dat zowel fread/echo loops als fpassthru een hoge CPU load met zich mee brengen.

Helaas gebruiken vrij veel kant-en-klare PHP applicaties deze methode om bijvoorbeeld Access Control uit te voeren op downloads of plaatjes, in de trant van: klopt de hash van jouw sessie cookie met $foo ? Dan krijg je je bestandje, anders niet.

Als je gebruik maakt van Apache om dit soort bestanden te serveren, dan is de CPU load uiterst miniem. En je hebt het voordeel dat Apache uit zichzelf de goede headers meestuurt, dus geen gezeik met een brakke PHP applicatie die een plaatje als text/html uitspuugt.

Ik zat laatst een beetje te brainstormen over het fread/echo probleem, wat ook mijn eigen site/server treft, en ik kwam tot het volgende:

Laat Apache doen waar het voor gemaakt is. Dat betekent dat plaatjes gewoon vanaf het filesystem geserved moeten worden, door Apache zelf.

Helaas integreert Apache niet netjes met jouw eigen ACL systeem wat je in je applicatie hebt. Of wel? Ik zat te denken aan een oplossing waar je mod_rewrite gebruikt. Je kan dan je applicatie aanroepen in een RewriteCond. Je scriptje krijgt dan een URL van buitenaf als input, en geeft een URI op het lokale filesystem als output.
Wat je script doet mag je zelf weten. Misschien alleen ACL checken, of misschien ook resizen enzo. Het resultaat kan je als je wilt in een cache zetten en de cache-entry in je DB loggen.
Anyway, er komt een lokale URI uit je script. Het bestand op die locatie wordt vervolgens door Apache verstuurd.

Een andere optie is om "ouderwets" je PHP script de URL te laten afhandelen, maar om dan ipv fread/echo een HTTP 301/302 te versturen naar een temporary URL. Dit heeft echter vele nadelen:
* Een extra HTTP request, meer dataverkeer en meer tijd
* "Google-unfriendly"
* mogelijk een security hole, aangezien die temporary URL's theoretisch door het hele internet opgevraagd kunnen worden. Met wat Apache trucjes kan je dat deels verhelpen, maar als je toch Apache trucjes gaat uithalen kan je net zo goed mijn eerste optie volgen.


Oef, dat was ff iets langer dan ik had gedacht. Excuses voor het hijacken van je topic, ook al is het min of meer on-topic.

[Verwijderd]

imp schreef op woensdag 30 augustus 2006 @ 14:44: lang verhaal

Mja, het is niet zo dat het allemaal hartstikke professioneel is hoor, het is meer dat we een foto-album wel leuk vonden. En in plaats van iets als gallery oid te gebruiken leek zelf iets proggen me een betere oplossing. Afijn, de scripts bijna af, en ik kom tot de conclusie dat de basis van dat alles een nogal hoge load veroorzaakt.
Vandaar dat ik graag dat scriptje verander zonder dat ik de rest hoef te herschrijven.
Het is dus niet zo dat apache niet integreert of Access Control nodig is.

Het is een shared hosting server, apache tweaken zal hem niet worden denk ik.
Je tweede optie lijkt mij wel te doen.
*google is niet van belang, wat doet die dan verkeerd met temporary URL?
* security is niet aan de orde, het zijn maar wat simpele fototjes.

De extra bandbreedte/tijd lijkt mij miniem.
Het lijkt mij wel een proberen waard.

Oef, dat was ff iets langer dan ik had gedacht. Excuses voor het hijacken van je topic, ook al is het min of meer on-topic.

Goede argumentatie/commentaar is altijd welkom


edit: Ik heb het nu even zo gedaan:

PHP:

header("Location: $Redir");

Maar dat lijkt dezelfde load problemen op te leveren

[ Voor 5% gewijzigd door Verwijderd op 30-08-2006 17:41 ]

[Voutloos]

Verwijderd schreef op woensdag 30 augustus 2006 @ 17:20:
edit: Ik heb het nu even zo gedaan:

PHP:

header("Location: $Redir");

Maar dat lijkt dezelfde load problemen op te leveren

Dit heeft ook geen nut vergeleken direct de goede url voor plaatjes neer te zetten.

En resize je dan nog wel steeds on-the-fly?

[Verwijderd]

Voutloos schreef op woensdag 30 augustus 2006 @ 19:35:
[...]
Dit heeft ook geen nut vergeleken direct de goede url voor plaatjes neer te zetten.

En resize je dan nog wel steeds on-the-fly?

klopt, zo heb ik het nu dan ook maar gedaan, dan maar van tevoren resizen.
Dit topic was dan ook eigenlijk een beetje nutteloos achteraf