In .NET I have already tried the configuration below successfully:
<system.net>
<connectionManagement>
<add address="*" maxconnection="100"/>
</connectionManagement>
</system.net>
Using 100 concurrent HttpWebRequest they answered almost simultaneously (less than a second).
I wonder why some people wrote in some forums that Windows XP and Windows Server 2008 limits this number to 15 or 20. They are right?
The client versions of Windows are restricted in the number of half-open connections.
The 10 limit for XP is well known, Vista has other limits depending on the version (e.g. Home Basic has a limit of 2, Ultimate has 25).
You can Google "Patch for Event ID 4226" to alleviate these limits. Post Vista SP2 the behavior is configurable through a registry key.
Windows Server can handle several tens of thousands of concurrent inbound connections given enough resources.
Depending on your server version, you have to change some default parameters to allow these many connections to see this guide.
The author reports having seen 50.000+ concurrent connections to IIS6 on WS03SP1 x64 with 4GB RAM.
It could be because people are confusing the number of inbound SMB connections with the number of TCP/IP connections. SMB is used for file sharing and various other things and is limited to 10 connections in Windows Client OSes.
http://support.microsoft.com/kb/328459
There are connection limitations on uncompleted (new) connections. IIRC, this was rolled into a update a few years ago as an experiment to curtail the spread of certain types of malware. You can safely remove this limit:
http://technet.microsoft.com/en-us/magazine/2007.12.network.aspx
Related
My company is currently using TortoiseSVN 1.6.16 32-bit on Windows XP to connect via HTTPS to a VisualSVN-Server 2.1.19 running on a Windows Server 2003 residing in the same network (no proxy). We use a self-signed certificate and Kerberos authentication using windows credentials (I suppose this is a VisualSVN-specific feature). In this setup, everything works dandy.
When my company decided to move on to Windows 7, we tried TortoiseSVN 1.7.6 64-bit on Windows 7 64-bit which resulted in the following problem:
Any operation involving the server (repo-browser, checkout, update, checkin, ...) is unbearably slow e.g.
opening the repo-browser (10 projects): 15 min
update on a fresh checkout of 50 files: 1 min
checkin of a single empty file: 30 sec
Tortoise shows alternatively normal transmission speeds and 0 byte/s. Many small files seem to be slower than a few big ones.
The slow connection results in various failures when using neon as http-lib (serf is still slow, but operation finishes successfully without errors)
EasySVN, SmartSVN and the SVN command line client that comes with TortoiseSVN show the same behaviour. Same with TortoiseSVN 1.6.16 64-bit.
Changing the server protocol to HTTP (no SSL) does not improve the situation
On the other hand
TortoiseSVN 1.7.6 32-bit on Windows XP works fine with our server
Access via browser/WebDAV works well even under Windows 7
Server side logs do not show errors or even warnings
I found several posts which also complained about slow behaviour on Windows 7, but they didn't fit my bill because they were local operations or were restricted to TortoiseSVN.
As there is no indication that there is a general problem with Subversion on Windows 7, I suspect that it could be our OS' networking parameters or protocol versions. Are there any parameters which are known to influence Subversion's performance?
I have to admit I am not familiar with how exactly Subversion (or rather neon/serf) relies on the OS and on which parts. Any information on that would be greatly appreciated.
Are there any parameters in the subversion 'servers' file which I should test? How would you consider my chances that Wireshark'ing the connection will help me?
Similar experiences, opinions, hints, help and straws are welcome.
Wireshark shows sporadic gaps of ca. 5 sec in the TCP stream apparently caused by VisualSVN Server.
https: the server acknowledges the client hello then waits for 5 secs before sending its server hello
https: the server acknowledges the client key and than takes 5 secs before supplying its encrypted handshake data
https: even outside the handshake, server sometimes sends an ACK (on TCP level) and then waits for 5 sec before sending something back to the client (the data is encrypted so it's hard to tell whether the break occurs at some point of interest)
http: at both server side transmissions during the NTLM authentication
http: before server sending a FIN flag
A typical fail with Windows 7 against an older server is IPv6 networking.
If your machine does not have an SVN server listening on an IPv6 address Windows 7 might still try to do a TCP6 connect first (you can see it in Process Explorer if you look at the open sockets of the TortoiseSVN process while trying an operation), this has a timeout of a few seconds and then retries with IPv4.
Simple solutions are either upgrade your server to an IPv6 capable one or disable IPv6 for the Windows 7 clients.
Another thing you could verify (the answer above didn't work for us) is the Internet Explorer settings especially if you have IE9. We found that by disabling the option Automatically detect settings in the Internet Options -> Connection tab -> LAN settings, SVN started working normally again.
The issue was never properly cleared up. Most probably, the company internal network path between the client and the server was somehow at fault. The matter became obsolete when we moved the SVN server to another machine. The very same setup of server and clients works fine now, even with Windows 7.
I had the same symptom of a very slow repository browse, slow updates, slow everything.
My SVN server has two Ethernet cards, so it has two Ethernet IP addresses. The SVN server was only listening on one of the IP addresses. So a name resolution via WINS or NetBIOS could resolve to the 'wrong' IP address.
TortoiseSVN would retry, eventually the name resolution would find the 'correct' IP address, and things would work.
I have an oracle client which communicates with an Oracle database through a firewall.
I have been asked to limit the number of ports that need to be opened to an absolute minimum.
I think it should be possible to limit the firewall to open port 1521 only, if I also set the USE_SHARED_SOCKET = TRUE setting in the database server's registry.
Without the USE_SHARED_SOCKET setting, it seems that the Oracle SQLNET client is handed alternate server ports to use after the initial request to the listener on 1521.
This is an existing application, and I don't want to create havoc if - by setting this parameter - I break database communication in the application.
What - if any - adverse effects could I expect by using USE_SHARED_SOCKET = TRUE?. Is this a recommended firewall strategy? I've seen forums mentioning being locked to "dedicated server mode", but I don't think I understand if this is relevant.
Apparently Metalink NOTE 124140.1 provides some additional information, but I don't have access to Metalink.
On platforms and architectures that Oracle redirects connections to different ports (to the best of my knowledge, Windows servers in general and Unix servers for shared server connections), it generally does so for reasons of efficiency. If you set USE_SHARED_SOCKET to TRUE, you create the potential that there will be performance problems because the operating system has to deal with a lot of traffic for a lot of different logical connections on the same port.
Whether the potential performance problems actually affect your application, of course, is something that you'd have to test. The more connections you have, the more network traffic you create, the greater the potential for problems. But the vast majority of applications won't see any appreciable performance problems.
Is there a limit to the number of HTTP ports in a machine. I have a windows application that uses .NET Remoting. Each instance of the application, exposes a Remote object on load, through a HTTP Channel with port 0 (so that port can be decided dynamically). In a Multi user environment, will there be a limit to the number of HTTP Ports.
Thanks in Advance!
Yes there will be a limit to the number of ports available which is 65535 minus the number of ports already in use for existing services (for example, SMTP [25], HTTPS [443], SQL Server [1433], etc).
So on a typical Windows server, a finger in the air calculation would be 65535 - 1024 (the well know service ports <= 1024 which are considered out of bounds) - another 10-20 or so possible other application (SQL Server, MySQL, Oracle, etc). This would leave around 64490 post available.
However will you really be running 64000 of instances of your server?
I am doing some maintenance on software and have a problem that I do not understand.
Application was developed using Microsoft Visual C++ 6 and runs on Windows XP. It consists of 21 applications that communicate to each other via UDP sockets. It is a simulation of an embedded avionics system used to debug the system in a PC environment. Each of the applications simulates a node in the embedded system and the embedded networked is simulated over UDP. The system originally ran on multiple PCs but can now runs on a single Quad core machine.
The system is working but the communication is annoyingly slow. However opening up Internet Explorer and visiting a web site or two set something that would cause my applications to suddenly communicate very fast to each other.
So my question is what did Internet Explorer set when visiting a web site so that my application can also set it? None of the original authors of the system is still around and I have very little windows programming experience.
it might not be a windows problem after all
check your API, check your buffer and check for errormessages 'getlasterror()' that doesn't cause INVALID (-1) and stops the program try to use it even if your program runs perfectit might have useful warnings
check ACK or attack speed it's a common issue at transfer large amounts of data over network connections ( <-- 90% it's your problem ), here is a useful topic on that subject ( support.microsoft.com/kb/823764 )
if neither of those solutions work, try checking your driver version against the manfucturer website.
last resort is those useful ideas:
. use this program www.lvllord.de to increase max half/open connections from 8 to 50
. using a server edition windows can boost some internet based programs
. using multi-threading with sockets API can cause some confusing to the API if you're using more than 2 sockets at different threads in multithreaded application, try optimize performance by using async sockets or something like that ( msdn.microsoft.com/en-us/library/ms738551(VS.85).aspx )
So my question is what did Internet Explorer set when visiting a web site so that my application can also set it? None of the original authors of the system is still around and I have very little windows programming experience.
may be ACK check it on wiki .. it means in other ways the attack speed .. if not then it will be the receive window size
both settings are invisible to users .. but can be set via programs such as tuneup utilities or any general network hidden setting adjustors
it might just do the trick ..
If the protocol above UDP implements reliability the speed loss will be due to massive UDP packet loss on localhost. UDP performance on localhost is terrible, your best bet is to wrap the socket API inside a TCP layer.
If it's UDP broadcast or multicast you will have to look at implementing a broker process to multiplex the messages over TCP.
Might be easier to look at existing messaging APIs that work well at the interprocess level such as ZeroMQ.
Try using Wireshark to see what Internet Explorer is doing.
Does anyone know what is the maximum number of concurrent TCP/IP connections on Windows XP SP3? I am trying to load test a machine and would like to know what is the max number of tcp connections that can be opened by an application (in my case, java application) towards that machine.
Note that often you may be limited by the number of outbound connections supported on the client machine rather than by the number of concurrent connections possible. See this Socket Bind Error for how to tune MAX_USER_PORT to enable more outbound connections from the machine running the tests.
I found some very useful information here:
http://smallvoid.com/article/winnt-tcpip-max-limit.html