Andy- On the receive side *if you have windows scaling enabled* you supposedly *can* enhance the receive window by setting these registry keys HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\TCPWindowSize registry values can be set to a maximum of 65,535 bytes (without window scaling) or 1,073,741,823 (with window scaling). Microsoft does admit to 5GBPS hard limit for receive
On the send side you can increase thoughput by enabling CTCP (Compound TCP) netsh interface tcp set global congestionprovider=ctcp Loss negotiation can be mitigated by enabling Enhanced Control Notification algoithm via netsh interface tcp set global ecncapability=enabled http://technet.microsoft.com/library/bb878127 I remember QOS agents installed on both send and receive sides helped monitor and enhance Throughput Do you have QOS agents you can enable to track and reconfig send and receive parameters? Thanks for the hard work collecting these stats..this will help me determine which connector to use going forward Martin Gainty ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Thu, 10 May 2012 17:36:02 -0500 > From: aw...@ptc.com > To: users@tomcat.apache.org > Subject: Re: Slow downloads through mod_jk on Windows XP > > So I cannot reproduce the slow down to 4-5MB/s on the same VM I was able > to reproduce it on once I copied the VM to an adequate vmware server. > But I do see some neat numbers in case people care. > > I ran with ab -5 directly against apache, against a url mapped to ajp as > well as direct to the http connectors. > The numbers were consistent between tomcat 5.0, 5.5, 6.0 and 7.0 so I'm > only going to post one set of numbers for tomcat. > > This is against a windows XP SP3 with no sendbuffersize, tcpbuffersize > or scaling window tuning: > Direct to apache http: > Transfer rate: 21925.90 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 1 0.3 1 1 > Processing: 19593 20077 474.0 20045 20855 > Waiting: 1 2 0.6 2 3 > Total: 19593 20078 474.1 20046 20856 > > Through AJP: > Transfer rate: 36732.95 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 1 0.2 1 1 > Processing: 10662 11984 879.6 12227 12975 > Waiting: 4 5 0.5 5 5 > Total: 10663 11984 879.7 12227 12976 > > Direct to tomcat http: > Transfer rate: 30968.31 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 1 1.6 0 4 > Processing: 11326 14214 2655.1 15565 16952 > Waiting: 3 5 1.6 5 7 > Total: 11326 14215 2654.3 15565 16952 > > > Note how much better the both the tomcat results are than direct > apache. Most interestingly, note how much better AJP is than direct > tomcat HTTP connector. That was quite unexpected. > > Here are the results from a Windows 2008 system on the same vm host: > Direct to apache http: > Transfer rate: 57968.69 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 1 0.1 1 1 > Processing: 7453 7594 181.8 7575 7890 > Waiting: 2 12 18.5 6 45 > Total: 7453 7594 181.8 7576 7890 > > Through AJP: > Transfer rate: 31532.82 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 1 0.2 1 1 > Processing: 10723 13960 2813.3 15795 16409 > Waiting: 3 5 3.1 4 10 > Total: 10724 13961 2813.4 15795 16410 > > Direct to Tomcat http: > Transfer rate: 37742.45 [Kbytes/sec] received > > Connection Times (ms) > min mean[+/-sd] median max > Connect: 0 0 0.1 0 1 > Processing: 10974 11664 452.1 11812 12192 > Waiting: 2 14 25.2 4 59 > Total: 10974 11664 452.2 11813 12192 > > Tomcat http averaged better times, BUT ajp was able to perform faster at > times. Direct HTTP to apache is way faster though but I think that's to > be expected. > > So realistically, I think the 2008 numbers make sense to me and the XP > numbers show that XPs tcp stack is a piece of crap (which I think alot > of people already know). > > I'm not sure what to make of the customer reports of the slow downs but > at this point, I'm going to have to ask them to use something like > ab.exe to do the downloads instead of Internet Explorer (most of them > use IE to do it). Maybe there's some stupidity with IE. > > Anyways, I'm closing the book on this (with a bookmark just in case) but > wanted to provide the numbers in case people were curious what I got. > > Thanks, > Andy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
