[PHP] html_entity_decode traag

[plofkip]

Hey GoT gasten!

Ik heb even een vraagje, hoop dat iemand me, en eventueel ook andere GoT-ters, kan helpen...
Ik haal wat item op uit een database, waarvan 1 veld 'description' heet. Dit veld bevat een string van ongeveer 500 tekens en is html ge-encodeerd (dus met < en > enzovoorts).
Ik haal 10 van deze items op.
Dit wil ik natuurlijk als html weergeven op een pagina, dus gebruik ik de functie html_entity_decode om de string om te zetten naar normale tekst, zodat je niet "<a href="bla">Dit is de tekst van iets</a><img src="flkdkjslfklfsdk.jpg" />" ziet op de pagina, maar normale tekst en plaatjes...

Het probleem is nu:
De functie doet er 6 seconden over om dit te doen Dit vind ik echt belachelijk lang! Weet iemand de oorzaak hiervan en een manier om dit sneller te doen?

[Janoz]

Ten eerste zou het geen 6 seconde hoeven duren. Kun je wat stukjes code laten zien? Ten tweede vraag ik em af waarom je de boel htmlencoded in je database opslaat. Dat laatste lijkt me helemaal nergens voor nodig.

[plofkip]

Ik heb 2 scenario's:
- Zonder html_entity_decode
- en met...

Het eerst duurt 1 seconde, het tweede 7 seconden...

[Marcj]

Hoevaak wordt die functie dan aangeroepen? Wat 500 tekens decoden kan in een microseconden oid, dat mag echt geen seconden duren.

[stekkel]

Probeer eens alleen de encoded < > ' en " te vervangen met een str_replace call. str_replace lijkt me namelijk vele malen sneller dan html_entity_decode.

[plofkip]

stekkel schreef op woensdag 11 april 2007 @ 14:43:
Probeer eens alleen de encoded < > ' en " te vervangen met een str_replace call. str_replace lijkt me namelijk vele malen sneller dan html_entity_decode.

Er komen ook tekens als ' in voor....

Een stukje code:

PHP:

$query = "Een query";
$get_clicks = mysql_query($query);
while ($row = mysql_fetch_array($get_clicks, MYSQL_ASSOC)) {
    $click['title'] = $row['title'];
    $click['description'] = html_entity_decode($row['description']); // Traag
    //$row['description'] = $click['description']; // Snel
    $click['url'] = $row['url'];
    $click['time'] = $row['time'];
    $click['click_id'] = $row['id'];
    $click['serviceurl'] = $row['servicetitle'];
    $click['servicename'] = $row['name'];
    array_push($clicks, $click);
}
return $clicks;

[ Voor 72% gewijzigd door plofkip op 11-04-2007 14:59 ]

[Janoz]

Wat een enorm vreemde en omslachtige manier van het uitlezen van je resultaten. Wat wil je hier uberhaupt mee bereiken?

[plofkip]

Janoz schreef op woensdag 11 april 2007 @ 14:52:
Wat een enorm vreemde en omslachtige manier van het uitlezen van je resultaten. Wat wil je hier uberhaupt mee bereiken?

Als je feedback geeft zou je het dan ook kunnen onderbouwen?
Ik wil hiermee bereiken dat de namen van mijn array overeenkomen met de namen waar ik later mee werk, opzich kan die foreach weg en de inhoud ervan in de while loop ja...

[stekkel]

FaNtJuH schreef op woensdag 11 april 2007 @ 14:47:
[...]

Er komen ook tekens als ' in voor....

Een stukje code:

PHP:

$query = "Een query";
$get_clicks = mysql_query($query);
while ($row = mysql_fetch_array($get_clicks, MYSQL_ASSOC)) {
    $row['click_id'] = $row['id'];
    array_push($clicks, $row);
}
foreach($clicks as $click) {
    $row['title'] = $click['title'];
    $row['description'] = html_entity_decode($click['description']); // Deze is traag
    //$row['description'] = $click['description']; // Deze gaat wel snel!
    $row['url'] = $click['url'];
    $row['time'] = $click['time'];
    $row['click_id'] = $click['id'];
    $row['serviceurl'] = $click['servicetitle'];
    $row['servicename'] = $click['name'];
    array_push($result, $row);
}
return $result;

