eksekvere kode efter header-redirect

Hvis jeg må spørge, hvorfor vil du køre kode efter header?
Og hvad er præcis din plan? :o)

Af forskellige årsager, bla. for at skrive forskellige statistikker i databasen. Alle beregninger der ikke skal bruges til at videresende brugeren er der jo ingen grund til at brugeren venter på... Og hvis man ønsker at lave sql-kald til servere der ikke er localhost (eller på samme LAN som webserveren) kan det hurtigt mærkes ved at browseren hænger lidt før man bliver sendt videre.

Et PHP script tager den tid det tager at loade, hvis du bare sender videre før dine query's vil de ikke blive sendt eller tage mindst lige saa længe som at putte dem øverst. exit() sørger bare for at der ikke bliver gjort/udskrevet mere..

header("Location: http://www.dr.dk");
flush();
LangsomFunktion(...);

Ovenstående vil vel sørge for at brugeren bliver sendt til dr.dk selvom scriptet kører et stykke tid efter? Flush() tvinger alt output ud til browseren og browseren venter vel ikke på at scriptet er kørt færdigt med at hoppe videre?

<ole>

At forsøge at løse noget på den måde, giver ingen mening. Jeg forstår stadig ikke, hvad du vil - og hvorfor  :)

/mvh
</bole>

Jeg er ved at lave et linksystem, hvor jeg har bannere rundt omkring på andre hjemmesider, når brugere klikker på mine bannere bliver de sendt til min side hvor jeg "registrerer" deres klik og sender dem til den hjemmeside banneret reklamerer for. Men da jeg skal udføre en del ting samtidig med at jeg "registrerer" brugerklikket vil jeg gerne sende brugeren videre først og derefter "registrere" klikket. Hvis det tager 2 sek. at køre hele scriptet igennem vil det jo genere brugeren: browseren hænger på min side i 2 sek før den videresendes til den relevante hjemmeside.

*phew* håber det hjalp  :o)  grundlæggende vil jeg bare vide om det kan influere på scriptets efterfølgende kørsel at man sender browseren, der startede scriptet, væk.

Jamen, når du redirecter, loades det andet dokument jo - og alt, der måtte være skrevet til browseren af det første forsvinder ... hvis det altså havde kunne ladet sig gøre  :)

Du må bare optimere resten af din kode - og her tør jeg æde min laptop på, der er rigtig store gevindster at hente - og så vente med at redirecte til efter, du har kørt dine funktioner.
Med fornuftig kode kan brugeren ikke mærke, han 'hænger' ... så kan du selv vurdere din kodes kvalitet  ;o)

Som eksempel kan nævnes at der stort set _aldrig_ bruges * i MySQL-forespørgsler. Kun nybegyndere i PHP bruger * - og gør det kun, indtil de opdager, at * bruges i eksempler og tutorials for at simplificere eksemplet. Meningen er næsten altid, at koderen selv skal skrive de felter, han har brug for at hente.
En anden klassiker er manglende - eller mangelfuld - indeksering af DB-tabeller i forhold til de aktuelle DB-kald.

Derudover er der hundredevis af andre ting, man kan gøre for at optimere sin kode  :)

Det er klart koden skal være optimal, det var ikke det jeg ville vide.

Det script der "redirecter" skriver ikke noget til browseren, eneste formål er at "redirecte" og registrere klikket.

Erfaringen fra Eksperten siger, at det er ofte, spørgeren ikke ønsker at høre løsningen på hans problem - men det skal ikke afholde mig fra at skrive den  :)

Det var dit eksempel (18/11-2005 18:28:02), der fik mig til at tro, du også ville outputte noget i dit dokument - men nu forstår jeg vist, hvad du har misforstået:
Det tager et ganske kort stykke tid, at hente det nye dokument (DR's index-side). Derfor kan noget efterfølgende script muligvis blive afviklet - alt efter, hvorlang tid, det tager at hente dokumentet. Derfor bruger man normalt exit().

Først når dokumentet er begyndt at ankomme til browseren - og browseren har læst noget af body-indholdet - kan du flush'e indhold af dokumentet ... men på det tidspunkt afvikles ikke mere script i det oprindelige dokument.
Det nye dokument er hentet, selvom det ikke er færdig-loaded.

Jeg har lavet masser af den slags registrerings løsninger - og brugeren behøver ikke at 'hænge'. Med effektiv kode, opdager han kun, han bliver redirected, hvis han er _virkelig_ opmærksom.

Hvis du synes, det er et problem, at brugeren 'hænger' i dit dokument, er den eneste løsning således at optimere din kode ... like it or not  :)

