Currently our staging IIS puts 100% load on the CPU.
(I wasn't allowed to post with an image so I'll link it: http://i40.tinypic.com/1444qww.png)
I currently have been unable to find the cause of this behavior since the stack of the thread that causes the high load does not contain any application specific references. If anyone sees more in this screenshot then I or had a similar experience I'm glad to hear it.
Info:
Windows Server 2k8R2
If any more information is required I shall try to provide.
Thanks.
We found that one of the business layer classes was loading a 50k+ table into a dictionary in memory in its initialization. This caused the long wait as well as the high load. Changing this swiftly fixed our problem.
Related
I've been doing some refactoring on a slow running web application, and managed to reduce the number of requests and the size of the downloads to help improve the situation. Now the loading time is consistently shorter. However, consistently before there was hardly any time elapsed before the last 2 requests. Now consistently there is a gap.
Q1: What do these 'gaps' indicate in Chrome Network view?
Q2: Looking at the screenshots, the DOMContentLoaded time vs. the overall Finish time, are there any conclusions I can draw that could help me optimise further?
Record the page load in the Performance panel. See Get Started With Analyzing Runtime Performance to get the gist of how to use the panel. Understanding the network bottleneck can also help get you oriented.
However, you'll want to press the Reload page button (like Sam does in the "understanding the network bottleneck" video) instead of the Record button to record the page load performance, as the "get started with analyzing runtime performance" instructs you to do.
Once you've got a recording, the Main section shows you all of the main thread activity that occurs while the page is loading. The Network section shows you all of the Network requests. You'll probably be able to visually verify that there's a bunch of JavaScript work going on during the gap that you're seeing in your screenshots.
If it's still not clear to you, post a screenshot of your Performance panel recording and I'll help you decode the results.
One of our web pages has a rendering performance issue, when the page is open, the spinner is freeze or loading very laggy, and after 6-12 seconds the page completes loading. So i'm using the Network's waterfall in chrome dev tool to diagnose the issue. But I got a few scenarios which i don't understand what happened.
In the following screenshots, all the resources for the corresponding page are loaded in a very short time, but the spinner is freeze for 6 seconds or 9 seconds, i'm not sure what is happening after the resources are loaded and before the page completes loading, maybe the spinner is in a wrong thread or gets blocked somehow? What is the means that i should use to find out the cause?
Scenario 1
Scenario 2
UPDATE
Network Screenshot
Timeline Screenshot
UPDATE
After checking the Event Log, i think the issue happens at Angular digest cycle, that endpoint response time should still be 780ms.
Thanks for the detailed info. It'd be more helpful if you can link to the page, but I understand that's often not possible. I'll just provide some general data for people in the same boat. I don't know if I'll be able to completely answer this specific question, though.
In the Scenario 1 and Scenario 2 screenshots you can see that your resources are loading in 1 or 2 seconds. That's your cue that the issue isn't related to the Network.
So while this is a page load issue, it has nothing to do with the network.
In Timeline Screenshot you can see that your CPU usage is completely maxed out from about 1900ms to beyond 16000ms. So your page is forcing the browser to do a tremendous amount of work. This is probably in the JavaScript.
To diagnose this, I'd investigate the flame chart (under Main) which you can see in Timeline Screenshot. The longer the bar, the longer that function is taking to complete. Or, if you see a small function getting called thousands of times, that could be the cause. If you can optimize those calls, then you can get your page visually loaded faster. You can click Self Time header in the UPDATE screenshot to rank the function calls according to which took the most time.
Again, I don't know how helpful this answer is for this particular question, but I thought I'd try to rephrase the problem in a different, more general way.
I have multiple proxies in a message flow.Is there a way in OSB by which I can monitor the memory utilization of each proxy ? I'm getting OOM, want to investigate which proxy is eating away all/most memory.
Thanks !
If you're getting OOME then it's either because a proxy is not freeing up all the memory it uses (so will eventually fail even with one request at a time), or you use too much memory per invocation and it dies over a certain threshold but is fine under low load. Do you know which it is?
Either way, you will want to generate a heap dump on OOME so you can investigate what's going on. It's annoying but sometimes necessary. A colleague had to do that recently to fix some issues (one problem was an SB-transport platform bug, one was a thread starvation issue due to a platform work manager bug, the last one due to a Muxer bug when used in exalogic).
If it just performs poorly under load, then you'll need to do the usual OSB optimisations, like use fewer Assign steps (but assign more variables per step), do a lot more in xquery rather than proxy steps, especially loops that don't need a service callout, since they can easily be rolled into a for loop in xquery; you know, all the standard stuff.
Sometimes the project compiles, and sometimes it fails with
"Out of memory allocating 4072 bytes after a total of 0 bytes"
If the project does compile, when it starts it immediately throws a bad access exception when attempting to access the first (allocated and retained) object, or, throws an error "unable to access memory address xxxxxxxx", where xxxxxxxx is a valid memory address.
Has anyone seen similar symptoms and knows of workarounds?
Thanks in advance.
If compilation or linking is failing with an out of memory error like that, it is likely one of two issues.
First, does your boot drive or the drive that you are building your source on have free space (they may be the same drive)? If not, then that error may arise when the VM subsystem tries to map in a file or, more likely if boot drive is full, the VM subsystem tries to allocate more drive for swap space.
Secondly, is your application just absolutely gigantic? I.e. is it the linker that is failing as it tries to assemble something really really large?
There is also the possibility that the system has some bad RAM in it. Unlikely, though, given that the symptoms are so consistent.
In any case, without more details, it is hard to give a more specific answer.
I've seen this, it is not usually an actual memory error...(of your code)
what is happening is that you have your Xcode target Build settings "optimization level" set to Fast, or faster, or fastest..
there appears to be a bug in there somewhere, set it to none, or try the Os, or O3 (i don't think fastest is effected)..
this will very likely solve someones problem that comes across this thread. for sure try "none" first... this will confirm that this is what is happening in someone's case that sees this...
i can tell that McPragma is having this problem for sure, because he/she describes changing from debug to release, and this causes it (debug is already set to none) and release is set to something else... when that is the case... for sure it is that particular build setting...
To be clear, this is for a normal iPhone application, and not a game.
I've read around the web a few times some developers mentioning that they were working hard to improve/reduce the startup time of their applications, but never with any good background information on how to do so.
So the question is simple: how can you reduce the startup of iPhone applications?
Same as any other performance issue: Use Shark and/or Instruments to identify bottlenecks in your code, and then focus on how you can speed things up there. Each tool will give you a picture of how much time was spent in what parts of your code, so the general scheme would be to run the tool while you start the app and then pore over the data to see where the performance hits occur.
At app startup time, the most likely candidates for improvement will be deferring data loading until later on when it's actually needed, variously described as "on demand" or "lazy" loading. Essentially, don't load any data at app startup unless it's actually needed right away when the app loads. In practice, lots of stuff that may be needed at some point doesn't have to be immediately available when the app starts. For example, if you have a database of N records but only one is visible at a time, don't load all N into memory at app startup time. Load whatever the current record is and then load the others when you actually need them.
James Thomson did a nice blog post documenting his efforts to make PCalc launch faster.
Of particular interest is his use of image with screenshot from last app run, to pull the same trick Default.png does, while loading rest of the app.