performance tip 2 uit de php manual:

Note: If you use array_push() to add one element to the array it's better to use $array[] = because in that way there is no overhead of calling a function.

Bovendien, zoals Janoz al opmerkte, het is wat omslachtig. Al je foreach acties (voor zover die al nodig zijn) zou je ook in je eerste while lus kunnen afhandelen.

[Janoz]

je plemt alles eerst in de ene array en plempt het vervolgens weer in een andere array en geeft het daarna pas terug en vraag je vervolgens af waar performance problemen vandaan komen

Als je kolomnamen niet overeen komen met wat je verwacht kun je ook dingen doen als:

Select id as click_id, title, description, url, time, id, servicetitle as serviceurl, servicename as name enz...

--

Daarnaast was het niet echt feedback, ik was gewoon benieuwd hoe je er uberhaupt bij gekomen was om een dergelijke constructie te bedenken.

[ Voor 16% gewijzigd door Janoz op 11-04-2007 15:05 ]

[plofkip]

Janoz schreef op woensdag 11 april 2007 @ 15:00:
je plemt alles eerst in de ene array en plempt het vervolgens weer in een andere array en geeft het daarna pas terug en vraag je vervolgens af waar performance problemen vandaan komen

Als je kolomnamen niet overeen komen met wat je verwacht kun je ook dingen doen als:

Select id as click_id, title, description, url, time, id, servicetitle as serviceurl, servicename as name enz...

Kijk daar kan ik al meer mee, maar toch is het snel als ik html_entity_decode niet gebruik, dus dat is sowieso hetgeen die performance naar beneden haalt...

[Janoz]

Hoeveel records haal ej eigenlijk op? En gebruik je die allemaal ook? Daarnaast staat een eerdere vraag ook nog steeds. Waarom heb je het eigenlijk uberhaupt html encoded in je database staan.

[stekkel]

FaNtJuH schreef op woensdag 11 april 2007 @ 15:01:
[...]

Kijk daar kan ik al meer mee, maar toch is het snel als ik html_entity_decode niet gebruik, dus dat is sowieso hetgeen die performance naar beneden haalt...

probeer nu eens:

PHP:

$row['description'] = str_replace(array("&quot;","'","&lt;","&gt;"),array("\"","'", "<",">"),$click['description']);

[ Voor 4% gewijzigd door stekkel op 11-04-2007 15:08 ]

[plofkip]

Janoz schreef op woensdag 11 april 2007 @ 15:06:
Hoeveel records haal ej eigenlijk op? En gebruik je die allemaal ook? Daarnaast staat een eerdere vraag ook nog steeds. Waarom heb je het eigenlijk uberhaupt html encoded in je database staan.

Ik haal er 10 op, die gebruik ik allemaal. Ik weet niet precies waarom het encoded in de database staat, is een keuze die gemaakt is op mijn werk zodat je snel RSS feeds kunt genereren zonder te encoden.

[crisp]

FaNtJuH schreef op woensdag 11 april 2007 @ 15:11:
[...]

Ik haal er 10 op, die gebruik ik allemaal. Ik weet niet precies waarom het encoded in de database staat, is een keuze die gemaakt is op mijn werk zodat je snel RSS feeds kunt genereren zonder te encoden.

Die hadden nog nooit van CDATA gehoord?

[plofkip]

crisp schreef op woensdag 11 april 2007 @ 15:19:
[...]

Die hadden nog nooit van CDATA gehoord?

Quote van iemand van mn werk:

"CDATA maakt niet uit bij dingen als &-tekens in de feed enzo staan, dan is t geen valid RSS"

We zitten ook al te kijken of we het RAW kunnen dumpen in de database, maar zolang dat niet gebeurt wil ik graag verder praten over mijn originele vraag

[hamsteg]

