I have a local web application running on IIS which contacts a service deployed on AWS.
While I was testing the throughput against the AWS service I realised that my local web application didn't respect the ConnectionLimit value set in the web.config through the following code:
<system.net>
<connectionManagement>
<add address="*" maxconnection="48" />
</connectionManagement>
</system.net>
Instead the following code always return int.MaxValue
#(ServicePointManager.FindServicePoint(new Uri("https://myawsservice/")).ConnectionLimit)
This seems to contradict what I have read here: http://msdn.microsoft.com/en-us/library/ms998583.aspx#scalenetchapt17_topic14
Increasing maxconnection enables more calls to be executed concurrently to a remote Web service. This attribute does not affect local Web service calls. An increase in the number of concurrent calls causes an increase in the utilization of threads that are used to make the remote calls.
I would expect Int32.MaxValue to only be applicable to local web services. I don't consider my AWS service to be local.
Did I miss something? Did I misunderstood the definition of local web service?
Thanks in advance for your help.
Nico.
Found the issue.
If the processModel autoConfig attribute is set to "true" inside your machine.config then you can't override the ConnectionLimit using the web.config
<system.web>
<processModel autoConfig="true" />
...
</system.web>
Set it to "false" if you want to control the ConnectionLimit but in that case you'll probably want to review the other values set when autoConfig is on.
Related
I am trying to call a webservice to get information about specific objects. It works perfectly fine in my test WinForms application, basically after I added the service reference I did not have to do anything else than creating a local client in my C# class, setting up the input parameters and calling the method that was in the documentation and I received the response I wanted. Very simple webservive, no https, no magic.
I copied my code to my MVC web application, I made sure to copy EXACTLY the same url, web.config settings (bindings, endpoints), I even updated the service reference many times, but in MVC it does not work. The error message says:
"There was no endpoint listening at 'webservicename' that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details."
The inner exception is:
"No connection could be made because the target machine actively refused it 127.0.0.1:8888"
I have set up my hosts file, because I am using Local IIS and wanted to use the websie's name in the url, so I have this in my hosts:
"127.0.0.1 www.mywebsite.local"
I have a feeling that either my firewall or app pool setting causes this problem, but I could not figure out which one. Once again, the webservice is working perfectly fine from my basic test WinForms app.
I tried to change the Identity of my app pool to something else than ApplicationPoolIdentity (I tried NetworkService, LocalService, LocalSystem), but it did not help.
.Net version is 4.5 in WinForms and 4.5.1 in MVC.
Any ideas?
Edit:
It looks like there is a problem with the proxy settings. In the MVC web.config I had the following section:
<system.net>
<defaultProxy enabled="true">
<proxy proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
I do not know why, but when I set it to false, the problem goes away...I am not an expert of proxies. Does it mean I have to add special settings to my firewall?
I have trouble posting 'large' objects to my web api using the HttpClient's PostAsJsonAsync method. The objects contain a base64 encoded image file.
After a period which seems like the client's timeout setting, the exception
'A task was canceled.'
is thrown by the HttpClient. The timeout is already set very high (10 minutes). This only happens with files larger than ~2 MB. Anything smaller works fine. I know that the request does not even hit the first line of code in the controller method because the first line is a logging line and the log is empty. There are no exceptions in the server event viewer.
It is hard to pin down the issue because the controller works fine when I deploy the web api on my local IIS. But when I deploy it on my Azure VM, it only work for small files. The web.config files are identical.
maxRequestLength is already set high enough.
<httpRuntime targetFramework="4.5.2" maxRequestLength="1048576" />
Instead of IIS hosting in an Azure VM, i've just tried to deploy the API as an app service. The exact same thing happens there.
You can also try setting this limit:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="1073741824" />
</requestFiltering>
</security>
</system.webServer>
Note that contrary to the maxRequestLength parameter, this value is in bytes.
In my company API (we use WebAPI 2) we want to return 504 (gateway timeout) when controller action takes to much time. Sometimes inside our WebAPI actions we cooperate with external company APIs, which not always work correctly, so it could be convinient for user.
I added entry in web.config, but it doesn't work.
<system.transactions>
<defaultSettings timeout="00:00:10" />
</system.transactions>
How can I resolve this problem?
timeout is set in number of seconds, and I Think you should use httpruntime executiontimeout instead of transaction timeout wich only affects the transactions within the request
<system.web>
<httpRuntime executionTimeout="10" />
</system.web>
I have a standard Web Service that processes JSON requests via an webHttpBinding. I am trying to find out whether there is a limit on how many concurrent connections it can handle and how to control it. Can't find anything. I am missing something simple or some setting?
Here is a skeleton of my service:
[ServiceContract]
public interface IMyService {...}
[ServiceErrorBehavior(typeof(ErrorHandler))]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class MyService : IMyService {...}
I have some suggestion for this, but this will not be direct config related change. Hold on and read this.
In WCF, there is InstanceContextMode and ConcurrencyMode properties defined for ServiceBehavior. These parameters are configurable only within the service code, and not in XML configuration, because they relate to the runtime behavior of the service and the service developer should be aware of their values. The InstanceContextMode parameter determines how many instances of the service have to be created by the WCF runtime. The possible values are:
PerCall: a new InstanceContext object is created for each call.
PerSession: a new InstanceContext object is created for each session. If the channel does not create a session this value behaves as if it were PerCall.This is the default value.
Single: only one InstanceContext object is used for all incoming calls and is not recycled subsequent to the calls. If a service object does not exist, one is created.
More helpful Blog
Use WCF Service Throttling to control the service.
<behaviors>
<serviceBehaviors>
<behavior name="Throttled">
<serviceThrottling
maxConcurrentCalls="1"
maxConcurrentSessions="1"
maxConcurrentInstances="1"
/>
</behavior>
</serviceBehaviors>
</behaviors>
Always remember that service behaviors do not override limits defined in the host (or binding). For example when using webHttpBinding the default IIS Maximum Concurrent Connections would likely need to be changed for large concurrency values.
Turns out it has more to do with threading than anything else. The default ASP.NET settings are pretty conservative, so you have to hike them up. Once I did that, the concurrent connections bottleneck completely disappeared.
Make sure you have the following in the appropriate machine.config (not web.config):
<configuration>
<system.net>
<connectionManagement>
<add address="*" maxconnection="100" />
</connectionManagement>
</system.net>
<system.web>
<processModel
autoConfig="true"
maxWorkerThreads = "100"
maxIoThreads = "100"
minWorkerThreads = "50"
minIoThreads = "50"
/>
<httpRuntime
minFreeThreads="176"
minLocalRequestFreeThreads="152"
/>
</system.web>
</configuration>
I took all this info from Tuning IIS article by Stuart Brierley. The only thing I changed significantly from his recommendations is maxConnection value.
I need to get rid of the Expect: 100-Continue header in HTTP message, when communicating with WebService using WCF in Windows Store App.
I have found a lot of solutions, but none of them is possible in Windows 8:
ServicePoint.Expect100Continue = false; doesn't exist in Store App any more (No SericePoint or ServicePointManager class),
I cannot change configuration in web.config file, because it doesn't exist in Store App,
It is possible to change the flag in HttpClient, but I cannot access it, when using WCF,
I tried to manipulate with message headers using IClientMessageInspector, but the default HTTP headers are being added later, in higher layers, so my changes will be ovverriden.
Does anyone have any other ideas?
There are 2 ways to deal with this.
You can turn set expect100Continue="false" in you app.config or web.config, but this will be global. This could be an issue if some external services prefer to use the header expect100Continue. Here's how:
<system.net>
<settings>
<servicePointManager expect100Continue="false"/>
</settings>
</system.net>
Or you can do it in code for a specific endpoint as follows:
System.Net.ServicePoint servicePoint =
System.Net.ServicePointManager.FindServicePoint(myWcfService.Endpoint.Address.Uri);
servicePoint.Expect100Continue = false;
// now execute some service operation