I am getting the below error whenever the size of parameters in my form exceeds 10,000.
com.ibm.wsspi.webcontainer.util.RequestUtils parseQueryString
SRVE0325E: Exceeding maximum parameters allowed per request 10,000
I did some investigation and found that the issue can be resolved by adding a parameter com.ibm.ws.webcontainer.maxParamPerRequest in webcontainer custom properties and setting its value to -1.
However my problem is that I am getting this error only in production environment and not in test environment. The parameter com.ibm.ws.webcontainer.maxParamPerRequest is not set in test environments also.. The version of websphere application server in test environment is 7.0.0.19 and that in production is 7.0.0.23.
There is a WEB server infront of my WAS server and i also checked the value of PoolDataSize parameter in plugin.xml and found its value to be "-1".
Does different fixpack versions of websphere in test and production have to do anything with this?
Please help
The com.ibm.ws.webcontainer.maxParamPerRequest property to change the maximum number of parameters allowed in your inbound requests did not exist until WebSphere 7.0.0.23.
The property was introduced in order to address a potential DOS vulnerability.
[It's hard to figure why your application needs more than 10000 parameters, though.]
Related
I need to run an aggregate query to calculate the count of records e.g. SELECT r.product_id, r.rating, COUNT(1) FROM product_ratings r GROUP BY r.product_id, r.rating. The query works perfectly fine on the Azure Data Explorer, albeit a little slow. An optimised version of the query takes about 30 seconds when executed on the Data Explorer. However, when I run the same query in my Java app, it appears to be timing out in 5 seconds with the following exception:
com.azure.cosmos.implementation.GoneException: {"innerErrorMessage":"The requested resource is no longer available at the server."}
I believe this is due to a default request timeout of 5 seconds defined in ConnectionPolicy (both Direct and Gateway modes). I can't find a way to override this default. Is there a way to increase the request timeout? Is there another possible reason for this error?
Tried this both on the Java SDK v4 and Spring Data Connector v3 with the same end result i.e. GoneException.
You could consider the following recommendations,
The following should help to address the issue:
Try to increase http connection pool size (default is 1000, you can increase to 2000)
If you are using GateWay mode, try the DirectMode, more traffic will go over tcp and less traffic over http
You can refer the Github code on setting the timeout.
I am using an IIS web garden for long running requests with 15 worker processes.
With, for example, 3 browsers, typically multiple worker processes are used.
With Apache jMeter, all requests are using the same worker process.
Is there a way to force the use of multiple worker processes?
This may have at least 2 explanations:
You have some hard coded ID or session ID in your test plan. Check for their presence and remove them, add Cookie Manager to your test
You have a load balancer that work in Source IP mode, in this case you need to either change policy to Round Robin or add 2 other machines
If you are using 1 thread with X iterations and expecting different workers then check that:
Cookie Manager is configured this way:
And Thread Group this way (notice "Same User on each iteration is unchecked"):
If issue persists, then please share you plan and check that you don't have somewhere in Header Manager a hardcoded id leading to using 1 worker
Well-behaved JMeter script should produce the same network footprint as the real browser do so if you're observing inconsistencies most probably your JMeter configuration is not matching requests which are being sent by the real browser.
Make sure that your JMeter test is doing what it is supposed to be doing by inspecting requests/responses details using View Results Tree listener
Use a 3rd-party tool like Wireshark or Fiddler to capture the requests originating from browser/JMeter, detect the differences and amend your JMeter configuration to eliminate them
More information: How to make JMeter behave more like a real browser
In the absolute majority of cases JMeter script is not working as expected due to missing or improperly implemented correlation of the dynamic values
Good Afternoon Everyone,
I am load testing my .NET Web API which is hosted on a Windows 2008 Server virtual machine. I am using Visual Studio 2012 Load Test. However, once my load test reaches 780 concurrent users, the CPU % starts to decrease as shown in the image attached. The load test reaches a maximum of 1000 concurrent users but the CPU % is still decreasing at the highest user load. I cannot explain why. Is any kind of IIS limit being reached? Why does this occur? Is the maximum user load reached for this function?
Just looking for an explanation to this result and some guidance.
Thank you
IIS does have separate output cache settings which are enabled by default which does start to make sense after considering how it handles dynamic content with static response and cache worthiness:
The IIS output caching feature targets semi-dynamic content. It lets
you cache static responses for dynamic requests and increase
scalability
Configuring Cache Worthiness:
Even if you enable output caching, IIS does not immediately cache a
request. It must be requested a few times before IIS considers a
request to be “cache worthy.” Cache worthiness can be configured via
the ServerRuntime section.
Two properties determine cache worthiness:
frequentHitTimePeriod
frequentHitThreshold
A request is only cached if more than frequentHitThreshold requests for a cacheable URL arrive within the frequentHitTimePeriod.
This was a good explanation: http://www.iis.net/learn/manage/managing-performance-settings/configure-iis-7-output-caching
I have a intranet SiteCore website set up on IIS 7 which randomly throws the following error message
HTTP Error 503.2 - Service Unavailable
The serverRuntime#appConcurrentRequestLimit setting is being exceeded.
To fix this issue, I have made following changes
Increased the Queue Length of application pool myrjetAppPool from 1000 to 65535.
Modified Machine.Config to increase requestQueueLimit property of ProcessModel element to 100000
Increased appConcurrentRequestLimit to 10000 by running
C:\Windows\System32\inetsrv\appcmd.exe set config /section:serverRuntime /appConcurrentRequestLimit:100000
But I'm still getting the same error. ANy help is greatly appreaciated.
You might check to see where all your threads are going. We had occurrences where threads for Media Library assets were hanging and blocking up the queue.
In IIS Manager, select the server node from the tree, then the "Worker Processes" feature icon, then right-click the application pool of interest and select "View current requests". You might find something is getting stuck. I sometimes hit F5 on this screen a few dozen times in very quick succession to see the rate the requests are going through (of course Performance Monitor is better for viewing metrics but it won't tell you what URLs are being processed).
Investigate references in the linked url to 'MaxConcurrentReqeustsPerCPU' which you may need to set by creating a new registry key, depending on your OS and framework.
https://learn.microsoft.com/en-us/archive/blogs/tmarq/asp-net-thread-usage-on-iis-7-5-iis-7-0-and-iis-6-0
As already commented - check the actual concurrent request count using performance counters to determine which limit you're hitting i.e. it could be a limit of 5000 or maybe 12 (per cpu).
Edit: I realise this may look like I'm talking about a different setting entirely, but I believe there is overlap here.
We got this problem after an installation of an IIS plugin. After long investigating we saw that the config-file C:\Windows\System32\inetsrv\config\applicationHost.config had an extra location tag for the site with the problem. After removing the extra entry and an iisreset, the site/server worked normally againg. So something must went wrong during the installation....
I am using the AppFabricCacheSessionStoreProvider and occasionally get the error
ErrorCode:SubStatus:There is a temporary failure. Please retry later.
(The request failed, because you exceeded quota limits for this hour.
If you experience this often, upgrade your subscription to a higher
one). Additional Information : Throttling due to resource :
Connections.
I am using a basic 128mb cache with a web role which has two instances. What is the default MaxConnectionToServer value if it is not set? I think when I fire up a staging instance as well it can cause this error (4 simultaneous instances). Will setting MaxConnectionToServer to a higher value make it better or worse? I believe the 128mb cache has limit of 5 connections so should I set it to 1 which would mean only 4 connections could be used. The cache is not used elsewhere in the app.
The default for MaxConnectToServer is 1, so you shouldn't have to change this setting, but if you do set it to 1, it will avoid anyone else looking at your config from getting confused as well. If you set it to a higher value then you will see this problem more often.
The cache session provider seems to be a little slow at disposing of its connections to the cache when it doesn't need them any more. This means that if you're running a number of instances which is close to the limit for you cache size you do seem to see this error. You're correct a 128MB cache does only allow 5 concurrent connections. If you want to avoid this problem at the moment the only solution I'm aware of is to buy the next cache size up.