Janoz schreef op woensdag 11 april 2007 @ 15:06:
Hoeveel records haal ej eigenlijk op? En gebruik je die allemaal ook? Daarnaast staat een eerdere vraag ook nog steeds. Waarom heb je het eigenlijk uberhaupt html encoded in je database staan.

Ik doe dat ook standaad Ik heb maar twee plekken waar strings in de database komen (insert + modify) en een stuk of veel plekken waar ze er weer uitgehaald worden. Door dit structureel op deze twee plekken te doen weet ik zeker dat er geen lekken onstaan. Noem het luiheid maar voor mij is het eenduidig.

BTW. dit soort vertragingen heb ik absoluut niet. Wat gebeurt er als de de data eerst in een locale variable zet en deze decode?

PHP:

$row['description'] = $click['description'];
$row['description'] = html_entity_decode($row['description']);

Structurele vraag, waarom zet je alles uberhaubt in een tweedim array? Je hebt volgens mij bij gebruik van een database geen arrays meer nodig voor locale opslag, hoogstens de actieve fetch en die zou ik splitten list()-en naar locale niet-array variabelen.

PHP:

list( ...,$sDescription, ...) = $click;
$sDescription = html_entity_decode($sDescription);

[ Voor 17% gewijzigd door hamsteg op 11-04-2007 15:34 . Reden: Structurele vraag / split vs. list ]

[plofkip]

Locale var ervan maken geeft geen verschil...

[crisp]

FaNtJuH schreef op woensdag 11 april 2007 @ 15:22:
[...]

Quote van iemand van mn werk:

"CDATA maakt niet uit bij dingen als &-tekens in de feed enzo staan, dan is t geen valid RSS"

que?

[Confusion]

Welk stuk script heb je precies getimed? Als je zo'n description in een string stopt en dan de encode functie eroverheen rost, is het dan ook traag?

[plofkip]

crisp schreef op woensdag 11 april 2007 @ 15:30:
[...]
que?

Laten we dit even buiten beschouwing laten want ik weet er het fijne niet vanaf, er wordt op het moment sowieso gekeken of we het RAW op kunnen slaan, maar stel dat dat niet lukt dan zou ik graag willen weten hoe ik dit op kan lossen... Of hoe we kunnen voorkomen dat we de DB moeten wijzigen...

Confusion schreef op woensdag 11 april 2007 @ 15:34:
Welk stuk script heb je precies getimed? Als je zo'n description in een string stopt en dan de encode functie eroverheen rost, is het dan ook traag?

FaNtJuH schreef op woensdag 11 april 2007 @ 15:27:
Locale var ervan maken geeft geen verschil...

[ Voor 33% gewijzigd door plofkip op 11-04-2007 15:37 ]

[crisp]

De vraag is: hoe encoden ze? mogelijk dat html_entity_decode wel gewoon overkill is en een gewone replace veel sneller is, bijvoorbeeld:

PHP:

function unhtmlspecialchars($string)
{
    return strtr(   $string,
            array(  '&'     => '&',
                ''' => '\'',
                '"'    => '"',
                '&lt;'      => '<',
                '&gt;'      => '>'
            )
    );
}

[Confusion]

Ik bedoel: als je de code compleet lostrekt uit het script, zo'n brok html_encoded zut uit de database eventjes in een string zet en daar dan (zoveel keer als nodig is) de html_entity_encode functie overheen haalt.

Dan weet je tenminste zeker dat het de functie is en niet een samenspel van andere omstandigheden, die alleen maar op traagheid van die functie lijken te wijzen.

[stekkel]

crisp schreef op woensdag 11 april 2007 @ 15:40:
De vraag is: hoe encoden ze? mogelijk dat html_entity_decode wel gewoon overkill is en een gewone replace veel sneller is, bijvoorbeeld:

PHP:

function unhtmlspecialchars($string)
{
    return strtr(   $string,
            array(  '&'     => '&',
                ''' => '\'',
                '"'    => '"',
                '&lt;'      => '<',
                '&gt;'      => '>'
            )
    );
}