Det der har min interesse er blot om man risikerer at ens php-script bliver stoppet når brugerens browser loader en ny hjemmeside?

Men du har helt ret i, at udgangspunktet og målet bør være at scriptet er så optimalt at ovennævnte problematik slet ikke opstår. Af samme årsag er jeg netop gået i gang med at læse o'reillys "High Performance MySQL".  :)

Så er du og dine kommende MySQL-koder i rigtig gode hænder  ;o)

Om alle dine scripts kører færdig afhænger af, hvad det er, der køres ... det ville jeg _aldrig_ turde satse på!  :)

olebole, nu slapper vi lige af ;o)

Jeg bruger * ofte, da jeg for det meste udnytter alle data den henter, jeg vil sku heller skrive 'et tegn' end navnet paa 15 forskellige rows.

nizo >> Ellers tak - jeg har ingen trang til eller behov for at slappe af. Måske, du skulle vågne lidt op i stedet - så du kunne finde ud af at læse indenad  ;o)

"at der stort set _aldrig_ bruges * i MySQL-forespørgsler" ... bemærk: "stort set"

"Meningen er næsten altid, at koderen selv skal skrive de felter, han har brug for at hente" ... bemærk: "næsten altid"

Skal man bruge alle felter i hver række, bruger man naturligvis *

Nu ved jeg ikke, om du selv er begynder og det er årsagen til, du ikke kan kende forskel på rækker og kolonner, eller om det er en fejl, du roder rundt i det. Under alle omstændigheder er det tåbeligt at skrive en *, hvis du skal hente 15 felter udaf 25 i hver række.
Henter du data i mange rækker, overlæsser du jo derved serveren med en masse unødigt arbejde - og så er der tale om dårlig kode!

Det er ikke et spørgsmål om, hvad koderen har lyst til og/eller hvad han gider - men et spørgsmål om, hvad der performer bedst.
Undskyld mig, hvis du føler dig truffet - men det er børnelærdom for alle server-programmører  :)

- og som eksempel kan jeg nævne, at jeg for et halvt års tid siden var med til at rydde op i en større nyhedsportals PHP-scripts. Inden optimeringen meldte MySQL-serveren om 120% belastning. Efter at have ændret alle *'er - som var første hug i processen - var vi nede på omkring 65% ... alene ved at rydde op i *'er i MySQL-kaldene.

Så kan du jo selv overveje, om der evt. kunne være årsag til at overveje din egen kodestil  ;o)

Jeg viste ikke "SELECT * " i mysql performede så dårligt, personligt bruger jeg det aldrig, af den grund at jeg vil styre hvad det er jeg vil ha' ud, så er det nemlig muligt at tilføje felter i tabellen senere uden at skulle tjecke al koden igennem.

Anywayz Olebole - hvis du lægger et svar for din kommentar d. 19/11-2005 00:50:27, det er vidst det nærmeste jeg kommer svar på mit spørgsmål...  :o)

Prøv at se eksemplet med at hente 15 felter udaf 25. Her vil du hente de 15 felter, du har brug for i hver række ... plus 10, du ikke har brug for. Det er en _meget_ stor spild-procent.

Der er mange andre ting, man kan gøre. Hvis du f.eks. i en SELECT ved, du kun leder efter én bruger i din tabel, bør du sætte 'LIMIT 1' i kaldet. Ellers leder den resten af tabellen igennem efter flere mulige matches.

Det samme gælder ved UPDATE (og det er nok oftere overset):
    "UPDATE `tabel` ............. WHERE `user`='olebole' LIMIT 1"

- og et svar  :)

Takker - du er jo fyldt med tips  :o)  jeg er lutter ører

ehhhh ... forhåbentlig er du også andet end ører  ;D
Tak for points  :)

Nej, jeg vil ikke videre paastaa jeg er nybegynder.

Min tables er somregel ikke specielt store og derfor føler jeg ikke den store trang til at skærer ned paa udhentning af data da det foreskelllen paa loade tid ikke er meget størrer.