I'm looking through my newrelic analysis and I'm seeing in almost every case over 60%-70% of my time is spent inside MixedGrailsControllerHelper.executeAction(). I've checked the traces and it's spent in executeAction() after the controller has already handled the action. So it's after invokeAction() has been called, but I can't find any locks that might be holding it up. All the time seems to be spent in executeAction(). No other methods it calls show any significant time spent in them. I am using the MongoDB gorm plugin usually returning JSON data.
So what's the problem?
Related
Hello and thanks for your time. If you stumble upon this I'm having a bit of issue and it requires some knowledge with Firebase / Swift and Swift's mapkit. So what I'm trying to do is create an expiring annotation. A user puts a pin on a map and after some amount of time (say 3 hours) the annotation disappears.
I've read about one thing where you can use NSTImer, but the issue is that if the phone is asleep or powered off it might have issues with NSTimer. Instead, I was thinking of using Firebase to save the annotation and use the time stamp to show when the point should expire. I saw another stack overflow post regarding this which involved if / else statements to check when a certain time has passed and to bring remove the data after the time.
The post never explained how to actually do that, and also I'm not actually sure how to create an observer that will easily check if a certain time has passed based on the timestamp. If anyone could create some code or point me in the right direction, would really appreciate it. Thank you!
I follow a book called Eclipse Plugin Development by Example: Beginner's Guide and all examples are hosted at github. However, I can't successfully run SWTBot example.
The first time it takes a very long time to run, but in the end it would pass all test cases.
However when I try to run the same code second time, it only testUI() will pass, the other three will have org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: The widget was null.
Somewhere in the book is said
If one (shell) is not currently visible, it polls (every 500 milliseconds by default) until one is found or the default timeout period (5 seconds) ends when a WidgetNotFoundException is thrown
But I don't see why the first time all test cases will pass but not the second time.
but I have not idea why the first time will work but second time won't.
I also report this at github issue but so far no one response.
did you interfere with your desktop while the test was running? I found this can (!) cause problems with SWTBot.
Also, WidgetNotFound is an exception you'll be seeing a lot when using this framework. Sometimes it might be due to bugs, sometimes to unusual underlying UI code. It should be reproducible in those cases, though.
My page load times have been wildly fluctuating, and sometimes it takes so long to serve a page that I get a server timed out error, even during relatively quiet times of day for my site.
I have been using pingdom to check page load times and to try and find where the problem lies.
It seems when a page loads normally (in approx 6 seconds), there is a 1.63 second 'Wait' Time for the main html file, before it starts receiving the file.
You can see this here:
http://tools.pingdom.com/fpt/#!/GEoqJlVdZ/http://www.bluedogposters.com.au/shopdisplayproducts.asp?id=11&cat=Movies
But 2 minutes later, when the same page is taking 17 seconds to load, there is an 11.7 second Wait Time before starting to receive this same html file.
You can see an example here:
http://tools.pingdom.com/fpt/#!/he2L5Jhgz/http://www.bluedogposters.com.au/shopdisplayproducts.asp?id=11&cat=Movies
Do you know what can cause this difference in the Wait times because it seems this is the reason my site has been so slow recently.
Accoring to the Waterfall chart, there is nothing else happening, so why the Wait?
Is it more likely to be a code or server issue?
I found some useful info here How to reduce server "Wait" time?
Any advice is much appreciated.
You need a tool that can dig into the backend performance, something like New Relic might help - they do a free month trial.
There's obviously some variation in performance going on but whether it's related to load or other factors is really hard to discern without digging deeply.
You should try new relic anyway, it will still give you a good answer even on an ASP classic site. I have used it on windows servers before to figure out why an app was running slow.
I am new to objective-c/cocoa programming. I am making an application which is to constantly sync with a server and keep its view updated.
Now in a nutshell, heres what I thought of: Initiate an NSTimer to trigger every second or two, contact the server, if there is a change, update the view. Is this a good way of doing it?
I have read elsewhere that you can have a thread running in the background which monitors the changes and updates the view. I never worked with threads before and I know they can be quite troublesome and you need a good amount of experience with memory management to get most out of them.
I have one month to get this application done. What do you guys recommend? Just use an NSTimer and do it the way I though of...or learn multithreading and get it done that way (but keep in mind my time frame).
Thanks!
I think using separate thread in this case would be too much. You need to use threads when there is some task that runs for considerable amount of time and can freeze your app for some time.
In your case do this:
Create timer and call some method (say update) every N seconds.
in update send asynchronous request to server and check for any changes.
download data using NSURLConnection delegate and parse. Note: if there is probability that you can receive a huge amount of data from server and its processing can take much time (for example parsing of 2Mb of XML data) then you do need to perform that is a separate thread.
update all listeners (appropriate view controllers for example) with processed data.
continue polling using timer.
Think about requirements. The most relevant questions, IMO, are :
does your application have to get new data while running in background?
does your application need to be responsive, that is, not sluggish when it's fetching new data?
I guess the answer to the first question is probably no. If you are updating a view depending on the data, it's only required to fetch the data when the view is visible. You cannot guarantee always fetching data in background anyway, because iOS can always just kill your application. Anyway, in your application's perspective, multithreading is not relevant to this question. Because either you are updating only in foreground or also in background, your application need no more than one thread.
Multithreading is relevant rather to the second question. If your application has to remain responsive while fetching data, then you will have to run your fetching code on a detached thread. What's more important here is, the update on the user interface (like views) must happen on the main thread again.
Learning multithreading in general is something indeed, but iOS SDK provides a lot of help. Learning how to use operation queue (I guess that's the easiest to learn, but not necessarily the easiest to use) wouldn't take many days. In a month period, you can definitely finish the job.
Again, however, think clearly why you would need multithreading.
I have been working at entering and sustaining periods of flow while working, and while researching the concept I came across this site which addressed the idea of sustaining flow in short bursts. The technique specifies that one sets a timer for 48 minutes in which they focus purely on their work, and when the timer runs out they spend 12 minutes doing whatever.
However, in the paragraph directly above that statement is a quote from Peopleware saying that it takes at least 15 uninterrupted minutes to enter a state of flow.
When reading that point, the 48 minute technique seemed counter-intuitive, since every 48 minutes you are "breaking" your flow, and once you start up again you have to spend 15 minutes going back into it, so you really only get (at a maximum) 33 minutes of "flow time". Obviously these quantities aren't necessarily rigid, but you get the idea.
My question is to those who have tried a timing technique similar to the one described. As I see it, the only justification for this technique is that it possibly reduces the amount of time it takes to re-enter that period of flow. Can anyone who has used this technique provide some clarification?
I've tried the Pomodoro Technique for a week or so. I didn't focus too much on the details of maintaining check lists of completed and interrupted sprints, but rather I started the day with the tasks that I wanted to do on that day, and went through them as best as I could using the 25-minute sprints and five-minute breaks.
The Pomodoro Technique suggests to use the breaks to relax, stretch your legs, grab a coffee, etc. I've noticed that activities like those that don't require a total focus shift and can be done on automatic don't break the flow, but rather helped me cleanse my mind and refocus my attention. It's as if you're allowing yourself to step away from the trees to survey the forest for a bit before diving back in.
I dropped Pomodoro after that short trial period because I found that in my case I got the most benefit from simply sitting down in the morning and writing down what I wanted to do on that day. Once the decision is made and the work is started I found that I fall into a natural rhythm of sorts. I work until I'm bored, frustrated, or interrupted, then I take a break and continue. I didn't find that time boxing my sprints added much value.
YMMV, but it's worth at least giving it a try.
A timer would be terrible for me, because it might go off and interrupt my train of thought at a critical moment.
For me, maximizing flow would begin by (1) first preventing forthcoming distractions (ie, making sure phone calls and other interrupts are disabled and that anything scheduled, like a meeting, is sufficiently far off there's no possibility of running into it), then (2) working on the problem at hand as long as I can, but all the while trying to recognize when I'm not making progress.
If I think I'm making progress, no matter how slowly, I just keep going as long as I can. But if I appear to be stuck or going in circles, I stop, and do something else instead, even if that something else is starting on a different problem. I let my subconscious dwell on the original problem, and once I have a feeling I feel fresh or curious enough to restart again, I do.