ntec Skrevet 2. november 2006 Rapporter Del Skrevet 2. november 2006 Jeg har laget et lite script som endrer på størrelsen på et bilde. Bildet skal automatisk endres til 640 pixler bred HVIS bildet er større enn dette. Men så oppstår et problem når jeg skal forminske veldig store bilder, og får denne feilmeldingen Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 1600 bytes) in /usr/home/web/wnoxxxx/ntec.no/home/inc/resize.php on line 35 Kan jeg forminske store bilder uten å bruke så mye minne? Eksempel på bilde som ikke lar seg forminske: http://home.ntec.no/gfx/bilder/temp/1_DSC00047.JPG Prøv scriptet her: http://ntec.no/home/inc/resize.php?bilde=h...SC00047.JPG&u=1 Lenke til kommentar
NH Skrevet 2. november 2006 Rapporter Del Skrevet 2. november 2006 dette går på oppsettet i PHP.ini denne må du endre. den er satt standard til 8MB som tillater bilder på maks 1280x1024 om jeg ikke husker feil... Lenke til kommentar
ntec Skrevet 2. november 2006 Forfatter Rapporter Del Skrevet 2. november 2006 jeg har webhotell hos web10, så jeg har ikke tillatelse til å endre på filen PHP.ini. Så det finnes ingen alternative løsninger på å forminske bilder? Lenke til kommentar
Jonhoo Skrevet 3. november 2006 Rapporter Del Skrevet 3. november 2006 Har hatt samme problemet tidligere, men fant aldri noen løsning.. Endte med at jeg bare satte en størrelsesbegrensning på alle bilder... Lenke til kommentar
allyse Skrevet 3. november 2006 Rapporter Del Skrevet 3. november 2006 Dette er et klassisk problem siden du må "uncompresse" alle bilder før du kan behandle dem. Pass på to ting ihvertfall. Ikke kjør exif-informasjonsgreier (dette tar mye minne etter hva jeg har hørt), og hvis du henter pr string (bruke fopen mv, og imagefromstring) så funker det til tider litt bedre enn hvis du henter rett fra jpg,png osv. To andre måter er å bruke ini_set(memory_limit, '36M') eller bruker .htaccess. For bildehehandling bør du ha rundt 36mb minne. Skriv også ren kode og lukk alle variabler mv. slik du ikke bruke unødig mye minne. Lenke til kommentar
ntec Skrevet 3. november 2006 Forfatter Rapporter Del Skrevet 3. november 2006 To andre måter er å bruke ini_set(memory_limit, '36M') eller bruker .htaccess. Hvordan skal .htaccess-fila se ut da? Lenke til kommentar
Gjest Slettet-rXRozPkg Skrevet 3. november 2006 Rapporter Del Skrevet 3. november 2006 (endret) php_value memory_limit 16M Men: det er ikke sikkert dette har noen effekt, siden de som drifter serveren kan skru av muligheten for å overstyre parameterene. Endret 3. november 2006 av Slettet-rXRozPkg Lenke til kommentar
NH Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 Da web10.nu er en billighost med _mange_ brukere per server, tviler jeg sterkt på at de vil gå med på dette da serverene deres er overbelastede nok fra før av. Om du i det hele tatt klarer å overstyre dette vil du høyst sansynlig fort merke at webhotellet ditt er borte og avtalen oppsagt da det er i mot retningslinjene demmes. Annbefaler at du leser disse. Selv om trafikken er ubegrenset er det kun snakk om innenfor rimelighetens grenser, og de er ikke glad i overbelastning av serverne, har selv vært i kontakt med deres kundeservice anngående dette da jeg selv har et galleri på deres servere... Vil nok annbefale som nevnt tidligere at du legger inn en limit i scriptet ditt og manuelt resizer bilder til rundt 1024px... Lenke til kommentar
allyse Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 Da web10.nu er en billighost med _mange_ brukere per server, tviler jeg sterkt på at de vil gå med på dette da serverene deres er overbelastede nok fra før av. Om du i det hele tatt klarer å overstyre dette vil du høyst sansynlig fort merke at webhotellet ditt er borte og avtalen oppsagt da det er i mot retningslinjene demmes. Annbefaler at du leser disse. Selv om trafikken er ubegrenset er det kun snakk om innenfor rimelighetens grenser, og de er ikke glad i overbelastning av serverne, har selv vært i kontakt med deres kundeservice anngående dette da jeg selv har et galleri på deres servere... Vil nok annbefale som nevnt tidligere at du legger inn en limit i scriptet ditt og manuelt resizer bilder til rundt 1024px... 7220012[/snapback] Jeg er i og for seg enig i det, men når du betaler for et produkt må sunn fornuft fra begge parter være innad her. I og for seg hvis de annonserer med ubegrenset trafikk kan de ikke trekke seg fra det med mindre de vil si opp avtalen. Tenker meg de har en klausul i kontrakten på det, og det vil etter mitt syn være et brudd på markedsføringsloven. Ting som ini_set og endring i htaccess er noe hosten selv kan skru av, og mange gjør det. Jeg er enig en som bruker skal bruke sunn fornuft, men å ta en 40mB til en peakperiode (til f.eks cache) syntes jeg er helt greit. Det er hosten sitt ansvar at funksjoner som blir levert i prisen blir levert. Men det å konstant bruke en 2-300mB er noe som sier seg selv er urimelig. Lenke til kommentar
NH Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 (endret) Bruk av script/programmer er tillatt så lenge bruken ikke medfører et urimelig stort ressursforbruk på maskinene, og at scriptene / programmene på ingen måte benyttes til å tilegne seg tilgang til andre filer eller informasjoner på maskinene enn kundens egne. Kunden bør vise hensyn til at alle systemressurser deles med øvrige kunder. Tok kanskje litt hart i med stengingen, men de er nok ikke for fan av det. det avhenger jo hvor ofte cachen brukes, og hvor aktivt bruk opplastningen er... Endret 5. november 2006 av NH Lenke til kommentar
allyse Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 Tok kanskje litt hart i med stengingen, men de er nok ikke for fan av det. det avhenger jo hvor ofte cachen brukes, og hvor aktivt bruk opplastningen er... 7222025[/snapback] Alt kommer jo ann på hvor bra scriptet er skrevet. Trenger ikke recache ting som allerede er cachet f.eks. Lenke til kommentar
Jonhoo Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 Men det å konstant bruke en 2-300mB er noe som sier seg selv er urimelig. Ehm, host host, bare for aa vaere pirkete... m = micro / meter M = Mega mB = 1x10^-6 Byte som er nermest ingenting... Ontopic: Trenger du aa bruke saapass mye minne, saa vil jeg foreslaa aa bytte til dedicated host PHP burde forsaavidt ta noe av skylden de ogsaa, maa da vaere mulig med en mindre minnekrevende maate aa gjoere dette paa... Lenke til kommentar
Ernie Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 PHP burde forsaavidt ta noe av skylden de ogsaa, maa da vaere mulig med en mindre minnekrevende maate aa gjoere dette paa... 7222372[/snapback] Tror ikke du får det så veldig mye mer effektivt. Det er liksom ikke så enkelt å endre "fysisk" størrelse på bildet når det er komprimert, ergo må det dekomprimeres og vi får et problem med minne. Tror heller vi sier at PHP (eller scripting på web generelt) egentlig ikke egnet for å endre størrelse på bilder Lenke til kommentar
9001 Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 Post scriptet ditt. Bildet ditt fungerer fint her med 8MB memory_limit. Lenke til kommentar
Jonhoo Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 Tror heller vi sier at PHP (eller scripting på web generelt) egentlig ikke egnet for å endre størrelse på bilder 7222719[/snapback] Mmm, sant Men maa da vaere mulig aa lage en eller annen form for C basert implementasjon som kan gjoere det litt fortere? Nei, huff, kanskje jeg bare surrer... ^^ Lenke til kommentar
Ernie Skrevet 5. november 2006 Rapporter Del Skrevet 5. november 2006 Tror heller vi sier at PHP (eller scripting på web generelt) egentlig ikke egnet for å endre størrelse på bilder 7222719[/snapback] Mmm, sant Men maa da vaere mulig aa lage en eller annen form for C basert implementasjon som kan gjoere det litt fortere? Nei, huff, kanskje jeg bare surrer... ^^ 7224059[/snapback] Det ER skrevet i C Lenke til kommentar
Jonhoo Skrevet 6. november 2006 Rapporter Del Skrevet 6. november 2006 Hmm.. Ja, det var det jeg tenkte meg ^^ Men da maa det jo vaere en raskere maate aa gjoere dette paa siden C i utgangspunktet ikke er nettbasert... Lenke til kommentar
Peter Skrevet 6. november 2006 Rapporter Del Skrevet 6. november 2006 Nå er du langt ute og sykler, neste du sier nå er vel at VB ville være bedre... C er ¤%& raskt enten det er på nett eller i en minnekontroll. PHP egner seg ikke til bildebehandling blandt annet fordi det har rimelig lite minne til rådighet på de fleste servere mens bildebehandling ofte krever veldig mye minne. Lenke til kommentar
Ernie Skrevet 6. november 2006 Rapporter Del Skrevet 6. november 2006 (endret) Hmm.. Ja, det var det jeg tenkte meg ^^Men da maa det jo vaere en raskere maate aa gjoere dette paa siden C i utgangspunktet ikke er nettbasert... 7226649[/snapback] Nå er du veldig på bærtur her. C banker PHP rått på web når det kommer til ytelse osv. Eneste grunnen til at det ikke brukes så mye lengre er at det blir mye kode og debuging er et mareritt uten like. C er like lite/mye nettbasert som PHP eller et hvilket som helst annet språk. PHP er ikke noe annet enn noen hendige funksjoner samlet sammen med en masse herk som dynamisk allokering og "magiske" variabler, og slikt gjør det ikke akkurat mer nettbasert. PS: Hvis du tror det er knotete å komme ut på web med C så kan jeg opplyse om at det ikke er mer enn et par linjer. Med FastCGI er det vel en inkludering og en while-loop. Endret 6. november 2006 av Ernie Lenke til kommentar
9001 Skrevet 6. november 2006 Rapporter Del Skrevet 6. november 2006 Hrm, hadde visst kompilert uten memory limit, så stryk min forrige uttalese. Greide å komme opp i 114MB (i følge htop) når jeg resiza http://dump.xerc.biz/hirespicture.jpg Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå