On 9/11/08, Matus UHLAR - fantomas <uhlar@xxxxxxxxxxx> wrote: > > On 9/10/08, Matus UHLAR - fantomas <uhlar@xxxxxxxxxxx> wrote: > > > On 09.09.08 21:23, solprovider@xxxxxxxxxx wrote: > > > > 5000 reqs/sec @ 20 KB/req = 100 MB/sec = 1Gbps. One gigabit network1 > > > it's even 800, not 1000 Mbits per second... > > > Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/ > > Rough conversion (from the old days) was: > > 1 byte of data > > = 8 bits on disk > > = 10 bits of network traffic > this was also correct in modem times. I don't think that network > (http/tcp/ip) headers cause that big overhead now :) Yes, it depends on size > of average requests... However we should count that into average size of > request... Network overhead is difficult to estimate. IPv4 adds 32-36 bytes per packet; IPv6 adds 60-64 bytes per packet. Packet size has a large effect -- smaller packets require more packets with more protocol overhead ; larger packets waste more space in the final packet. Then add non-data packets e.g. ACKs. My 25% overhead (2 bits overhead per 8 bits data) has produced reasonable estimates. > > = 13 bits of encrypted (SSL) network traffic > Interesting, I guess that mostly applies to SSL handshake overhead. I don't > have the numbers but I guess encrypted text should not be much bigger than > non-encrypted. I once read that encryption added 20-30%. Modern streaming encryption seems more efficient, but adds handshake overhead per transmission. Again, my 30% overhead has produced reasonable working estimates. > Does somebody have the data? > Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/ Ditto. I would like better estimates, or at least more details to support my current calculations. solprovider --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|