21. november 2005 - 21:28Der er
13 kommentarer og 2 løsninger
Thumpnails og performance
Jeg har et billedgalleri der i øjeblikket virker ved at når man uploader et nyt galleri bliver der lavet et lille thumpnail-billede som gemmes på serveren, der så senere kan vises på siden. Men dette tager jo en smule plads og ikke mindst en masse filer, så jeg begyndte at overveje en smartere løsning... Jeg har derfor lavet det følgende script der "on the fly" kan generere et thumpnail-billede vha. komponenten ASPImage:
if not StrImgPath = "" then StrImgPath = Server.MapPath("/Galleri/" & StrImgPath) Set ASPImage = Server.CreateObject("AspImage.Image") if ASPImage.LoadImage(StrImgPath) then NewWidth = (MaxHeight / ASPImage.MaxY) * ASPImage.MaxX if NewWidth > MaxWidth then ASPImage.ResizeR MaxWidth, (MaxWidth / ASPImage.MaxX)*ASPImage.MaxY else ASPImage.ResizeR NewWidth, MaxHeight end if StrImgType = LCase(Right(StrImgPath,Len(StrImgPath)-inStrRev(StrImgPath,"."))) if StrImgType = "jpg" or StrImgType = "jpeg" then Response.ContentType = "image/JPEG" elseif StrImgType = "gif" then Response.ContentType = "image/GIF" elseif StrImgType = "png" then Response.ContentType = "image/PNG" end if Response.BinaryWrite ASPImage.Image else Response.Write "Kunne ikke loade!" end if Set ASPImage = Nothing end if %>
Man kunne så simpelthen bruge dette script til at lave thumpnails til alle billederne når de skal vises på siden. Mit spørgsmål er så om dette kan betale sig rent server-performance-mæssigt... Vil det være for stor en opgave for serveren at generere billederne "on the fly"? Kan det måske gøres bedre i ASP.NET? Eller skal jeg bare blive ved med at bruge det gamle system med egentlige billeder gemt på serveren?
Umiddelbart vil jeg anbefale at du bibeholder dit "caching-system", hvor du gemmer en thumbnail som en fysisk fil på disken. Det er alt andet lige hurtigere for serveren at slå op på disken og sende en fil til klienten, end at skulle fyre op for en komponent som skal læse, processere og sende filen til klienten.
Du vil muligvis ikke kunne mærke det hvis der ikke er så mange brugere på (men jeg tror det nu alligevel), men serveren kan sagtens bruge sine resurser bedre end at generere det samme thumbnailbillede hver evig eneste gang en bruger viser den side hvorpå det bliver vist...
Om det giver mange filer eller ej, kan vel være ligemeget, du har vel en eller anden form for navngivningsstandard eller anden metode til at lade systemet finde billedet når behovet opstår, så det burde ikke være et problem.
der er ingen tvivl om at det mest optimale er at lave billeder ved upload i stedet for on-the-fly - til gengæld kan der være store fordele ved at lave dem on-the-fly; den primære er nok at man ved ikke at gøre det let kan have låst sig selv fast ved eventuelle design-ændringer - vil du engang ændre designet skal enten alle billeder laves om eller også må man benytte de størrelse man nu engang har sat i gammel tid og sådan et problem vil du jo aldrig komme ud i ved at lave dem on-the-fly.
Jeg vil derfor ikke mene det er performance der skal bestemme hvad man skal - men derimod mulige fremtidsplaner hvad angår billedstørrelser.
Umiddelbart synes jeg det ville være en smule forfejlet at vælge dynamisk genererede billeder på en så forholdsvis lille besparelse af arbejdsindsats i det tilfælde at du rent faktisk ønsker at redisigne dit site uden at det indebærer arbejdsopgaver der formegentlig i størrelsesorden får en reskalering af billeder til at ligne en kaffepause i en lang uge med overarbejde... det er vel i bund og grund et spørgsmål om at automatisere processen med at skanne en eller flere mapper med billeder og så skalere dem efter de nye designbehov - det har jeg svært ved at se, hvorfor man skal spilde, potientielt set, oceaner af serverresurser for at undgå.
dine gemte billeder er gemt med en bredde på 100 og en dertil passende højde - i dit redesign skal dine billeder pludselig være 150 i bredden... så er kvaliteten altså ikke vanvittig god ligepludselig!
... selvfølgelig kan man så gemme original-billedet også men det kræver alt samme plads. Et godt eksempel er fx hotpeople - om det gør det nu kan jeg ikke sige med sikkerhed men jeg ved at de tidligere 100% har kørt med billeder genereret on-the-fly og mit gæt er at de gør det stadigvæk og det er jo ikke fordi de giver en vanvittig ringe loadetid eller noget.
Hvis du skal generere billederne on the fly, skal originalerne ligger der under alle omstændigheder og alt andet lige vil de billeder man genererer være af en væsentlig ringere kvalitet og dermed fylde (væsentlig) mindre, så det overhead der er ved at have billederne liggende i skalerede udgaver betyder formegentlig så lidt hvad plads angår så det ikke er et stort problem (om ikke andet så koster harddiskplads jo ikke en bondgård nu om dage). Så det argument overbeviser mig ikke... :)
For det andet så kan vi vel godt blive enige om at serveren skal arbejde _væsentlig_ hårdere for at holde en klient forsynet med on-the-fly-skalerede billeder end hvis de er cachede. Det betyder at resurser bliver taget andre steder fra, hvilket jo ikke er særlig solidarisk, hvis man ligger på en delt server. Hvis man ligger på en dedikeret server, ja, så stikker min potentielt set en kæp i hjulet på sig selv, ved at bruge flere processorresurser end nødvendigt. Personligt arbejder jeg ud fra den tommelfingerregel at man skal lave så lidt på serveren som muligt, for at kunne servicere så mange som muligt... skalerbarhedens grundregel.
originalen - dog måske til en eller anden maxstørrelse - skal selvfølgelig ligge der men skal der udover originalen måske ligge 2-3 eksemplarer fylder det pludselig meget ekstra. Og jeg er på ingen måde enig med dig i at de billeder man genererer vil have en "væsentlig ringere kvalitet" - billeder vil blive meget meget tæt på lige så god som var de resized i fx photoshop (i hvert fald hvis programmeringen er lavet rigtigt). Pladsen er ikke et problem på egen server men der er trods alt stadig begrænsede mængder på de fleste webhoteller.
Vi kan sagtens blive enige om at serveren skal arbejde meget hårdere med billeder lavet on-the-fly - og som du siger og som jeg også tidligere skrev er det meget en vurdering af behov, muligheder etc - og en af de ting man netop burde vurdere det op imod er (som du så flot kalder det) solidaritet.
Når jeg laver noget bliver der også som udgangspunkt lavet det sæt billeder som jeg nu engang skal bruge i min opgave - det gør af flere grunde; bla fordi siderne ikke vil ændre sig mange år frem, fordi det skal være let og simpelt etc. Men sad jeg og skulle lave fx hotpeople om igen - altså en opgave hvor der er så stor fiksering på billederne - ville jeg med meget stor sandsynlighed vælge at lave dem on-the-fly simpelthen fordi jeg fra en dag til en anden kunne vælge at sige "hmm - i dag vil jeg lave lidt fis og ballade, jeg vil lægge en nissehue på alle billeder" eller "hov - jeg har lyst til at brugerne skal kunne se billederne i større format nu"...
så ja - serveren skal arbejde hårdere solidaritet eller ej ved billeder on-the-fly... hvad man skal gøre i den enkelte situation vil jeg ikke mene skal styres af solidaritet eller harddisk-plads men udelukkende på baggrund af opgavens type :)
Vi kan da kun være enige om at det der skal gøres det skal gøres, dvs. hvis behovet er at man skal være super dynamisk mht. justeringen af billederne, så skal man naturligvis ikke sidde og generere nye sæt billeder hver time, men hvis behovet for at gøre det er til stede, så er der måske alligevel god grund til at tænke sig ekstra godt om, ifht. hvormange serverresurser man fyrer af (så har man nok mange besøgende og dermed ekstra god brug for de enkelte processorcycles). Jeg er stadig af den overbevisning at man bør cache sig ud af så meget som muligt og spare på de resurser som er en flaskehals i systemet.
Når jeg skriver dårligere kvalitet, mener jeg ikke nødvendigvis at billedet bliver væsentlig dårligere at se på, men blot at datamængden i billederne bliver reduceret væsentligt (jeg undskylder det dårlige valg af ord).
Hvorom alt er, så er vi grundliggende enige om at det endelige valg er en vurdering i det enkelte tilfælde (af HD-plads kontra CPU-kraft tilsat en skefuld behov og en knivspids solidaritet), men at faktum er, at der bruges mange flere serverresurser til at generere billeder on the fly. Så kan killer_r jo tage det med i sine overvejelser, når der skal vælges strategi for galleriet... :)
P.S. Solidaritet skal man ikke kimse ad, det er grundlaget for gode relationer... ;-)
Yepper... Vi lukker... takker for den fine diskussion... Jeg tror nok det ender med at at jeg ikke laver dem on-the-fly... Det kan ikke svare sig med hvad man sparer i harddisk-plads i forhold til solidaritet osv... :-)
P.S: i øvrigt er det jo ikke kun andre man er solidarisk med - det er jo også ens eget site, dvs. de andre sider som jo også skal bruge serverens kræfter på at blive generere. Jeg mener derfor stadig det godt kan betale sig at tænke i serverresurser uanset hvad. :)
klart - men uanset hvad vil du lige meget hvordan du end vender og drejer det kunne performe på flere forskellige niveauer... alt efter mål, fremtidsvisioner etc etc :)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
