I have a C# MVC application hosted in IIS test environment with only one action method in APIController. Clients call this single method and depending upon the parameters different small processes are performed.
I am using IIS 10.0.17763. Application is built in .Net Framework 4.6
I have disabled these modules as i don't need them.
WebDAVModule
WindowsAuthentication
ScriptModule-4.0
DefaultAuthentication
ServiceModel-4.0
UrlAuthorization
FileAuthorization
The problem is that under load test from jmeter, all calls somehow stay longer in ResolveRequestCache State.
Can someone guide me the problem behind or suggest me something to check. I am not using any kind of caching due to business requirement.
Here is the Screenshot of requests states from IIS
Edit. I have removed some other modules too to check the effect.
Here is the list of loaded modules in my application
Related
For functional automation we use to create a framework which is reusable for automating application. Is there any way to create Performance testing framework in jmeter. So that we can use same framework for Performance testing of different applications.
Please help if any one knows and provide more information regarding it.
You can consider JMeter as a "framework" which already comes with test elements to build requests via different protocols/transports, applying assertions, generating reports, etc.
It is highly unlikely you will be able to re-use existing script for another application as JMeter acts on protocol level therefore there will be different requests for different applications.
There is a mechanism in JMeter allowing to re-use pieces of test plan as modules so you won't have to duplicate your code, check out Test Fragments and Module Controller, however it is more applicable for a single application.
The only "framework-like" approach I can think of is adding your JMeter tests into continuous integration process so you will have a build step which will execute performance tests and publish reports, basically you will be able to re-use the same test setup and reporting routine and the only thing which will change from application to application will be .jmx test script(s). See JMeter Maven Plugin and/or JMeter Ant Task for more details.
You must first ask yourself, how dynamic is my conversation that I am attempting to replicate. If you have a very stable services API where the exposed external interface is static, but the code to handle it on the back end is changing, then you have a good shot at building something which has a long life.
But, if you are like the majority of web sites in the universe then you are dealing with developers who are always changing something, adding a resource, adding of deleting form values (hidden or not), headers, etc.... In this case you should consider that your scripts are perishable, with a limited life, and you will need to rebuild them at some point.
Having noted the limited lifetime of a piece of code to test a piece of code with a limited lifetime, are there some techniques you can use to insulate yourself? Yes. Rule of thumb is the higher up the stack you go to build your test scripts the more insulated you are from changes under the covers ( assuming the layer you build to is stable ). The trade off is with more of the intelligence under the covers of your test interface, the higher the resource cost for any individual virtual user which then dictates more hosts for test execution and more skew from client side code which can distort the view of what is coming from the server. An example, run a selenium script instead of a base jmeter script. A browser is invoked, you have the benefit of all of the local javascript processing to handle the dynamic changes and your script has a longer life.
I'm doing some in memory Caching for some Plugins in Microsoft CRM. I'm attempting to figure out if I need to be concerned about different orgs populating the same cache:
// In Some Plugin
var settings = Singleton.GetCache["MyOrgSpecificSetting"];
// Use Org specific cached Setting:
or do I need to do something like this to be sure I don't cross contaminate settings:
// In Some Plugin
var settings = Singleton.GetCache[GetOrgId() + "MyOrgSpecificSetting"];
// Use Org specific cached Setting:
I'm guessing this would also need to be factored in for Custom Activities in the AsyncWorkflowService as well?
Great question. As far as I understand, you would run into the issue you describe if you set static data if your assemblies were not registered in Sandbox Mode, so you would have to create some way to uniquely qualify the reference (as your second example does).
However, this goes against Microsoft's best practices in Plugin/Workflow Activity development. Every plugin should not rely on state outside of the state that is passed into the plugin. Here is what it says on MSDN found HERE:
The plug-in's Execute method should be written to be stateless because
the constructor is not called for every invocation of the plug-in.
Also, multiple system threads could execute the plug-in at the same
time. All per invocation state information is stored in the context,
so you should not use global variables or attempt to store any data in
member variables for use during the next plug-in invocation unless
that data was obtained from the configuration parameter provided to
the constructor.
So the ideal way to managage caching would be to use either one or more CRM records (likely custom) or use a different service to cache this data.
Synchronous plugins of all organizations within CRM front-end run in the same AppDomain. So your second approach will work. Unfortunately async services are running in separate process from where it would not be possible to access your in-proc cache.
I think it's technically impossible for Microsoft NOT to implement each CRM organization in at least its own AppDomain, let alone an AppDomain per loaded assembly. I'm trying to imagine how multiple versions of a plugin-assembly are deployed to multiple organizations and loaded and executed in the same AppDomain and I can't think of a realistic way. But that may be my lack of imagination.
I think your problem lies more in the concurrency (multi-threading) than in sharing of the same plugin across organizations. #BlueSam quotes Microsoft where they seem to be saying that multiple instances of the same plugin can live in one AppDomain. Make sure multiple threads can concurrently read/write to your in-mem cache and you'll be fine. And if you really really want to be sure, prepend the cache key with the OrgId, like in your second example.
I figure you'll be able to implement a concurrent cache, so I won't go into detail there.
I have tried two things. One is pre-compiling my ASP.NET MVC 3 project using aspnet_compiler, and the other is using RazorGenerator in the project to allow the views to be compiled. Using both methods, I still see that pages in my site are having to compile on the first access. I see csc.exe running on the server when they are first accessed and it doesn't happen the next time. Why are these pre-compiling steps not preventing this and thus letting me have faster first time access?
Pre-compiling an application won't improve the first request startup time because there are still many things that need to happen when the first request arrives:
The Application_Start method executes
Controllers and Views location are retrieved and cached for subsequent requests
...
You could use the AutoStart feature of IIS 7.5 and ASP.NET 4.0 if you want to preload an application in memory when the web server starts. This way the application will be hot and waiting for the first request.
We have a very strange issue that we're dealing with.
We have an MVC 3 application that we are still developing, and Monday we started running into an issue with four specific routes (methods) in one of our controllers. All four of these routes are used in the management of roles and deal with either creating or editing a role. We have two different tiers of roles in the application, so there are two routes for creating a role for each tier, and two routes for editing a role for each tier. Both methods for the corresponding create routes call the same view, as well as the two methods for the corresponding edit routes. Both views call a shared partial view that contains the form fields that correspond to the properties of the role being created or edited.
Here's the issue.
If I attempt to hit these routes without running the debugger first, IIS will hang. It will not error out, throw an error, or even register the request in the IIS log.
HOWEVER, if I attempt to access those routes in the debugger, regardless of whether I have a breakpoint set up or not, the routes function as they should.
To make life a little more interesting, if I attempt to access those same routes AFTER I've run and shut down the debugger, the routes STILL function as they should.
We can reproduce this behavior on EVERY machine on our development team AND our staging server (except the debugging part on staging).
The methods that correspond to all of these routes themselves rely on a couple of methods in the same web service in our middle tier. Those methods work properly outside of the debugger in our integration tests.
We've checked for endless loops in the code, but can't find anything that would create an endless loop under these conditions. In fact, there's only one loop in the shared view, but it's a for each loop which shouldn't ever result in an endless loop.
Lastly, when I attempt to hit any of these four routes without running under the debugger or at least running it on a previous request, IIS essentially hangs. It will not time out. It will not throw an error. It will not log an error to the IIS log. Finally, it will eat up system resources the the point that you have to either restart IIS or reboot the entire machine.
Has anyone ever seen this behaviour before? Any ideas on how to get around it? I've NEVER seen this behavior before, and the only thing that anyone in our development group could come up with was some sort of permissions issue on a file, but we're not accessing the file system (outside of the view files themselves, and they have proper permissions) at any point during the processing of these methods.
I'm open to any and all suggestions.
UPDATE #1:
I have also posted this question on the ASP.NET forums and I had someone ask a question for more information. Here's my response to their questions.
What IIS are we talking about?
IIS 7.5. We're using the full-fledged IIS, not IIS Express.
What error?
That's just it. There is no error. No error is being reported. In fact, the request itself isn't being recorded in the IIS log for the site IF we're attempting to access these routes without the debugger running. If the debugger is running, everything works as you would expect it to.
VS Cassini?
Nope. IIS 7.5 that comes with Windows 7.
If you deploy on IIS a default WebForm project , does it works?
Yes. Without an issue. I actually have a number of WebForms applications that I maintain for customers running on my development box. They all work without any issue whatsoever.
If you deploy on IIS a default MVC project , does it works?
Yes. I have a number of sites running on this box. All of these sites are running without a hitch. IN FACT, the vast majority of routes on this site can be accessed without any issue. The vast majority of routes WITHIN THIS VERY CONTROLLER can be accessed without any issue!!!
To reiterate, this controller allows a user to manage users, roles, and permissions within the application. We have methods in there for listing, creating, and updating users, roles, and permissions. The routes that hit the methods for managing users and permissions work regardless of whether the debugger is running or not. The ONLY routes giving us issues are the four routes that I described above.
We currently have 19 controllers in this application, each with a varying number of defined route methods. EVERY OTHER route defined for the application is working properly and is not exhibiting this behavior. These are the only four methods (routes) in this one particular controller where we are seeing this.
UPDATE #2:
I've narrowed this down to a REST call (to a service that we control) within the controller. Here's the weird part - if I go into the REST service and immediately return a value (don't process anything), it still hangs outside of the debugger. If I'm running inside of the debugger or immediately after running the debugger, everything works as it should.
If I attempt to hit that REST service in fiddler directly, it works like a charm.
I'm going to try changing the URL in the service contract for the web service I'm calling and see if that works. Maybe it's something to do with the REST URL on the web service.
UPDATE #3:
Just to add further confusion, I set up Fiddler to act as a proxy between my MVC application and the REST middle tier. For EVERY other REST call within the application, the proxy gets the request. For this particular REST call, the proxy NEVER gets the request.
Now here's the annoying part. The WebChannelFactory that we use to call all of the methods in the middle tier through REST is created using a utility class in our MVC application. This code is used to generate every channel, so there's no difference between the requests that populate the list of users and the one that populates the list of permissions (the one that's hanging).
This is a GET request that's hanging, so I was able to call it directly in the browser. It works without an issue. The issues doesn't appear to be on the service end, but somewhere in the MVC application.
Make sure that you don't pass in ViewBag.Variable.ToString(), since it's dynamic, it will not work!
For multiple reports, I have a scriptlet that calls many web services. The calls are done under the afterReportInit() method to fill a couple of HashMaps which in turn are used in the reports. The problem is that web services calls are performed at every report generation which results in very low performance.
I'm looking for a workaround to make thoses web services called once for all reports.
Note that reports are deployed on JasperServer
I'm looking into the thing. So far what I've found is that JasperReports has a custom class loader, JRClassLoader that would need to be extended:
http://grepcode.com/file/repo1.maven.org/maven2/net.sf.jasperreports/jasperreports/4.1.2/net/sf/jasperreports/engine/util/JRClassLoader.java#JRClassLoader.%3Cinit%3E%28java.lang.ClassLoader%29
I personally wouldn't bother with the class loading mechanism and would instead try caching the results of the web service calls using memcache if possible... Depending on your setup, apache could probably do this as well.