I am running a Load Test on my .Net web application using Jmeter.
Application Process: Launch - Login - Start Test - Answer Q&A - Home Page - Logout
Till 500 users or sometimes 750, the test is running successfully. But when I increase the load I get an Error:
Non HTTP response code: org.apache.http.conn.HttpHostConnectException/Non HTTP response message:
Connect to www.demoname.com:80 [www.demoname.com\/11.111.111.111] failed: Connection timed out: connect
'11.111.111.111' - is my Server IP address
I have increased the jmeter.batch file Heap memory to HEAP=-Xms1g -Xmx4g -XX:MaxMetaspaceSize=256m
Apache Jmeter version - 5.1.1r1855137
Java Version - 1.8.0_221
Server Configuration: Standard D4 v2 (8 vcpus, 28 GiB memory)
How can I get rid of this error?
HttpHostConnectException is basically an instance of a ConnectException which:
Signals that an error occurred while attempting to connect a socket to a remote address and port. Typically, the connection was refused remotely (e.g., no process is listening on the remote address/port).
So most probably the error is on your server side because JMeter attempts to establish the connection and fails to do this within the bounds of the defined timeout
If you're absolutely sure that your application works normally you can increase connect timeout in HTTP Request Defaults
However a better idea would be getting to the bottom of the error and fixing it on server side, the most possible reasons are in:
your application is overloaded, i.e. lacks essential resources like CPU, RAM, Network, etc. Make sure to set up monitoring of these metrics using i.e. Azure Monitor or JMeter PerfMon Plugin
your application infrastructure is not properly configured, make sure to double check if your backend is properly tuned for high loads including IIS and MSSQL
it might be the case your application code is problematic, i.e. it cannot handle more than X users due to poorly implemented algorithms. Consider using a profiler tool like NProfiler or dotTrace to detect the most expensive functions, largest objects, etc.
I have C# windows service that polls an ADS 9.10 advantage database periodically during the day using Quartz.net. The window's service is still in development and hasn't be put live. On the test box the database is refreshed nightly. Whilst the database is being restore the windows service correctly logs error. Once the restore has finished the windows service continues running correcly for a few attempt but then this error occurs.
Error: Advantage.Data.Provider.AdsException: Error 6097: Bad IP address or port specified in the connection path or in the ADS.INI file. axServerConnect
at Advantage.Data.Provider.AdsInternalConnection.Connect()
at Advantage.Data.Provider.AdsPoolManager.GetConnection(String strConnectionString, AdsInternalConnection& internalConnection, AdsConnectionPool& pool)
at Advantage.Data.Provider.AdsConnection.Open()
The only way to resolve this is to stop and start the service. To me this means something must be caching a bad connection, Which I don't understand as I'm do the C# USING wrapper around the connection and command, thus disposing the connection after it finished. I've tried turning off the connection pooling in the connection string
AdsConnection.FlushConnectionPool(_connectionString)
AdsConnection.FlushConnectionPool()
Please note that I don't use the ADS.ini file, the IP address and port number are in the connection string.
One solution could be use a schedule task rather than the quartz job... but I like quartz so I would like to fix this problem.
The requirement to restart the service to resolve problem is probably due to caching of connection error codes by the ADS clients. I think the only solution to get around the error code caching is to use the RETRY_ADS_CONNECTS configuration in the ads.ini. The ads.ini file can be placed in the same directory as the service.
The 6097 error is returned when the database is down while being refreshed and then cached by the ADS ado client.
I'm trying to implement simple wcf service. I think that my server and client side endpoints points are set correctly.
On debugging I can see that my service returns data properly but when it comes to display on the screen (simple console application is the client of the service) it says
The underlying connection was closed: A connection that was expected
to be kept alive was closed by the server.
class Program
{
static void Main(string[] args)
{
string endPoint = ConfigurationManager.AppSettings["BookServiceActiveEndPoint"];
IBookService proxy = new ChannelFactory<IBookService>(endPoint).CreateChannel();
// this is where breaks
Console.WriteLine(proxy.GetBookDetails("TestBookTitle")); /
Console.ReadLine();
}
}
any ideas where to look for further info?
wcf host is website and solution has multiple startup projects
- webservices.host (website)
- webservices.consoletests
This can be caused by a lot of problems, some I've encountered are:
Problems with serialization/deserialization
Endpoint configuration issues
app pool has terminated (ex, when a stackoverflowexception is thrown)
tons more
so the best solution is enable tracing and look at the trace logs. I won't try to explain something that's already well explained in the web so I'll just give you a few links:
How to turn on WCF tracing?
http://msdn.microsoft.com/en-us/library/ms733025(v=vs.110).aspx
Usually, it is enough to enable tracing on your web server. However, there might be (very rare) cases where you won't find anything wrong in the server trace logs. In this case, you might also want to enable tracing in the client (same procedure, if you have a .NET client).
The TIBCO EMS user's guide (pg 292) says:
The backup server will work indefinitely to either A) become the
primary server or B) reconnect to the primary server. It also says
clients may receive fail-over notification when the switch is successful (see also TIBCO EMS .NET reference pg 220).
I have some questions spinning off of these facts...
What kind of errors occur on the client side while the servers are attempting fail-over/reconnect?
What is the appropriate response from the client?
Get new Connection objects from the ConnectionFactory until one works?
Wait for fail-over notification? (are current Connection instances fixed at this time? or do I need to get a new instance?)
I hope the scenario is clear, any related information or advice would be appreciated too.
I can at least answer #1 above.
If you have enabled Tibems.SetExceptionOnFTSwitch(true); and have set up an exception handler to capture the messages the server sends to the client, you will see the following:
For single-server, non-fault tolerant connection failures:
"Connection has been terminated".
For fault-tolerant connection failures:
"Connection has performed fault-tolerant switch to "
If you attempt to publish while the connection is down, a TIBCO.EMS.IllegalStateException is thrown with the "Producer is closed" message.
for #2 above, I think the answer is to allow the EMS library to handle as much as possible. Once we got the EMS reconnect functionality to work, it gracefully tried to reconnect until the server became available again and once it reconnected, it was like there was never a problem. The only gotcha is probably if you try to publish a message before the ems connection is back. This is where the exception handler comes in, Once notified that you are in failover mode, you can adjust exception handling on the publisher side to suppress the error until the connection is back. The thing I don't know is how do you tell when you've exhausted all reconnect attempts.
Anyway, Seems like our two worlds are closely related when it comes to EMS - hope our findings (based on your comments on my questions) help you.
We use TEMS (Tibco EMS - a Tibco Product for WCF) So it becomes a custom binding. We tried to break it by doing things like bounce the server to force switch overs and it works really well. make sure you are using version 1.2 not 1.1 because you cannot do anything other then client acknowledgement.
Every now and then in a high volume .NET application, you might see this exception when you try to execute a query:
System.Data.SqlClient.SqlException: A transport-level error has
occurred when sending the request to the server.
According to my research, this is something that "just happens" and not much can be done to prevent it. It does not happen as a result of a bad query, and generally cannot be duplicated. It just crops up maybe once every few days in a busy OLTP system when the TCP connection to the database goes bad for some reason.
I am forced to detect this error by parsing the exception message, and then retrying the entire operation from scratch, to include using a new connection. None of that is pretty.
Anybody have any alternate solutions?
I posted an answer on another question on another topic that might have some use here. That answer involved SMB connections, not SQL. However it was identical in that it involved a low-level transport error.
What we found was that in a heavy load situation, it was fairly easy for the remote server to time out connections at the TCP layer simply because the server was busy. Part of the reason was the defaults for how many times TCP will retransmit data on Windows weren't appropriate for our situation.
Take a look at the registry settings for tuning TCP/IP on Windows. In particular you want to look at TcpMaxDataRetransmissions and maybe TcpMaxConnectRetransmissions. These default to 5 and 2 respectively, try upping them a little bit on the client system and duplicate the load situation.
Don't go crazy! TCP doubles the timeout with each successive retransmission, so the timeout behavior for bad connections can go exponential on you if you increase these too much. As I recall upping TcpMaxDataRetransmissions to 6 or 7 solved our problem in the vast majority of cases.
This blog post by Michael Aspengren explains the error message "A transport-level error has occurred when sending the request to the server."
To answer your original question:
A more elegant way to detect this particular error, without parsing the error message, is to inspect the Number property of the SqlException.
(This actually returns the error number from the first SqlError in the Errors collection, but in your case the transport error should be the only one in the collection.)
I had the same problem albeit it was with service requests to a SQL DB.
This is what I had in my service error log:
System.Data.SqlClient.SqlException: A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
I have a C# test suite that tests a service. The service and DB were both on external servers so I thought that might be the issue. So I deployed the service and DB locally to no avail. The issue continued. The test suite isn't even a hard pressing performance test at all, so I had no idea what was happening. The same test was failing each time, but when I disabled that test, another one would fail continuously.
I tried other methods suggested on the Internet that didn't work either:
Increase the registry values of TcpMaxDataRetransmissions and TcpMaxConnectRetransmissions.
Disable the "Shared Memory" option within SQL Server Configuration Manager under "Client Protocols" and sort TCP/IP to 1st in the list.
This might occur when you are testing scalability with a large number of client connection attempts. To resolve this issue, use the regedit.exe utility to add a new DWORD value named SynAttackProtect to the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ with value data of 00000000.
My last resort was to use the old age saying "Try and try again". So I have nested try-catch statements to ensure that if the TCP/IP connection is lost in the lower communications protocol that it does't just give up there but tries again. This is now working for me, however it's not a very elegant solution.
use Enterprise Services with transactional components
I have seen this happen in my own environment a number of times. The client application in this case is installed on many machines. Some of those machines happen to be laptops people were leaving the application open disconnecting it and then plugging it back in and attempting to use it. This will then cause the error you have mentioned.
My first point would be to look at the network and ensure that servers aren't on DHCP and renewing IP Addresses causing this error. If that isn't the case then you have to start trawlling through your event logs looking for other network related.
Unfortunately it is as stated above a network error. The main thing you can do is just monitor the connections using a tool like netmon and work back from there.
Good Luck.
You should also check hardware connectivity to the database.
Perhaps this thread will be helpful:
http://channel9.msdn.com/forums/TechOff/234271-Conenction-forcibly-closed-SQL-2005/
I'm using reliability layer around my DB commands (abstracted away in the repository interfaece). Basically that's just code that intercepts any expected exception (DbException and also InvalidOperationException, that happens to get thrown on connectivity issues), logs it, captures statistics and retries everything again.
With that reliability layer present, the service has been able to survive stress-testing gracefully (constant dead-locks, network failures etc). Production is far less hostile than that.
PS: There is more on that here (along with a simple way to define reliability with the interception DSL)
I had the same problem. I asked my network geek friends, and all said what people have replied here: Its the connection between the computer and the database server. In my case it was my Internet Service Provider, or there router that was the problem. After a Router update, the problem went away. But do you have any other drop-outs of internet connection from you're computer or server? I had...
I experienced the transport error this morning in SSMS while connected to SQL 2008 R2 Express.
I was trying to import a CSV with \r\n. I coded my row terminator for 0x0d0x0a. When I changed it to 0x0a, the error stopped. I can change it back and forth and watch it happen/not happen.
BULK INSERT #t1 FROM 'C:\123\Import123.csv' WITH
( FIRSTROW = 1, FIELDTERMINATOR = ',', ROWTERMINATOR = '0x0d0x0a' )
I suspect I am not writing my row terminator correctly because SQL parses one character at a time right while I'm trying to pass two characters.
Anyhow, this error is 4 years old now, but it may provide a bit of information for the next user.
I just wanted to post a fix here that worked for our company on new software we've installed. We were getting the following error since day 1 on the client log file: Server was unable to process request. ---> A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.) ---> The semaphore timeout period has expired.
What completely fixed the problem was to set up a link aggregate (LAG) on our switch. Our Dell FX1 server has redundant fiber lines coming out of the back of it. We did not realize that the switch they're plugged into needed to have a LAG configured on those two ports. See details here: https://docs.meraki.com/display/MS/Switch+Ports#SwitchPorts-LinkAggregation