Re: Foto's gecomprimeerd mailen
On 09/06/2014 06:51 PM, Paul van der Vlis wrote:
op 06-09-14 14:40, Jan-Rens Reitsma schreef:
On 09/05/2014 03:44 PM, Paul van der Vlis wrote:
op 05-09-14 13:01, Jan-Rens Reitsma schreef:
Als ze niet tegen een limiet aanlopen, wat is het probleem dan?
Als de verzender op "verzenden" drukt duurt, het lang zo'n mail te
versturen. En als de ontvanger op de mail klikt, duurt het lang voordat
hij getoond wordt.
Aha! Is DAT het probleem? Ik betwijfel of daar gemakkelijk iets aan te
doen valt. Maar ik verwacht niet dat het versturen van de foto's veel
sneller zal gaan als je de foto's verder comprimeert.
Jawel, dat scheelt enorm.
Het is volgens mij belangrijker eerst te bepalen hoe de tijd die nodig
is om de mail te verzenden schaalt t.o.v. de lengte van het bericht. Is
dat verband kwadratisch (~ L^2) of kubisch (~ L^3) of nog sterker
vertragend?
Het verzenden van 10 berichten met n foto's in de attachment zou (veel)
sneller kunnen gaan dan het verzenden van een enkel bericht met 10 * n
foto's in de attachment. Als jij ervan overtuigd bent dat de tijd die
nodig is om een email te versturen evenredig zou zijn met het kwadraat
van de lengte van een bericht, dan kun je beter 10 berichten met n
foto's na elkaar versturen dan een enkel bericht met 10 * n foto's omdat:
100 * n^2 > 10 * n^2
Voor kubische schaling geldt:
1000 * n^3 > 10 * n^3
Het zou een factor 10 of 100 in snelheid schelen als je de tien losse
berichten met n foto's na elkaar verstuurt. Als je de tien berichten
tegelijk verstuurt scheelt het (in theorie) een factor honderd of
duizend in tijd, zonder dat je de compressie van de foto's hoeft te
verhogen.
Ik vermoed dat het versturen van een aantal berichten met een kleiner
aantal foto's meer snelheidswinst oplevert dan het verder comprimeren
van een groot aantal foto's in een enkel bericht.
Tussen de mail
client (MUA) van je klant en de MUA van de ontvanger zitten minstens
twee MTA's en waarschijnlijk nog een MSA en .... Ik heb er geen flauw
idee van waardoor de grootste vertraging tijdens de verzending
veroorzaakt wordt. Dat zou in sommige gevallen bepaald kunnen worden
door de configuratie van een schakel in de keten.
Het komt simpel doordat het werken met veel data lang duurt.
Volgens mij wordt die vertraging veroorzaakt door de lagere prioritering
van processen die meer tijd in beslag nemen.
Zelf beheer ik al vele jaren mailservers dus ik heb er wel verstand van.
Dat betwist ik nergens. Ik vraag me alleen af of het versturen van een
lang bericht de slimste keuze is. Ik denk dat het slimmer zou kunnen
zijn om dezelfde informatie dmv een reeks korte berichten te versturen.
Ik kan me voorstellen dat het verzenden van veel foto's per email in
sommige gevallen sneller gaat als je ze apart kunt versturen in een
bundel threads. Ik denk niet dat het heel moeilijk is, of veel tijd
kost, om daarvoor een toepassing te schrijven.
De foto's moeten gewoon eerst gecomprimeerd.
Wat bedoel je? Dat de foto's nog verder gecomprimeerd moeten worden dan
nu het geval is? Wil je niet eerst uitzoeken of het verzenden van een
reeks kortere berichten met kleinere aantallen foto's veel meer
snelheidswinst oplevert?
<knip>
Ik werk niet graag met Java toepassingen.
Probably no problem.
<knip>
Waarschijnlijk kan ik beter tijd en energie steken in het vertalen van
.po-files naar het Nederlands. Daar hoef je niet veel voor te tikken.
Nou..., dat lijkt me ook veel tikken.
Dan verplaats ik dat plan naar een lagere positie op mijn
prioriteitenlijstje.
Mvg,
Jan-Rens.
Reply to: