I'm running a learning app written in react. The average session duration is 15 Minutes. Recently some Safari users (mobile and desktop) reported that the apps feels laggy after a fair bit of use (answering questions).
I monitored memory used in safari and answered some questions in the app. After a while, there is a spike in page memory usage (a ridiculous amount). A minute later page memory goes up again and stays there. From there on the app feels quite laggy.
The vast majority of javascript events are Animation Frame Requested and Animation Frame Fired events. That's why I thought that animations may be the culprit. I'm using react-spring and found this open issue.
I can only run safari in a docker container on my Linux machine, as I don't have an apple device (https://github.com/sickcodes/Docker-OSX). Maybe that is the reason for the weirdly high amount of page memory usage (I wish I had that amount of RAM).
I'm kind of stuck and don't know how to proceed. Did anyone experience similar issues with react, react-spring and safari?
Related
https://imgur.com/a/NtVWlcj
I get tons of such errors in a (pretty big) react app scaffolded with cra, when scrolling, when loading the page initially, when receiveing payloads from web sockets, some are blocking the app for as much as 15000ms, what could be causing this?
I just don't have any clue how to debug this, the chrome profiler seems like a start, but I would like any insight that could ease my suffering, cause right now I am about 15 hours deep into debugging.
We have a React app. Lately we are experiencing an issue which only appears in "developer" mode. Two of the modules causes the app to become unresponsive for several seconds. The cpu works hard and memory usage spikes. If I change the settings in Webpack to "production" it works smoothly.
I have tried doing performance recordings in devtools, but I am unable to interpret anything useful from it.
I have tried making the Webpack configuration as simple as possible without any signs of improvement.
I am not posting any code since I don't really know where the issue(s) might be. But maybe someone can give some ideas about where to look or how we can pinpoint the issue.
Thanks to #noitse for pinpointing the problem. I removed "redux-immutable-state-invariant" and that fixed the problem.
I have published an app built with React Native. Currently it's iOS only, but eventually may be released for Android as well. I'd like a cross-platform solution to remotely assist customers that run into bugs, crashes or any unexpected behavior. While the app could continuously log everything to a server, I've found that that's not very helpful since customers usually have very specific points in time that they need help with. Sifting through continuous logs is time consuming and generally a waste of resources.
My hope is to give the user the ability to press a button to send the stack trace, the last N minutes worth of logs, etc directly to me. This wouldn't work in the case of a hard crash of course. The vast majority of the time the app is functional when there's something they need help with.
A pie-in-the-sky idea would be to let the user share their screen with me.
Found this related question but it doesn't fully encompass what I'm trying to accomplish:
Release mode diagnostics in React Native
BugSnag looks promising. It's a paid service.
https://www.bugsnag.com/platforms/react-native-error-reporting
I tried BugSnag and a few other services. In the end, Sentry has the most reliable and simplest RN library. It's also free for the Developer plan (5k errors per month is plenty enough for us, and supports multiple apps).
https://sentry.io/pricing/
Back Ground fetch functionality with codenameone 1.5 release is working fine in Android devices and its not working in iOS devices. I have added "ios.background_modes=fetch" property also. Can you please help me on this.
On iOS you'll have less control over background fetch than you do on Android. The OS decides when it will allow you to perform a background fetch, and this depends on many factors. On Android it works more like clock-work. You specify the preferred interval, and it does an update on that interval (min 60 seconds I think). On iOS it could be 10 minutes, or it could decide to disallow you altogether if your app has been taking too long on previous fetches. Etc...
So given that information, what tests have you run to conclude that it is not working?
I have a site that I deployed to Heroku. It's a low traffic site so if nobody goes to it for a couple hours and then go to it, it will take about 5-10 seconds to load. Any other requests to other pages on that site loads up fine quickly. If I exit the site entirely and check back in a few minutes later, it also comes back up quickly.
It's only if it's left idle for a couple hours that the spin up time is noticeable. Does anyone else have this issue? If so, how did you fix it.
Also while on the topic, does the same thing happen with Google App Engine? I'm currently just trying out these app hosting platforms so I don't really have any preference for technologies/languages.
Quickest way to "fix" this problem is to make sure your site is always up. Set up a pingdom account (http://www.pingdom.com/) which will ping your site every few minutes just to keep it alive.
I have a special route myapp.com/keep_alive which does nothing except hit the rails stack without caching.
Hopefully this helps!
Do you happen to be hosting it with the 'free plan', ie. only with 1 dyno?
If so, what you experience might be a Dyno Idling. You can increase the number of the dynos so that your app is 'always-on'
From what I understand Heroku makes public this behaviour.
For free site hosting, one heroku 'Dyno' is dedictaed to your site, if the dyno is inactive for a period of time then the resource will be redirected elsewhere, when you try access the site after this time the system has to go request a Dyno back.
You can prevent this by paying for extra dyno's which will stick with your site or you can visit the site on a regular basis yourself with a automated script.
The best thing you can do to decrease this time is to minimize the size of your slug. This includes steps like deleting any PSD or AI image assets, removing PDFs, and minimizing your gem set. For more information see: http://devcenter.heroku.com/articles/slug-size. As a reference, my applications can usually spin up in under around one second.
If you don't want to pay for Pingdom, you can try the open source alternative: Pinger
https://github.com/austinthecoder/pinger