I am running a site with django+apache+ssl+mysql+cloudfron+s3.
However, I discovered that the ttfb time increases significantly when the first connection and caching setup time ends at some point.
(response starts after pause for about 5 seconds)
After uninstalling Apache, I tried debugging in debug mode and in Gunicorn.
There were no issues with ttfb in debug mode. However, I found out that I had the same problem when using Gunicorn.
So I looked all over apache, db, ssl, django template rendering, etc.
I don't know what's causing the bottleneck.
Which part should I look at more?
Oh, and I also found that if I send a request twice in a row, I get a response right away without any pause.
Please advise. I think my head is going to break...
edit : I tested it without any cdn or database page, but the result was the same.
Related
I have running a site serve both via https and http.
The issue only happen when access via https, steps are
open a chrome, first time to load the only single site in HTTPS, chrome stall this inital connection about 1second.
however any immediate subsequent refreshing the same page, only have zero to couples of milliseconds, can ignore.
put aside the page(don't interact with it, for a short while, may few minutes), then pick it up to refresh it, it will repeat from step #1(stall about 1 second, followed by any immediate refresh almost zero stalling)
This only happen when access the site by HTTPS, don't have this kind of issue when access by HTTP(always almost zero stalling).
Issue only seen in Chrome browser, but not safari and firefox(there is almost no stalled time), all tested in Mac OS
Would any one help to give some idea please? why the first loading introduce 1 second stalling? how to reduce that stalling time please
screenshot
sorry, this is really hard to explain the issue
I think i found the cause now, i was using a self-signed certificate for https connection, though i add it to browser exception list to trust it, it looks like chrome is being more strict on this(than others ), after switching to a trust CA signed cert. The chrome stalled time reduce to jus few millseconds for all request now, i am happy to close this question now
I have loaded up a database with about 7.5M nodes having 33+M relationships - it's about 25 GB in total. So, it's reasonably large is my point. What I am finding since loading it is that periodically my Neo4j client is just falling over, leaving nothing more than Chrome's irritating "Aw snap - something went wrong" behind. I have checked the logs and found nothing significant there. How can I begin to track down what is happening on these failed queries?
The issue might be with your Chrome environment. This Google support page on the "Aw Snap!" error may be of help.
Also, if your queries return a lot of data or take too long to respond, the browser might be running out of memory or exceeding some internal timeouts. So, make sure the queries you make via a browser are tailored accordingly.
I'm developing a WP8.1 SL app which uses background tasks (not agents!).
My task is triggered by a TimerTrigger - once every 30 minutes (which I believe is the minimum interval for Windows Phone, right?). It is doing a lot of work, and for some reason, sometimes it gets interrupted - that is, it stops in the middle of it. The way I know it's in the middle of it is because I log what's happening and the task's work is basically the same every time.
I deployed the app to my device yesterday to test a new approach, and everything was working fine - the background task was doing everything every time it was started - worked like a charm. Today my device needed a soft reset, so I did it (nothing was working, it happens from time to time since I updated to WP8.1). Since that moment, the background task gets interrupted every time, right in the middle of it, just as with the previous approach.
Any ideas what can cause this? I'm thinking it may be connected to the soft reset, because - 100% success rate before it, 0% after that.
What I've tried so far:
I'm logging errors, I have a try-catch around everything, I've subscribed to the UnobservedException event and to the task's Canceled event, and I'm logging the suspension count - none of these things help. There seem to be no errors, it's not suspended, and it's not canceled.
I'm logging the current memory usage from time to time, and it's about 16-17MB. On my device, the limit should be 30MB, so I don't think that's a problem.
I'm calling RequestAccessAsync wherever I can. I thought once should be enough, but since that soft-reset issue, i decided to put it in 1-2 other places to check if it's causing the issue. Well, it's not, or at least this didn't fix it.
What I'm not sure about:
I have no idea how to check the CPU time my task has consumed. I can't find a good/reliable way to do so. Also, I can't find any info that would explain why the task would be stopped in the middle sometimes, and other times - it would work fine.
Any ideas why my background task is sometimes stopped at the middle? I'm really having a hard time determining how to fix/improve the app and will it work at all.
Thanks.
So, I think I found what my problem was.
First of all, the background task just needed a lot of CPU time, more than the limit, and that's why it was getting killed in the middle.
The reason why it was working sometimes, was because sometimes the device on which I was testing treated the app as being in debug (or with attached debugger). In this case the restriction on CPU time is removed.
So, even if I uninstall the app and rebuild it in Release and redeploy, and start it without the debugger attached, the device was NOT enforcing the constraints. That only happens, if I have started the app with the debugger at least once (or maybe the first time) after it's deployed. Restarting the device (just power off and then turn on) fixes this.
While I was testing, using the same build of an app, its background task ran for 40 MINUTES on one device, and just 3-4 seconds on another. After I restarted the first device, the background task started behaving normally (running for just a few seconds).
So, if you want to test your background task for the CPU constraint:
You must be testing on a device, not on the Emulator.
Uninstall the app, if it's installed.
Restart the device.
Deploy a Release build of the app.
Run the app, so that it can register the background task, and then close it.
Wait for the background task to be invoked. (You could add a trigger that can be forced, like TimeZoneChanged or UserPresent, so that you could quickly test it.)
P.S. This may not be the perfect answer, but these are my observations, and they helped me solve my problem. This by far is the best method I have found for testing the CPU time, and it's far from perfect. So, if anyone has better ideas, please share them.
A web page is not loading/hanging. How will you debug it?
I have been asked this question couple of times during my telephonic interviews. But I don't know the perfect answer.
I had given answers such as checking if the web-app is deployed properly, the internet itself might be slow, the JSP might have some errors, checking logs for any such detail, etc. But interviewer kept asking "These are all good checks, but what if all of these are fine, what else might be wrong?"
Also, it is not a JavaScript specific question. I can debug the JS/jQuery code using debugger, or following the console.log(). But how will you debug a plain JSP page?
Can any web-application gurus at SO help?
Once you know that you can't simply get to your site in the expected way (what I call the Hail Mary Test), then you need to start from the inside out.
Because of the multiple failure points a website can have, I always create a command line environment that allows me to test the framework & DB operation independently of the web server, firewall settings, etc. This can take some fiddling depending on what you are using, but I've done this successfully with Django, WordPress, Drupal, etc.
Once I know the app itself is working, I connect with a command line client (e.g. links) to see if a client coming from localhost works as expected. This confirms that the server itself is working (at least partially). Then I test from another host on the same LAN. More than once I've seen localhost work and LAN access not work, and the problem is almost always server configuration or firewall configuration.
If all of that works, but you still can't get to your site from the internet, then it is a networking / firewall setting somewhere further up the food chain. Try to find a host that is one step farther up from where you last succeeded and test that. Lather, rinse, repeat.
This is an odd freeze. When I switch from source view to design view for an HTML or ASPX file, the client area freezes, but I can still click on other tabs and menus.
What am I missing here? Really don't feel like reinstalling VS2008.
I had the same problem, and found one resolution.
In VS 2008, In a page that was using a master page, the either frequency while working in source view or switching to design view, IDE would freeze for 10-20 seconds.
In my master template, I had references to the Google hosted JQuery, Jquery UI, and one or two more scripts off site. These were placed directly in my master page's head section.
I downloaded the js and then by deleting any offsite references, my IDE would be smooth again in both design and source mode.
I also discovered I could put the scripts inside my ToolkitScriptManager (I'm using AjaxControlToolkit) and added the Mode="Release", and could place the http://www.google.com references for the scripts. The IDE is still working fine for me.
This is often due to the Design mode downloading external resources that are timing out. As #JonK mentioned, for him it was jQuery references. I have seen this when the ConnectionString was set to production databases that could not be accessed on my development machine, even though I wasn't debugging (running) the site only editing code, it would still try to connect and because it couldn't it would stall waiting for the timeout.
VS2008 is mostly single-threaded for UI operations like this, so if it is downloading a slow or non-existent network path it hangs like this.
VS2008 can make all kinds of network requests, so these two examples may not solve it for you. The best way I have found to diagnose the problem is to use the Microsoft tool Process Monitor, filter by the Process webdev.exe, and watch for I/O requests that are long running and/or throwing errors. In my case, I could find the place that was having a problem because there would be a 20 second gap in between the hundreds of I/O entries in Process Monitor. Then, just back-tracked from when that gap began and I eventually found the request that was causing the problem.
This may not be possible for you, but if you can, an upgrade to VS2010 would help; it does a much better job of running process on multiple threads in more places so you don't have to worry about this as much.
Have you tried restarting your computer and then reopening your project?