I am working on the Maximo anywhere 7.5.2.0 version. I could seen lot of log trace on console while login successful. This always taken some time for downloading data.
I wanted to be tuning the performance.
And also wanted to be stoped the log trace while production. Can I do the code optimazation for performace tuning. If yes, Kindly suggest where I can do it.
Thanks in advance.
If you change the logLevel="0" in the app.xml it will disable logging. In future releases, we've done a better job of disabling the logging even more at this lower log level. The latest iFix for 7521 should have this fix.
Related
Over the past two months, my app has become significantly more complex. I use Transactions to complete 90% of all document writes client side. I have added quite a few listeners recently as well. Over the apps development, a linear increase in transaction and listener usage has caused an exponential spike in crashes. These crashes are just from testing using one device! Furthermore, the crashes happen exclusively on Android devices...
These are the four causes of every crash my app has seen:
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground(CloudFirestorePlugin.java:613)
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$DocumentObserver.onEvent (CloudFirestorePlugin.java:429)
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$EventObserver.onEvent (CloudFirestorePlugin.java:451)
io.flutter.plugins.firebase.cloudfirestore.CloudFirestorePlugin$5.doInBackground (CloudFirestorePlugin.java:633)
The information provided doesn't help in narrowing down the problem. I would normally assume that I am doing something wrong, but the fact that this occurs exclusively on android devices leads me to believe something is wrong at the package level. Digging online through forums and documentation it appears I am not alone with this Firestore Transaction/Listener related issue.
Has anybody had similar issues and found a solution? This isn't only a problem for me, it's a show stopper.
Is it possible that since introducing listeners I have created this problem?
This seems to be a known issue on github, please confirm but the issue only occurs on Android -Fluter with the listeners.
They mentioned:
Just waiting for the green signal to make sure this doesn't catch some other edge cases and I can go ahead with a fix patch.
You shoudl post that your are being affected also and followup there.
I am using test complete as a automation development tool and I need to execute the code in the cross browser tool (CBT).
I am experiencing a significant slowness in CBT execution. All tests are failing.
Appreciate that you can help me to resolve this issue.
Regards,
Senani.
Typically the log files give a good idea of what caused the failure in your test. I have noticed that sometimes delays need to be added to the tests in order to get them to complete without error, but once again that is what my log files said. This link may also help. https://support.smartbear.com/testcomplete/docs/app-testing/web/general/cross-browser/about.html
I have a site that runs off of dotNetNuke with much customization. In production, this site runs fine, speed is relatively optimal, etc. In development, it's PAINFULLY slow (anywhere from 10-30 seconds per action slow). Can anyone recommend any tools/ideas on how to diagnose this issue? The environments are very similar (the dev database is not as powerful as the production one, but it's not enough to warrant this type of delay). I'm looking for something that can help determine all the points of contact for the requests, etc.
Any thoughts?
Try out the following tools:
YSlow: YSlow analyzes web pages and why they're slow based on Yahoo!'s rules for high performance web sites
PageSpeed: The PageSpeed family of tools is designed to help you optimize the performance of your website. PageSpeed Insights products will help you identify performance best practices that can be applied to your site, and PageSpeed optimization tools can help you automate the process.
Firebug and Network Monitoring: Look at detailed measurements of your site's network activity.
Fiddler
YSlow, PageSpeed, and Firebug are great tools you should definitely use but the fact that you're only seeing the issue in the development environment seems to imply it's not the site that's the problem but something with the development environment. Generally, I find most slowness in these cases is related to Disk and/or RAM issues. Use Task Manager to verify the machine has enough RAM for it's current load. Make sure there's sufficient available disk space for proper caching to occur. You may need a faster hard drive.
Run the site lokal in release mode and see if it changes something.
If you can run the live site in debug mode and see if it slows down as much as in the lokal environment.
An ASP.NET web app running on IIS6 periodically shoots the CPU up to 100%. It's the W3WP that's responsible for nearly all CPU usage during these episodes. The CPU stays pinned at 100% anywhere from a few minutes to over an hour.
This is on a staging server and the site is only getting very light traffic from testers at this point.
We've running ANTS profiler on the server, but it's been unenlightening.
Where can we start finding out what's causing these episodes and what code is keeping the CPU busy during all that time?
Standard Windows performance counters (look for other correlated activity, such as many GET requests, excessive network or disk I/O, etc); you can read them from code as well as from perfmon (to trigger data collection if CPU use exceeds a threshold, for example)
Custom performance counters (particularly to time for off-box requests and other calls where execution time is uncertain)
Load testing, using tools such as Visual Studio Team Test or WCAT
If you can test on or upgrade to IIS 7, you can configure Failed Request Tracing to generate a trace if requests take more a certain amount of time
Use logparser to see which requests arrived at the time of the CPU spike
Code reviews / walk-throughs (in particular, look for loops that may not terminate properly, such as if an error happens, as well as locks and potential threading issues, such as the use of statics)
CPU and memory profiling (can be difficult on a production system)
Process Explorer
Windows Resource Monitor
Detailed error logging
Custom trace logging, including execution time details (perhaps conditional, based on the CPU-use perf counter)
Are the errors happening when the AppPool recycles? If so, it could be a clue.
It's not much of an answer, but you might need to go old school and capture an image snapshot of the IIS process and debug it. You might also want to check out Tess Ferrandez's blog - she is a kick a** microsoft escalation engineer and her blog focuses on debugging windows ASP.NET, but the blog is relevant to windows debugging in general. If you select the ASP.NET tag (which is what I've linked to) then you'll see several items that are similar.
If your CPU is spiking to 100% and staying there, it's quite likely that you either have a deadlock scenario or an infinite loop. A profiler seems like a good choice for finding an infinite loop. Deadlocks are much more difficult to track down, however.
Process Explorer is an excellent tool for troubleshooting. You can try it for finding the problem of high CPU usage. It gives you an insight into the way your application works.
You can also try Procdump to dump the process and analyze what really happened on the CPU.
Also, look at your perfmon counters. They can tell you where a lot of that cpu time is being spent. Here's a link to the most common counters to use:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/852720c8-7589-49c3-a9d1-73fdfc9126f0.mspx?mfr=true
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/be425785-c1a4-432c-837c-a03345f3885e.mspx?mfr=true
We had this on a recursive query that was dumping tons of data to the output - have you double checked everything does exit and no infinite loops exist?
Might try to narrow it down with a single page - we found ANTS to not be much help in that same case either - what we ended up doing was running the site hit a page watch the CPU - hit the next page watch CPU - very methodical and time consuming but if you cant find it with some code tracing you might be out of luck -
We were able to use IIS log files to track it to a set of pages that were suspect -
Hope that helps !
This is a guess at best, but perhaps your development team is building and deploying the application in debug mode, in stead of release mode. This will cause the occurrence of .pdb files. The implication of this is that your application will take up additional resources to collect system state and debugging information during the execution of your system, causing more processor utilization.
So, it would be simple enough to ensure that they are building and deploying in release mode.
This is a very old post, I know, but this is also a common problem. All of the suggested methods are very nice but they will always point to a process, and there are many chances that we already know that our site is making problems, but we just want to know what specific page is spending too much time in processing.
The most precise and simple tool in my opinion is IIS itself.
Just click on your server in the left pane of IIS.
Click on 'Worker Processes' in the main pane. you already see what application pool is taking too much CPU.
Double click on this line (eventually refresh by clicking 'Show All') to see what pages consume too much CPU time ('Time elapsed'
column) in this pool
If you identify a page that takes time to load, use SharePoint's Developer Dashboard to see which component takes time.
We have some performance problems with one of our applications. I thought about using something like dotTrace to find out where the problems are, but dotTrace would probably degrade performance even more.
What's the best way to profile an application that's on a prod environment w/o affecting performance too much?
The general answer is "don't do it".
Other than that, you can gain a lot by using performance counters. If the built-in counters don't help, you can create your own.
Among other things, the performance counters may give you an idea of how to reproduce the performance problems through load testing.
The next idea is to narrow down the area you're interested in. There's no sense impacting performance for the entire application if it turns out to be your web service access that's slow.
Next, be sure to have instrumented your application, preferably by using configuration. The Enterprise Library Logging Application Block is great for that, as it allows you to add the logging to your application, but have it configured off. Then, you can configure what kind of information to log, and where to log it to.
This gives you choices about how expensive the logging should be, from logging to the event log to logging to an XML file. And you can decided this all at runtime.
Finally, you're not going to be able to use dotTrace or something else that requires restarting IIS an adding code to your running application. Not in production. The ideas above are for the purpose of not needing to do so.
Profiling memory or cpu?
Memory: the best way would be to create a memory dump of the w3wp process (launch task manager, right click the process then "create dump"), then copy the dump to your local machine and analyse it with WinDbg. And look at which classes consume the most memory. There are lots of questions/answers here on Stackoverflow on how do do that (how to use WinDbg and analyse the .NET heap).
CPU: we use a short command-line profiler by Sam Saffron (woohoo, one of the creators of Stackoverflow!) His project is abandoned, but we forked it and maintain it here. https://github.com/jitbit/cpu-analyzer Everyone's welcome to contribute. It attaches to your threads using Microsoft's DbgManager and finds call-stacks that take longest time to execute.
Did you load-test the application on a number of sessions that's anywhere near the actual load of the production environment?
The first thing that comes to mind is that your app is not scaling well under load or that your db is not scaling well with an increase in size (causing this way problems even with a very limited number of concurrent sessions) but it could be anything really.
My suggestion is to replicate the production environment and run proper load-testing then look at the data and it'll give you some clue.
you don't wanna play games with your production environment, but if you don't have it already you could use logging to keep track of the sequence and time spans of key-events and take it from there.
You could use ants profiler
http://www.red-gate.com/products/ants_performance_profiler/index2.htm
They claim that "the overhead was hardly noticeable".
There is a 14 day free trial so you could give it a try.
Edit: I agree with John's comment, it will disrupt, require some down time, to get it started / stopped. Best to use it on a test environment to identify the bottle necks.
You can use ants profile as well as performance counter of the system. It will help you to determine whats the problem.
Here are some details about performance counter..
http://msdn.microsoft.com/en-us/library/fxk122b4.aspx
http://msdn.microsoft.com/en-us/library/ms979204.aspx
http://www.codeproject.com/KB/dotnet/perfcounter.aspx
I would recommend to take several memory dumps of the process in Production, look at all the stack traces and see if you find a pattern.