In our application, there are scheduler queries running in background.
While profiling the code through Jprofiler in Java EE & probes - JBDC
thread selection - all thread groups
aggregation level - methods
thread status - all states is selected.
so the list of JDBC queries shown under Java EE & probes - JBDC contains scheduler related queries as well, and they contribute to hotspot list.
My question is : when i launch my application and start profiling code, does the time incurred in execution of scheduler queries a part of the time required to render the pages of my applicaion or that time is independent?
Also is there a option in Jprofiler to have exact time like Httpwatch that shows the time to render application pages?
"scheduler query" does not sound like any pages are rendered.
You can see page rendering times in the URL nodes in the call tree. They show the servlet path rather than a method name.
Related
I'm currently experiencing some hangs on production environment, and after some investigation I'm seeing a lot of request queued up in the worker process of the Application Pool. The common thing is that every request that is queued for a long time is a web api request, I'm using both MVC and Web API in the app.
The requests are being queued for about 3 hours, when the application pool is recycled they immediately start queueing up.
They are all in ExecuteRequestHandler state
Any ideas for where should I continue digging?
Your requests can be stalled for a number of reasons:
they are waiting on I/O operation e.g database, web service call
they are looping or performing operations on a large data set
cpu intensive operations
some combination of the above
In order to find out what your requests are doing, start by getting the urls of the requests taking a long time.
You can do this in the cmd line as follows
c:\windows\system32\inetsrv\appcmd list requests
If its not obvious from the urls and looking at the code, you need to do a process dump of the w3wp.exe on the server. Once you have a process dump you will need to load it into windbg in order to analyze what's taking up all the cpu cycles. Covering off windbg is pretty big, but here's briefly what you need to do:
load the SOS dll (managed debug extension)
call the !runaway command
to get list of long running threads dive into a long running thread
by selecting it and calling !clrstack command
There are many blogs on using windbg. Here is one example. A great resource on analyzing these types of issues is Tess Ferrandez's blog.
This is a really long shot without having first hand access to your system but try and check the Handler mappings in IIS Manager gui for your WebApi. Compare it with IIS settings of your DEV or any other Env where it works.
IF this isnt the issue then do a comparison of all other IIS settings for that App.
Good luck.
I have a web application that simply acts as a Front Controller using Spring Boot to call other remote REST services where I am combining Spring's DeferredResult with Observables subscribed on Scheduler.computation().
We are also using JMeter to stress out the web application, and we have noticed that requests start to fail with a 500 status, no response data and no logs anywhere when the number of concurrent threads scheduled in JMeter increases from 25, which obviously is a very "manageable" number for Tomcat.
Digging into the issue with the use of VisualVM to analyze how the threads were being created and used, we realized that the use of rx.Schedulers was somehow impacting the number of threads created by Tomcat NIO. Let me summarize our tests based on the rx.Scheduler used and a test in JMeter with 100 users (threads):
SCHEDULERS.COMPUTATION()
As we're using the Schedulers.computation() and my local machine has 4 available processors, then 4 EventLoop thread pools are created by RxJava (named RxComputationThreadPool-XXX) and ONLY 10 of Tomcat (named http-nio-8080-exec-XXX), as per VisualVM:
http://screencast.com/t/7C9La6K4Kt6
SCHEDULERS.IO() / SCHEDULERS.NEWTHREAD()
This scheduler seems to basically act as the Scheduler.newThread(), so a new thread is always created when required. Again, we can see lots of threads created by RxJava (named RxNewThreadScheduler-XXX), but ONLY 10 for Tomcat (named http-nio-8080-exec-XXX), as per VisualVM:
http://screencast.com/t/K7VWhkxci09o
SCHEDULERS.IMMEDIATE() / NO SCHEDULER
If we disable the creation of new threads in RxJava, either by setting the Schedulers.immediate() or removing it from the Observable, then we see the expected behaviour from Tomcat's threads, i.e. 100 http-nio-8080-exec corresponding to the number of users defined for the JMeter test:
http://screencast.com/t/n9TLVZGJ
Therefore, based on our testing, it's clear to us that the combination of RxJava with Schedulers and Tomcat 8 is somehow constraining the number of threads created by Tomcat... And we have no idea why or how this is happening.
Any help would be much appreciated as this is blocking our development so far.
Thanks in advance.
So I have some Java code that takes some time to complete (about 2 minutes). Nothing I can do about that.
But I am wondering how best to approach this in the XPages UI so that the user may still have to wait but has more control/interaction while it is running (not just a spinning wheel).
So from what I can see I can do the following.
Java class called in XPage wrapped in a thread.
Java Agent called from XPage in a thread.
Java Agent called from an XPage, but waits for a document to be updated.
Eclipse plugin (For in the client) is activated. Not sure how it would talk back to XPage though (via document?).
Any other methods?
If you created the thread in the XPage, is that going to cause any problems at the server end? Will I have to avoid using Notes objects in the Java class?
I would suggest using the OSGi Tasklet service, a.k.a. DOTS. This approach allows Java tasks to be scheduled or bound to events, just like agents, but perform significantly more efficiently than agents. Perhaps most pertinent to your need is the additional ability to trigger DOTS tasks via the console, which would allow your XPages code to start the Java code merely by issuing a remote console command via the session object.
In addition, check out the technique used in the XSP Starter Kit to provide a serverScope variable. If your code is running in a DOTS task (or even an agent), it's running in a different Java application, so it can't talk directly to the standard scope variables. The serverScope approach would theoretically allow you to store objects that can be accessed from both the XPage and the triggered task. This could aid in using Mark's technique, as mentioned above by Per, to convey progress to the user while the task is running: you'd just be storing the progress information in serverScope instead of sessionScope.
A solution would be to have an agent react on saving new documents in the database instead of kicking of the agent in your application and use threads ( because threads can be very dangerous and could easily kill your http task )
Another thing you could look into is why the code that you want to execute is taking 2 minutes to complete. What is the code for? Doing things in other databases or connect to other non notes resources?
I went through couple of articles that talk about Web Workers in HTML5 and I was not able to clearly understand the following:
Is the life cycle for a web worker limited to a single page or across pages of an domain?
Is the life cycle for a web worker persistant after a page is loaded?
Are web workers a better option to using than an ajax call within setInterval?
Appreciate if someone could help me shed some light on the above questions.
Is the life cycle for a web worker limited to a single page or across pages of an domain?
Dedicated worker is limited to a single page, while shared worker can be related to many webpages
Is the life cycle for a web worker persistant after a page is loaded?
It could be persistent if it has onmessage() defined, and it could also returns after execution, if I understand correctly. In spec it says: let that run until it either returns, fails to catch an exception, or gets prematurely aborted by the "kill a worker" or "terminate a worker"...
Are web workers a better option to using than an ajax call within setInterval?
It depends. You can't simply say it is better or not. At the moment Web worker is mainly used for offloading complex JavaScript algorithms to run in the background.
I have an application that is currently running on IIS 6.0 with one worker process (the default). I am trying to determine if creating a web garden will improve performance. I have read a bunch of articles that say that a web garden is not the right approach for everyone (since it duplicates resources, cache is not shared, etc). I could not find an article that had a clear rational for using a web garden (Microsoft's site provides three bullet points, but no specific examples can be found). My situation is as follows:
We have can have up to 40 concurrent users at a given time.
Our application performs a series of calcuations (on the magnitude of 1,000s of calculations) that can take up to 10 minutes to complete.
We have multipe database calls some of which can take upwards to 30 seconds to complete.
Will creating a web garden improve performance, or should I simply increase the number of threads in the current worker process? When would be an example of when you should use a web garden? If a thread in the current worker process is performing calcuations (running .net code) and/or calling the database, can other threads run at the same time (I assume yes).
Thanks.
Ryan
Personally, I have gone the route of using a web garden when my web application required frequent worker process recycles.
In this specific case we needed to recycle the worker process often because we were using CodeDOM to emit assemblies dynamically, which has a memory leak by definition as more assemblies are loaded.
Having a web garden helped avoid a delay in server response every time the worker process was recycled.