Apologies if this sounds strange, but I'll try to describe what's happening as best I can. We were provided a small service that provides a single form UI that we capture the results of via an event. We've integrated this into two applications and we're seeing some different behavior when we load the UI in a modal window via an iframe. When integrated into one UI it loads pretty quickly. However, in the other UI it takes several seconds to load. Now, the only difference I could find is that setTimeout is being triggered sever seconds after the model is created. I discovered this using the Firefox development tools in the Performance tab.
Now, I believe that the UI for this form is built in a non-recent version of Angular (AngularJS?) based on some Google searches using strings that I could see in a minimized polyfill.xxxx.js file. However, I can't understand the code that was minimized and I have no version information to help me get back to a version that I can try to read and understand.
I did testing using the Performance API before the iframe is created in case the issue was something in my code, but the tested code is finished in < 100ms, so that didn't appear to be the issue. It's not a network issue as the requests occur pretty quickly. Also, both applications are referencing the same instance, so the only difference is the app that it's integrated into.
So, my primary question is what could be causing Angular (AngularJs) to set a timeout on page load? My secondary question is what advice is there for trying to debug this? I don't use Angular at all, so I'm not even sure where to begin outside of what I've already tried. The only custom app code I see looks to be Angular configuration/properties, so no JavaScript to debug.
The best advice with setTimeout() in such a situation is to not use any setTimeout().
I ran into same situation not only angular most of the framework treat setTimeout() a bit differently.
What I mean setTimeout() in a plain JS app and angularJS app and Angular App will differ the time interval.
setTimeout() is set to execute after a certain time, but that's is not guaranteed by the thread.
Some time angular completing change detection and watcher life cycle, all mingle with setTimeout() and you will end up with strange behavior.
So better not to use that unless you are sure it's not gonna mingle with other running things.
Please share the code snippet if possible
I've got a Node application which listens to a websocket data feed and acts on it by talking to another API. I'm now running into performance problems. Most of the time things are quiet, with the CPU at about 2-5%, but sometimes (about 3 times per 24 hours) the websocket feed we receive suddenly goes wild for a couple minutes with a lot of data. This makes the application do a lot of calculations, causing the CPU to spike to 100%, and causing all sorts of other trouble. I cannot predict these busy times and I can't really replicate it in a testing setup either. For these reasons I'm having a hard time profiling these spikes.
I'm not a Node guru, but I tried profiling this application using the node --prof flag, followed by the --prof-process flag (on a 3GB isolate-0x321c640-v8.log file). This is ok-ish, but the problem is that if I do that I profile the whole time it ran, instead of the high-traffic part of the time it ran.
I checked out the isolate-0x321c640-v8.log file (see excerpt below) hoping for some sort of timestamp on every line so that I could isolate the time I'm interested in, but I can't find anything like that in there.
tick,0x8ad1f58c24,26726463388,0,0x3fedc8b5859026ea,0,0x8ad76332f8,0x8ad7619f68,0x84113fbe10b,0x8ad12fd54f,0x8ad734f837,0x8ad735192b,0x8ad59c2598,0x8ad59c9765
tick,0x8ad1f6d472,26726464443,0,0x3ff76afe21366278,0,0x8ad7633873,0x8ad7619f68,0x84113fbe10b,0x8ad12fd54f,0x8ad734f837,0x8ad735192b,0x8ad59c2598,0x8ad59c9765
tick,0x8ad1206bd5,26726465499,0,0x8ad1f58c40,0,0x8ad76332f8,0x8ad7619f68,0x84113fbe10b,0x8ad12fd54f,0x8ad734f837,0x8ad735192b,0x8ad59c2598,0x8ad59c9765
tick,0x8ad1f6d472,26726466552,0,0x400040d9bba74cfb,0,0x8ad763377d,0x8ad7619f68,0x84113fbe10b,0x8ad12fd54f,0x8ad734f837,0x8ad735192b,0x8ad59c2598,0x8ad59c9765
tick,0x8ad1f591fa,26726467615,0,0x3fe94cccccccccce,0,0x8ad7626638,0x8ad761c1d9,0x84113fbe10b,0x8ad12fd54f,0x8ad734f837,0x8ad735192b,0x8ad59c2598,0x8ad59c9765
tick,0x8ad1f6d472,26726468680,0,0x7ffcc894f270,0,0x8ad1f59054,0x8ad7626638,0x8ad761c1d9,0x84113fbe10b,0x8ad12fd54f,0x8ad734f837,0x8ad735192b,0x8ad59c2598,0x8ad59c9765
tick,0x8ad1f6d41c,26726469744,0,0x329ab68,0,0x8ad7626cc9,0x8ad761c1d9,0x84113fbe10b,0x8ad12fd54f,0x8ad734f837,0x8ad735192b,0x8ad59c2598,0x8ad59c9765
Is there a good way to profile these specific times during runtime?
An easy answer for your problem I can't suggest but I prepared the following roadmap to learn more on the node.js tools and techniques for profiling and optimization that can be helpful for you.
Netflix JavaScript Talks - Debugging Node.js in Production - They have an interesting ideea of storing a complete processor and memory dump in the moment of crushing, this one can be useful for you I think.
0x - a flame graph profiling tool very helpful understanding how the cpu behaves:
A little article on how to use 0x Squeeze node.js performance with flame graphs
clinic - a super interesting tool of profiling and performance auditing of your node.js application based on async-hooks
I would instead of hunting down and hoping to "catch" the time frame the issue is occurring to try to simulate it via stress testing your app.
First setup the tools you need to monitor what is happening. Anything you find readable and helpful should be used here. For example you can use 0x, v8-profiler, heap-profile etc. The key here is to try those and see what is the most readable and easy to follow since some of them have so much data that you get lost in it.
Then get a sample of the data coming in and use libs like Artilery etc to make tons of requests and see what gives. I mean between the flame graphs of 0x and all the data from the other debugging libs you should have enough information to reach a conclusion.
If simulating this is not possible then you can simply run any of the profiling libs on a setInterval and write to the disk the data. For example heap-profile is used with this approach:
const heapProfile = require('heap-profile');
heapProfile.start();
// Write a snapshot to disk every hour
setInterval(() => {
heapProfile.write((err, filename) => {
console.log(`heapProfile.write. err: ${err} filename: ${filename}`);
});
}, 60 * 60 * 1000).unref();
So every hour you would have a data file to look into.
If your node crashes then you could write the dump in the process.catch:
process.on('uncaughtException', function (err) {
heapProfile.write(...)
});
Hope this helps.
Note: process.on('uncaughtException' ... is still under debate as if it is the correct approach to handle the crashes of node from my understanding vs the use of domains.
Have you thought about integrating a 3rd party Application Performance Management (APM) like NewRelic, AppDynamics , Atatus or Keymetrics?
They all have their strengths and weaknesses and different pricing plans. But they all share the goal to help developers to better understand their applications to pin down problems like yours.
Some of them have a free trial. That might be a good start to see if it fits your needs or not.
I'm working on an Ionic 3 application (for Android only). Everything works great, except that the startup time of my App is a bit long (nothing excessive, but like 4~5 seconds) and some users are complaining about it. I'm pretty sure it is possible to do better as I have other Ionic apps that rarely take more than 2 seconds to launch. (I'm hiding the splash screen myself, once platform.ready() is called)
Now, I'm already using some of the techniques I often read about : I'm calling enableProdMode() and compiling with the --prod flag. I also added ProGuard (wasn't meant to speed things up but can still reduce number of Java classes so why not), and I tried using Crosswalk but it resulted in worse performances.
So I'm looking for the next step : I'm trying to diagnose what happens during the splash screen, and what can I do better. But I can't find a way to get numbers or stats about what takes long and where is the problem. Instinctively, I'd say that reducing the number of Angular classes by refactoring some views and reducing the number of native plugins in my code could help, but I have found no evidence of it.
So my two questions are :
Is there a way to see what takes time during the splash screen, before platform.ready is called ?
Are there general tips such as reducing the number of plugins or classes to improve startup time ?
You need to use the Lazy Loading. So you will have not all the pages and plugins loaded at startup. The Lazy Loading allow you to load just the page and plugins if it's called.
Here is some links to help you to solve the problem :
http://blog.ionic.io/ionic-and-lazy-loading-pt-1/
http://blog.ionic.io/ionic-and-lazy-loading-pt-2/
Hope it helps.
This is more of a concept question as I am trying to learn more about long-polling, in Javascript/jQuery specifically. I have a web app where I am long-polling (websockets are not an option right now) to a json file. I have run some tests and after leaving the app open for some time, it starts to slow down and later seems to start getting stuck. Using Chrome, I've checked the developer tools and the memory starts going through the roof, as with the listeners (>5000) around 1 1/2 hours of up time. I've searched and searched but can't find forums that pinpoint this problem and solution. In my code, I am using setInterval every 30 seconds. What do I need to do in order to keep the memory and listeners count low, and make sure the app does not overload and get slow? The function of the app requires it to stay up for long periods of time.
Thank you for your help.
We found ourselves working in a webpage that manages to work with >20k users in real time.
We worked so hard to optimize the back-end system but we now need to make optimizations in the front end.
The first thing I came up with was use some tool of monitoring the load time of the JS files.
But we don't really need to get the times of loading javascript, what we really need is know what parts of our javascript code are taking more time to finish.
Now we are using new relic to track our site, and know what server-side scripts need to be optimized.
But I can't see any metrics about front-end codes or witch files need to be optimized.
There's any tool out there that may help us with this?
The best way to test your javascript speed cross browsers is to write your own function.
wrap whatever code you want to test into a function and run that function as many times as you possibly can within 1 second counting the iterations. run that test at least five times because you will get a different result every time and then find the average number of iterations. I also suggest using chrome since it is about 4 times faster than any other browser out there when it comes to javascript performance. Test all your code and optimize it for your browser and the improvement will impact your users experience as well.
I have my own speedTest obj that I wrote which you can view at my website here http://www.deckersdesign.com/source.php which is under construction. FYI this obj finds the median of iterations not the average.