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?
Related
I would know what are the queries that make slow my Joomla website. I know that there is the possibility to log all the slow query.
Unfortunately, I have only the access to the ftp where the website is hosted. Can I see this log also in ftp? Or I have to access to the server?
There are other way to see this log?
Thanks
As Rinos already said, there can be different reasons for a slow Joomla-Site.
If you cannot find a db-query being responsible for that check the network-tab in your developer-tools for resources that slow down your site.
One possible reason can be, that you are loading http-resources via https (so if you have hardcoded integrations of images, script-files etc. that will load via http while your site running in https, the developer tools will bark at you something about 'mixed content' ;) )
Depending on your Joomla there also might be some Modules/Components/Plugins that are not well designed... maybe deactivating them by chance and refreshing (yep, might be lot of work) will give you a hint. BUT: Please be careful, since there are some Plugins like the authentication-plugins that are needed and if you deactivate them you might "lock" yourself out. Normally core components and plugins shouldn't be responsible for that at all.
If you have a look at the queries from the debug-console, there are some queries that perform a full-table-scan. Maybe you'll find one among these that are performance-hungry.
If not so, please check your global configuration in the Joomla Backend under System -> Global Configuration and try check the following things:
Is caching enabled?
What kind of caching do you use?
Under the Server-Tab check for gzip-compression of your page
if you force https, do you have any http-resources on your site (like mentioned above)
Some of the possibilities here might help you to gain some performance, but if you still have performance problems, my next look would be the server-config.
There are still other things you might give a "heads up":
What PHP-Version are you running? PHP 7.x brings a remarkable performance-boost
Have a look at your php.ini file. What about your memory-limit and other options (have a look here for the technical requirements that are recommended: https://downloads.joomla.org/technical-requirements
Back on your site, are there any javascript-errors (the developer-tools of your browser will tell you)
Well, these are several possibilities you might pay some attention... Performance-Issues can have many reasons but hopefully some of the above said things might lead you on the right track ;)
regards
You can active debug in joomla from Configuration system, then you can see at the end of pages in "live site" all query performed with time and memory used, and much more you can help for understand what is slowing down your site
I have developed my website with asp.net and c# with MySql as back end. But even after optimizing css, Javascript and Images still takes time to load my website www.cloudionpro.com.
Please help do I need to change something in my coding or its a mysql server issue?
I loaded your site in Chrome and is reported the HTML of the page itself loaded in 93ms, of which 51ms was spent waiting for the HTML to be generated. 51ms is acceptable, but probably could be improved: it's likely you're making a lot of MySQL database calls that could be optimized (by paralleising them, or executing a query-batch).
Chrome reports the Google Maps API you're using failed to load, caused by scripting errors, which is also causing problems, open your browser's console for details of those. It looks like your site has a dependency on jQuery but your site never loads it.
I've developed a Chrome Extension that cycles through approximately 1500-2000 pages to collect information from a website and push it onto my own server. I use a Chrome extension, as given the requirements it's much easier to configure than making and parsing from the server side.
The extension is used only for internal purposes and we trigger this job using the chrome.alarm API to run at 3:00 am every day. This alarm when triggers pops open a new tab and runs through the 1500-2000 pages. The problem is when we check in the morning we see the SNAP dialogue after the extension has cycled through about 1500 pages (approx 3/4). I'm presuming this is due to the memory demand placed on Chrome to maintain such an unusually large history?
My question is, what would be the best way to mitigate this? Presumably killing the tab and reopening (after x number of pages) would work but that would slow down the feed and require quite a bit of code re-factoring. Is there any way you can force Chrome to dump the history and would doing so free memory in the immediate session?
Just to add some context, I am running this on a extra small VM with only 1 GB of memory. I appreciate I could upgrade the VM but that really just defers the problem.
It's hard to make a solid recommendation without seeing your code, but here's something a bit more general:
The problem is likely the information that is being collected. It continues to build up in memory until you run out. You might consider saving the results to local storage using Chrome's unlimited storage capability. In manifest file:
"permissions": [
"unlimitedStorage"
],
What I would probably do is save to local storage after every page, or something similar, and then reset the array (or whatever you're using).
UPDATE
If indeed history is the problem, you could consider deleting it on the fly. This function will delete entries for a specific URL:
https://developer.chrome.com/extensions/history.html#method-deleteUrl
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.
As far as I know, at the current moment, late 2011 the max-connections-per-server limit remains 6. Please correct me if I am wrong. This is bad that we cannot fix this easily as in Firefox. As far as I know this value is hardcoded.
One of the solutions is to download the Chromium's sources and rebuild them. Is there a more easy solution?
Is there any tricky way to hack this without creating a dozen of mirror-domains?
Why I'm asking the question: My task is to create a html-javascript slideshow that will run inside a fullscreened browser, and a huge monitor is hanging on the wall. The javascript is really complicated, it preloads photos and makes a lot of ajax calls to my web services. If WIFI connection is slow, if 6 photos are loading, the AJAX calls fail, the application runs bad. I want a fast solution based, on http or browser or ubuntu tweak something else, because rebuilding the javascript app will take days.
Offtopic: do you know any other things that can be tweaked in my concrete situation?
IE is even worse with 2 connection per domain limit. But I wouldn't rely on fixing client browsers. Even if you have control over them, browsers like chrome will auto update and a future release might behave differently than you expect. I'd focus on solving the problem within your system design.
Your choices are to:
Load the images in sequence so that only 1 or 2 XHR calls are active at a time (use the success event from the previous image to check if there are more images to download and start the next request).
Use sub-domains like serverA.myphotoserver.com and serverB.myphotoserver.com. Each sub domain will have its own pool for connection limits. This means you could have 2 requests going to 5 different sub-domains if you wanted to. The downfall is that the photos will be cached according to these sub-domains. BTW, these don't need to be "mirror" domains, you can just make additional DNS pointers to the exact same website/server. This means you don't have the headache of administrating many servers, just one server with many DNS records.
I don't know that you can do it in Chrome outside of Windows -- some Googling shows that Chrome (and therefore possibly Chromium) might respond well to a certain registry hack.
However, if you're just looking for a simple solution without modifying your code base, have you considered Firefox? In the about:config you can search for "network.http.max" and there are a few values in there that are definitely worth looking at.
Also, for a device that will not be moving (i.e. it is mounted in a fixed location) you should consider not using Wi-Fi (even a Home-Plug would be a step up as far as latency / stability / dropped connections go).
BTW, HTTP 1/1 specification (RFC2616) suggests no more than 2 connections per server.
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
There doesn't appear to be an external way to hack the behaviour of the executables.
You could modify the Chrome(ium) executables as this information is obviously compiled in. That approach brings a lot of problems with support and automatic upgrades so you probably want to avoid doing that. You also need to understand how to make the changes to the binaries which is not something most people can pick up in a few days.
If you compile your own browser you are creating a support issue for yourself as you are stuck with a specific revision. If you want to get new features and bug fixes you will have to recompile. All of this involves tracking Chrome development for bugs and build breakages - not something that a web developer should have to do.
I'd follow #BenSwayne's advice for now, but it might be worth thinking about doing some of the work outside of the client (the web browser) and putting it in a background process running on the same or different machines. This process can handle many more connections and you are just responsible for getting the data back from it. Since it is local(ish) you'll get results back quickly even with minimal connections.