[ASP] responstijd data verzenden met post methode *

[Verwijderd]

Ik werk al een tijdje met ASP en heb een website met pagina's die data van de ene pagina naar de andere met formpjes (post methode) versturen.
Deze forms bevatten vaak een groot aantal hidden fields. Nu wilde ik een schatting gaan maken hoe lang het versturen van een redelijke grote hoeveelheid data gaat duren.
Ik ga uit van de volgende situatie:
- 100 hidden fields, 10 karakters per field
- iemand heeft een trage verbinding (bv, 28k8 modempje, 4/5 kb/s)

Nu wilde ik dus een betrouwbare schatting maken hoe lang het gaat duren voordat die fields zijn verzonden, zodra iemand op de submit button drukt.
Dus feitelijk, wat is de wachttijd tussen het submitten en de aankomst op de volgende pagina?

Kan ik er vanuit gaan dat elk field 10 byte aan data bevat, wat dus ~1 kb (100*10) aan te verzenden data inhoudt elke keer als er op submit wordt gedrukt?
Of zit daar nog 'extra' data bij?
Kan ik er dan ook vanuit gaan dat degene die de data submit (met de geschetste verbinding) dan binnen 1 seconde de data heeft verstuurd?

Dit alles om in te kunnen schatten wat een redelijke hoeveelheid data is om te vesturen wanneer een bezoeker met een trage verbinding mijn site bezoekt.

elke hulp wordt, zoals altijd, gewaardeerd

[The Eagle]

Vanwege de overhead van TCP/IP mag je voor het versturen van data je lijncapaciteit door 10 delen om van het aantal bits / sec, bytes/sec te maken. ALdus met een 28k8 modem: 28000bits/sec = 28kbits / sec = 2,8 kbytes/sec 2800 bytes/sec. Nou zal ie dat niet halen (vanwege compressie e.d), maar ik denk niet dat je veel problemen zult kunnen verwachten. Hou echter wel rekening met het feit dat je ook je pagina zult willen verversen, en dat die aanzienlijk groter zal zijn als de data die je verstuurt met de submit.

[Verwijderd]

Ik begrijp dat het binnenhalen van de pagina zelf meer data zal kosten, maar het versturen van de data met de forms is een extra belasting. Ik wil dit beperken tot maximaal 2~3 seconden extra wachten en begrijp uit jouw verhaal dat dit wel snor zit.
Wat ook nog meetelt is de verwerkingstijd van de ontvangende pagina, het afvangen van de data met request dus. Kost dit evenveel tijd als het versturen?

[Zeezicht]

Kan je die data niet bewaren in sessies? Dan hoef je ze niet meer te versturen en kan de data niet meer veranderd worden onderweg....

[Verwijderd]

nee, want het gaat om twee fysiek gescheiden pagina's (op verschillende servers dus).

[Zeezicht]

Verwerkingstijd ligt aan de snelheid van je server. Heeft verder niks te maken met de verbinding.
Maar je moet wel rekening houden met het terugsturen van de data en de rest van de pagina. Dat kost ook nog tijd.

[Glimi]

Ga eens wat van minder dingen uit en test het eens uit met een packetsniffer hoe groot de TCP/IP pakketten zijn, dan heb je meer zekerheid over je data
Verder weet je niet precies hoe groot een character is. Speciale characters &, ; ed. worden URL encoded wat neerkomt op een transformatie naar 4 characters. Ook weet ik niet of de encoding meespeelt; ASCII is 1 byte voor één character, maar unicode is 2 bytes voor één character.
Bovendien wordt een HTTP request nog voorafgegaan door headers, ook dit kun je zien in een packetsniffer. Ze zien er ongeveer als volgt uit:

code:

POST /path/to/url HTTP1.1
Host: yourhostname
Accept: */*
User Agent: StringOfYourUserAgent
Referer: yourhostname/path/to/referer

hiddenvar1=bla&hiddenvar2=bla&hiddenvar3=bla

Kortom je HTTP request bevat ook wat variabelen (waarvan Accept: bij MSIE vaak huge is)

Echter ga er maar van uit, dat als alleen text gepost wordt, dat dit vergeleken met de data die de client terug krijgt, vaak in het niet valt Echter zeker weten doe je het pas als je aan de gang gaat met een packetsniffer.

Laatste punt: 56k modems doen vaak max 4 kb/s weet ik uit ervaring; dus 28k komt waarsch met moeite boven de 2kb/s uit

[4VAlien]

De grootste winst zit denk ik in het gebruik van compressie op de data van je webserver, ik weet alleen niet hoe dat op IIS zit (denk aan mod_gzip bij Apache) en dan ook nog bij het posten :-/ . Kan zijn dat The_Eagle dit al zei maar hij had het over de compressie op low level netwerk protocol geloof ik.