Tja, dat probeer ik de hele tijd duidelijk te maken (str_replace is overigens sneller dan strtr, maar dat terzijde) maar de TP hapt nog niet.

[plofkip]

Ok ik heb die functie geprobeert maar is niet sneller...
Ik zal zo is testen hoe het gaat in een los script...

EDIT:

Hmm dat gaat inderdaad wel snel.... Waardoor zou ik ervoor kunnen zorgen dan dat dit traag gaat vraag ik me af?
Denk dat ik maar even ga print_r-en en die-en op steeds verdere plekken...

[ Voor 48% gewijzigd door plofkip op 11-04-2007 15:58 ]

[crisp]

stekkel schreef op woensdag 11 april 2007 @ 15:43:
[...]


Tja, dat probeer ik de hele tijd duidelijk te maken (str_replace is overigens sneller dan strtr, maar dat terzijde) maar de TP hapt nog niet.

str_replace is bij mij 15% trager en levert bovendien foute resultaten op als je niet oppast:

PHP:

$s = '"tralala"';

$t = str_replace(   array(  '&',
                '"',
                ''',
                '<',
                '>'
            ),
            array(  '&',
                '"',
                '\'',
                '<',
                '>'
            ),
            $s
);

echo $t; // geeft "tralala" ipv &quot;tralala&quot;

(in dit geval moet je &amp; uiteraard achteraan zetten om dat op te lossen maar bij strtr hoeft dat niet)

[ Voor 8% gewijzigd door crisp op 11-04-2007 16:04 ]

[stekkel]

FaNtJuH schreef op woensdag 11 april 2007 @ 15:45:
Ok ik heb die functie geprobeert maar is niet sneller...
Ik zal zo is testen hoe het gaat in een los script...

EDIT:

Hmm dat gaat inderdaad wel snel.... Waardoor zou ik ervoor kunnen zorgen dan dat dit traag gaat vraag ik me af?
Denk dat ik maar even ga print_r-en en die-en op steeds verdere plekken...

Omdat html_entity_decode een enorme array met replace characters bevat en daarom traag wordt.

@crisp
Daarom had ik die &amp; replacement er buiten gelaten. Dat strtr bij jou sneller is verbaast me. Wel interessant trouwens. Ik zal binnenkort eens gaan testen want 15% is wel erg veel performanceverschil.

[crisp]

stekkel schreef op woensdag 11 april 2007 @ 16:39:
[...]


Omdat html_entity_decode een enorme array met replace characters bevat en daarom traag wordt.

@crisp
Daarom had ik die

code:

&

replacement er buiten gelaten. Dat strtr bij jou sneller is verbaast me. Wel interessant trouwens. Ik zal binnenkort eens gaan testen want 15% is wel erg veel performanceverschil.

Och, uiteindelijk praat je over 0.01 seconde verschil op 10.000 replaces - niet iets om wakker van te liggen hoor

[Confusion]

stekkel schreef op woensdag 11 april 2007 @ 16:39:
Omdat html_entity_decode een enorme array met replace characters bevat en daarom traag wordt.

Als die methode fatsoenlijk geimplementeerd is, dan zitten de te vervangen characters in een hashtable en is er geen enkele reden om zo extreem traag te zijn. Ik heb niet veel ervaring met PHP, maar de gelijksoortige functies in Java en Python vertonen dit gedrag niet en er is geen enkele reden waarom het dat in PHP wel zou moeten doen.

[hamsteg]

Ik denk toch dat je de oplossing moet zoeken in de gekozen structuur/architectuur van het PHP script. Al eerder is gewezen op de twee-dimensionale array die met push wordt opgebouwd. Vanuit mijn embedded ervaring weet ik dat er een duidelijk verschil kan zijn tussen array gebruik en gebruik van direct adresseerbare variabelen (een array is een adressering met een bepaalde offset en vereist dus extra rekenwerk). Het kan zijn dat html_entity_decode implemen tatie hier niet lekker mee overweg kan maar ik heb het nooit bewust gezien.

Wat mij triggered in je implementatie is het feit dat je vanuit je database weer een array opbouwd (een sub-database dus). Kijk eens of je de opbouw van je pagina's nog beter in combinatie met SQL kunt doen. Data pas ophalen als je het werkelijk nodig bent en niet vooraf in een array klaarzetten.

PS ik ben het met je keuze eens dat je code ge-encode wegzet en expliciet decode waar je het als HTML wilt gebruiken. Vanuit security aspecten vind ik dit een veilige benadering. Bij vele van onze klanten doen we dat ook maar hebben we niet dit soort vertragingen geconstateerd. Omdat veel verschillende mensen in dezelfde code programmeren is bij ons dit besluit genomen, liever iets meer overhead dan een mogelijk veiligheidslek door onzorgvuldigheid (yep, de mens is vergeetachtig of staat onder druk om een tijdsplanning te halen en neemt dan verkeerde short-cuts).

Ik ben dus ook benieuwd wat het is ...

[ Voor 11% gewijzigd door hamsteg op 11-04-2007 20:38 . Reden: PS added ]

[plofkip]

Lees mijn laatste reactie sowieso even:
FaNtJuH in "[PHP] html_entity_decode traag"

[plofkip]

OK ik heb de fout gevonden... het is een door mijzelf gemaakt image resize functie
Ik weet het, waarschijnlijk ziet de code er heel vies uit voor jullie, maar ik was er best trots op
Kunnen jullie deze code analyseren?

PHP:

function imageSizer($description) {
    $images = array();
    $imgIndex = stripos($description, '<img');
    $temp = $description;
    while($imgIndex > -1) {
        $temp2 = substr($temp, $imgIndex);
        $imgEnd = stripos($temp2, '>');
        $imgTag = substr($temp, $imgIndex, $imgEnd+1);
        $temp = substr($temp, $imgEnd+1);
        array_push($images, $imgTag);
        $imgIndex = stripos($temp, '<img');
        if($imgIndex == false) {
            break;
        }
    }
    foreach($images as $image) {
        $imgUrlBegin = stripos($image, 'src=')+5;
        $temp = substr($image, $imgUrlBegin);
        $imgUrlEnd = stripos($temp, '"');
        if(empty($imgUrlEnd)) {
            $imgUrlEnd = stripos($temp, "'");
        }
        $imgUrl = substr($image, $imgUrlBegin, $imgUrlEnd);
        $myimg = getimagesize($imgUrl);
        $this->click['description'] = str_ireplace($image,"<img border=\"0\" src=\"" . $imgUrl . "\" " . $this->resize->Resize($myimg[0], $myimg[1], 200) . " />",$this->click['description']);
    }
}

[ Voor 86% gewijzigd door plofkip op 11-04-2007 23:54 ]

[--MeAngry--]

Leuk script enzo, maar waar kunnen wij dat terugvinden in de code die je eerder geplaatst had. Want daar was het enige verschil toch de html_entity_decode functie?

[plofkip]

Ja maar dit wordt verderop in het script uitgevoerd, zoals ik al in een vorige reactie zei: als ik een print_r() en dan een die() na het aanroepen van de functie in mijn TS gaat het wel snel, dus het probleem zat ergens anders. Aangezien mijn resize functie niks veranderd aan de ge-encodeerde (originele) tekst ging dat snel, maar met decoded tekst gaat het sloom en dat komt door die functie.
(als ik hem niet aanroep komt de pagina namelijk meteen)

[Voutloos]

Nofi, maar we zouden toch gek zijn als we dit hele script zouden uitpluizen. Heb je al eens achterhaald hoe lang elke iteratie binnen de 2 loops in deze functie duurt? Wat doet $this->resize->Resize()? Je gebruikt deze functie omdat de functie blijkbaar de filename retourneert, maar wordt er niet steeds stiekem een resize gedaan? Etc. etc.

Oftewel, wat heb je zelf geprobeerd?

[ Voor 3% gewijzigd door Voutloos op 12-04-2007 08:28 ]

[Janoz]

Het is niet heel vreemd waarom het gebruik van de entity decode voor de vertraging zorgt. Het niet decoderen zorgt ervoor dat er geen <img voorkwam in de code waardoor die resize functie niet werd uitgevoerd.

Waarom die functie traag is kan komen door verschillende factoren. Gebruik je absolute of relative paden? Zeker in het eerste geval kan het voor enorme vertragingen zorgen wanneer plaatjes eerst helemaal ingeladen moeten worden voor het bepalen van de afmeting.

[Stamgastje]

FaNtJuH schreef op woensdag 11 april 2007 @ 23:51:
OK ik heb de fout gevonden... het is een door mijzelf gemaakt image resize functie
Ik weet het, waarschijnlijk ziet de code er heel vies uit voor jullie, maar ik was er best trots op
Kunnen jullie deze code analyseren?

Wat jij doet is ongeveer dit:

1. string doorlopen op <img> tags, alle tags in een array $images gooien
2. deze array weer(!) doorlopen en de urls weer uit de tags halen

Dit kan een stuk netter (en waarschijnlijk ook veel sneller) met regular expressions.

Verder gebruik je de functies getimagesize() en $this->resize->Resize(), ik vermoed dat daar de grootste vertraging in zit.

Edit: overigens zorgt een statement als "$temp = substr($temp, $imgEnd+1);" ook voor vertraging, waarom moet die string steeds ingekort worden? Je kunt ook gewoon pas op een bepaalde plaats in de string gaan zoeken. Uit de PHP documentatie (let op de int $offset):

code:

int stripos ( string $haystack, string $needle [, int $offset] )

[ Voor 18% gewijzigd door Stamgastje op 12-04-2007 08:52 ]

[Janoz]

hamsteg schreef op woensdag 11 april 2007 @ 20:29:
PS ik ben het met je keuze eens dat je code ge-encode wegzet en expliciet decode waar je het als HTML wilt gebruiken. Vanuit security aspecten vind ik dit een veilige benadering. Bij vele van onze klanten doen we dat ook maar hebben we niet dit soort vertragingen geconstateerd. Omdat veel verschillende mensen in dezelfde code programmeren is bij ons dit besluit genomen, liever iets meer overhead dan een mogelijk veiligheidslek door onzorgvuldigheid (yep, de mens is vergeetachtig of staat onder druk om een tijdsplanning te halen en neemt dan verkeerde short-cuts).

Waarom zo het niet secure zijn? Op deze manier koppel je je data wel heel erg sterk aan html. Of je nu afspreekt dat bij het erin gaan er ge-encode moet worden of bij het eruit halen afhankelijk van de toepassing ge-ecode moet worden lijkt me een even makkelijk te handhaven afspraak. Het verschil is echter dat je in het tweede geval je data in de database niet aan het vervuilen bent. Wat nu als je de tekst in een pdf of een (non html) email wilt hebben?

In het geval van php is mysql_real_escape genoeg om te voorkomen dat er problemen optreden. In andere talen/omgevingen heb je daar gelukkig geparameteriseerde queries voor.

[ReverendBizarre]

Janoz schreef op donderdag 12 april 2007 @ 08:51:
[...]In andere talen/omgevingen heb je daar gelukkig geparameteriseerde queries voor.

In PHP (i.c.m. met MySQL 4.1+) kan dat gelukkig ook. http://nl2.php.net/manual/en/ref.mysqli.php

Security is in ieder geval geen goede reden om htmlentities() te gebruiken. Als dat je drijfveer is moet je gewoon inderdaad geparameteriseerde queries gebruiken (sowieso de beste optie) of anders addslashes() of beter nog mysql_real_escape_string(). Dan vang je alle potentieel gevaarlijke karakters af zonder nodeloos allerlei dingen naar HTML entities te zitten converteren.

[Voutloos]

Nofi, maar als je op dat punt htmlentities gebruikt heb je gewoon duidelijk niet begrepen wat escaping en wat data van presentatie scheiden is.

[plofkip]

Het probleem was de php functie getimagesize()... Deze gebruik ik om de originele width en height van een plaatje op te halen, zodat ik de verhouding weet tussen de width en height, voor het resizen...

Weet iemand een snelle alternatieve oplossing?

ps1. Heb al gezocht op google
ps2. Ik gebruik externe images

[ Voor 32% gewijzigd door plofkip op 25-04-2007 16:21 ]

[Swaptor]

externe images?
Als in plaatjes die van andere webservers afgetrokken moeten worden?

If so, daar is je snelheidsverlies.

[plofkip]

Inderdaad...
Ik geef plaatjes nu gewoon standaard een width van 200px en de height past zich automatisch aan, met een onclick die het plaatje in een nieuw scherm opent

[Gomez12]

Simpele suggestie, alhoewel ik zou zeggen dat je je hele programma anders moet opbouwen.

Cache je image sizes. Bereken ze bij het posten, dan weet je ze al bij het ophalen van de data. Indien nodig laat je de client het werk verrichten via JS en post je de gegevens weer terug ( is ook te gebruiken tijdens periodiek weergeven om te zien of er geen ander plaatje / andere grootte op dezelfde locatie zit ).

Want wat je nu doet is gewoon bij elke request het totale plaatje naar je server toehalen. Deze gaat kijken hoe groot het is en stuurt dan naar de client een link naar het originele plaatje. Genereert leuke inkomende data hoeveelheden als ik mijn foto-boek daar ga posten

[Verwijderd]

Misschien is het in dat geval handig om te laten zien hoe je de functie aanroept, het probleem zal dan eerder daar zitten. Het aanroepen van een zelfgemaakte functie verklaart namelijk niet de extra overhead, tenminste niet in die hoedanigheid.

zo gisteravond gewoon ff pagina 2 over het hoofd gezien

[ Voor 13% gewijzigd door Verwijderd op 08-05-2007 12:10 ]

[Voutloos]

FaNtJuH schreef op woensdag 25 april 2007 @ 16:20:
ps2. Ik gebruik externe images

Je hebt al een db entry voor elk plaatje blijkbaar, voeg daar dan velden voor de afmetingen aan toe.

Je huidige aanpak is zeer slecht: eerst haalt de server het plaatje op, en vervolgens moet de client dat ook nog steeds doen. Slecht voor performance, load, bandbreedte en ga zo maar door. Dit soort constructies zouden gewoon nooit mogen voorkomen zonder caching. Tevens heeft de beheerder van de server waar de plaatjes vandaan komen nu eerlijk gezegd groot gelijk als hij jouw ip's zou bannen.

[hamsteg]

Als de constructie echt nodig is doe dan wat Voutloos zegt en voeg daar dan velden voor de afmetingen aan toe. Als deze velden niet zijn ingevuld doe je eenmalig je berekeningen zoals nu en vul je de velden met de antwoorden. Elke volgende gebruiker hoeft dan niet meer onnodig te wachten omdat dan de gegevens wel klaar staan in je database.

[Gomez12]

hamsteg schreef op dinsdag 08 mei 2007 @ 08:34:
Als de constructie echt nodig is doe dan wat Voutloos zegt en voeg daar dan velden voor de afmetingen aan toe. Als deze velden niet zijn ingevuld doe je eenmalig je berekeningen zoals nu en vul je de velden met de antwoorden. Elke volgende gebruiker hoeft dan niet meer onnodig te wachten omdat dan de gegevens wel klaar staan in je database.

Dan krijg je alleen een probleem als iemand een plaatje vervangt door een ander plaatje met dezelfde naam maar andere afmetingen en content. Daarom zoals ik al eerder zei zo af en toe gewoon een client-side javascript uitvoeren die gewoon opnieuw de afmetingen berekend en indien veranderd dan opnieuw opslaan in de dbase.

[plofkip]

Zijn inderdaad leuke oplossingen, maar zoals ik het nu heb is het ook prima! In ieder geval bedankt!