[fmistander]

Har lite funderingar kring bildstorlekens betydelse vid nedladdning.

Om jag sparar en liten ikon på 100 byte så komprimerad det går i photoshop jämfört med en lite mindre komprimerad på 300 byte. Bör det inte ta lika lång tid iaf för mottagaren att ta emot filen då bilden packas i ett paket om ca 500 bytes (Om jag minns rätt om TCP-paketen)

Vart går i så fall gränsen för bilderna att få plats i ett paket?

Känns ju lite overkill att komprimera ner dem i onödan för mycket om det ändå blir lika stort paket i slutändan...

Tackar för hjälp

[zoran]

Originally posted by fmistander@Mar 14 2006, 09:33
Har lite funderingar kring bildstorlekens betydelse vid nedladdning.

Om jag sparar en liten ikon på 100 byte så komprimerad det går i photoshop jämfört med en lite mindre komprimerad på 300 byte. Bör det inte ta lika lång tid iaf för mottagaren att ta emot filen då bilden packas i ett paket om ca 500 bytes (Om jag minns rätt om TCP-paketen)

Vart går i så fall gränsen för bilderna att få plats i ett paket?

Känns ju lite overkill att komprimera ner dem i onödan för mycket om det ändå blir lika stort paket i slutändan...

Tackar för hjälp

Klart, du kan ju optimera sånt. Du kan ha ett skript som tittar på RTT och bandbredd för att komprimera bilden. Du kan också räkna in väderomslag och temperaturer i havet ifall besökaren kommer från USA.

Eller så kan du bara tycka (som jag) att det är hårklyveri och strunta i att lägga ner massa jobb på det.

[eg0master]

Bilden kommer kopieras från en inkommande buffer till en mottagande buffer i browsern (minst) en gång och en kopiering av 300 bytes tar något längre tid än en kopiering av 100 byte.

Och två TCP paket kommer ta olika lång tid att sända eftersom datat sänds i en ström. paketen sänds inte momentant.

Så inte ens i teorin håller ditt resonemang eftersom det alltid kommer finnas vinnster med den mindre bilden. Dessutom kan det vara så att flera bilder kommer i samma paket pga TCP buffring och som konsekvens av Keep-Alive i HTTP (vilket är default för HTTP/1.1).

Dock finns det en grundregel vad gäller optimering (av programvara); Optimera bara det som måste optimeras. Om något inte måste optimeras tjänar man oftast på att låta bli.

Ang. storleken på paketen så är en MTU på 1500 väl det vanligaste för IP paket vilket väl brukar betyda att datadelen i TCP paketet blir 1460 (20 bytes för IP-paketet och 20 bytes för TCP headern (givet att inga options används i resp protokoll)).

[fmistander]

Tack eg0master för svar!

Var lite osäker på det där med om den skickade seriellt (Ström) eller ej. Men då betyder det alltså att storleken spelar roll. Annars hade man ju kunna göra alla såna småbilder till 1460 bytes utan att det skulle ta olika lång tid.

zoran: På med badbyxorna, här behövs det simmas för att optimera in småbilderna

[kullervo]

Det behövs inte handskakning för varje paket som skickas. När du skapar en TCP-anslutning talar mottagaren om hur stor mottagarbuffert han reserverat åt dig (window size). Efter det kan sändaren skicka datat fritt tills han fyllt mottagarens buffert utan massa SYN-paket hit och dit. Med andra ord: du oroar dig i onödan.

Edit: Är inte helt hundra på hur window size bestämms.

[eg0master]

Originally posted by kullervo@Mar 14 2006, 17:04
[...]
Edit: Är inte helt hundra på hur window size bestämms.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\TcpWindowSize
om jag inte missminner mig. :P

Och att inte alla paket behöver ACKas (handskakning med SYN görs väl ändå bara då sessionen sätts upp) påverkar inte hastigheten för mottagna paket hos mottagaren (där påverkar fortfarande bara storleken, väder, vind mm), däremot hastigheten som data kan skickas med (och potentiella omsändningar).

Dock har kullervo en väldigt legitim point: Du ororar dig i onödan. Optimera bara det som måste optimeras.

Att optimera för att man tror att det behövs är inget vinnande koncept.

[guran]

Det som har betydelse i detta fall är om du har en bild som "spiller över" några byte i ett nytt paket. Om du då har många bilder på sidan som spiller över på samma sätt, så kan det kanske löna sig att att se till att ta bort detta "överspill" och således se till att ett mindre antal paket måste skickas.

Fast när denna teknik ska löna sig tror jag du i första hand ska titta på din startsida, att den laddas så fort som möjligt.

Det finns även folk som betalar för antal nedladade byte och då kan det löna sig att inte skicka iväg onödigt data till. Att göra som t.ex. hitta.se gör, förnerladda kartbilder så att nästa kartbild ska visas fortare är ett okynne med tanke på att besökaren kan få betala för den trafiken, som sedan besökaren inte utnyttjar.

[nomicon]

Storleken har ingen större betydelse, utan tekniken.

Iallafall om man får tro på vad många kvinnor säger

-Martin

[Robert]

En tumregel kan vara att din optimering ska förbättra upplevelsen för användaren (hastighet), inte försämra den (fula bilder). Går det att komprimera utan märkbar förlust samt beskära lite marginaler etc i bilden, så kör på. Många bäckar små...