I have several user controls loading up in a template in an Umbraco website, and basically, there are problems with a certain template loading very slow initially (after that it loads fast). But the initial page load can take up to 5 minutes to load and the CPU on the localhost goes up very high during this. This is only on 1 specific template. I have tried a stack trace and still not able to output anything useful. Is there something in code where I can set breakpoints somehow in the code itself to see where it is spending most of it's time on the server before the page gets rendered to the client side?
I need to understand, that when the page is not cached, why it takes up to 5 minutes to render the page. How can I find this out in code? Preferably with breakpoints or some ASP.NET plugin that will help me understand why this is happening?
I have determined that it is not related to IIS 7.5, and it is NOT a System Hang! It is something in the code that is causing this.
Glimpse should provide...a glimpse into what is causing the slow initial load without requiring you to write profiling code just to troubleshoot the issue. It is certainly worth checking out before doing the latter at least.
Also, StackExchange's MiniProfiler looks promising and may be worth checking out.
The fallback option of instrumenting your code to time its execution will be more work and require code changes of course; but if that proves to be your best option to understand the slow load times, so be it.
Related
I created my WebSite on Asp.Net Core and I hosted it on SmarterAsp.Net
http://greensaucegames.com/
I don't know what the problem is, if it was something I did, or if the hosting server is slow.
But the site is very slow, sometimes it doesn't even open the page I just clicked, the one from nowhere it reloads.
Does anyone know a way for me to try to diagnose what may be making it so slow and intermittent? How do you do it? Or some advice on how can I improve the speed?
Are Razor Pages really slow? Should I use something else?
I do use Blazor for the Admin Area, can this be interfering with the rest of the site?
Because your hosting subscription plan is very cheap. Use a high resources server will see acceptable performance.
I went to SmarterAsp.Net's homepage, and even IT loaded very slowly. I clicked on their "Why Us" link and watched in horror as a medium-sized image scanned in over about 15 seconds. The words "total garbage" immediately came to mind.
Then I tried to open one of your asset images in a new browser tab. Just the image itself, which is not a large one, took like 20 seconds to load.
Conclusion-- 100% chance that the shared hosting you have is the problem.
When I first put up a real business website, it took me quite a while to realize that shared hosting is a no-go. Even if the site works great at first, new users will come to that host, and soon enough you'll be stuck in glue again. Upgrading to "premium" packages and so on didn't help either.
Then I opened up my wallet, shelled out for an Azure Windows Server VM, and added a couple years to my life thanks to my immediate and total lack of stress. It's nice when everything just works.
There are many factors that make your site working slowly. For example
How effective is your code
How effective is your SQL query
Have you optimized your image
If you believe that you have optimized your site, then you need to check your external factors like your hosting provider. You may need to upgrade your plan to higher plan to get more stable server. Their hosting service is cheap but it might impact to your webiste performance. To test it, you can upgrade to higher plan. If your site still working slowly, you may need to find other hosting provider. I personally use Asphostportal.com and I can recommend them if you need .NET Core hosting.
I am having a rather time-consuming issue with the Sitecore CMS.
Is it possible to shorten the time it takes for the application pool to recycle every time a change is made in the bin folder or web.config?
It takes the server 2 to 5 minutes to respond right after a change.
Any ideas?
There is one article from alex shyba from sitecore here on Reducing Sitecore Startup time
Summary of article is
In machine.config: disable process to check assembly signed
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
Disable performance counters in Sitecore web.config
<setting name="Counters.Enabled" value="false" />
There are plenty of articles on the improving sitecore performance I have listed few links below:
Sitecore SDN - Optimizing Performance in Sitecore
Sitecore Slides on performance improvements - download pdf
Analyzing and identifying the slow causing culprit - Sitecore Startup basics
He needs to restart the application pool in order to load the new dll's in.
You could try and minimize the things you do at startup(but i'm guessing it's mostly sitecore stuff which you can't influence) so the best suggestion i can give is to have 2 webservers with a content switch.
You would run your application on 2 servers and the content switch decides which server handles which request(be carefull with session and statics because each server will know nothing of the other).
If at some point you need to release a new version you just instruct your content switch to direct all trafic to webserver A. You then deploy to webserver B, open the website via a direct url that doesn't pass the content switch and make sure it's working properly + warmed up.
Then you tell the content switch to point all trafic to B and you have all the time in the world to update webserver A and switch the content switch back to normal mode.
I had this issue as well.
For whatever reason my local copy would take around 5 minutes to fully spin up after any change or starting the website fresh. It was absolutely dreadful for testing anything. It was only an issue locally. My development server environment and production didn't seem to be effected.
I found out a profiling tool that allowed me to find an outlier control that was taking an obscene amount of time to render. Try this...
Fire up your website after it compiles.
Log into this admin page: http://local.example.com/sitecore/admin/stats.aspx
You'll see a screen like this: Look for anything with an obscenely high Avg or Max time. Your problem will likely be in the logic there.
As a bonus, if you can keep hitting pages after your long recompile without much trouble, you should notice the Avg time roughly halving itself every page hit for your problem control if your problem is anything like mine was.
In my case, I found the largest issue came from one control that was doing an expensive search for one item.
It looked like this -> Sitecore.Context.Database.SelectItems("" + Sitecore.Context.Item.Paths.Path + "/ancestor-or-self::*[##templateid='" + templateId + "']");
This was mostly a local issue because the SQL server is remote to my machine, while the other servers were in the same building. Hence dev and production were relatively unaffected.
Good luck!
You can follow Alex Shyba's post here
But 2-5 minutes sounds extreme. This isn't normal. Are your hardware up to date?
Also I would look in to your prefetch cache. In your development environment you probably don't want i to fetch to much on start up, as this isn't needed in development.
I would also look into the initialize pipeline and global.asax to see if you are doing any custom start up jobs.
You can reduce the pre-fetch cache size on core, master, and web databases, but this is not recommended, do this only on development machines, not on production servers.
I am working on an ASP.NET project on VS 2010 that is completely local as of now and a strange problem keeps popping up which I can't seem to explain.
Essentially, sometimes when I perform an action that causes some sort of postback event (e.g. change the selection of a drop down list which repopulates a gridview based on the drop down list selection), the page will "flicker" like a normal postback but then result in a blank page.
Since this occured rather infrequently I decided to ignore it for the time being and focus on other aspects of the project. However, after I implement partial postbacks using AJAX, I think I may have found out what is happening.
With partial postbacks, the page now is not reloading every time a postback occurs, and I noticed that occasionally, performing an action that should cause a postback does absolutely nothing.
So my hypothesis is that somehow, the event triggered causes a postback but then gets hung up somewhere? I'm rather new to web programming so I'm at a loss at this point.
Any help would be appreciated.
Thanks
You seem to have an intermittent error that affects the large majority of your website without giving you any errors or logging. This is colloquially known as 'a huge headache'.
Here are a few steps you can take to hopefully get more information on the problem:
On your browser/client side, install a developer add-on such as Firebug that allows you to step through your AJAX/javascript as you make the calls. Watch for anything that looks odd or that might imply you are failing to address information critical for the postback. Javascript's robustness means that it can very often do things that are logically nonsense and not have a huge crash with informative errors like you would expect out of a more particular language like C#.
On the connection, install Fiddler and keep a log of all the requests and responses that go out over the line. When you manage to reproduce the error, inspect the request that went to the server very carefully to see if it's any different from others. If you get a response, investigate that too.
On the server side, try to drop a visual studio debugger into the web server instance so you have visibility on when something is hit and when it's not. If you are able to do this, you can at least see if it is getting all the way into your code when it goes to fail.
It may also help to ask if there's been any known hardware problems in your office/work space recently. It sounds really unlikely since everything else is working, but when dealing with a problem like this it's a good idea to check all your bases.
In my project, there is a page which has about 10-15 controls and, 3 tree views. It takes a lot of time to load as there is lot of logical checking required. How can I increase its speed (any method, code or database)? Please suggest some measures.
For eg: Every time the page loads, it checks whether the user is allowed to access that page or not. What controls he can access? The tree views are also binded based on the user access only.
On the loading of each controls, it again and again goes to fetch data. How can it be minimized?
Start with front-end optimization.
Disable ViewState of the controls, whereever it is not required.
Set Expire headers for your static content. (Browser caching)
Enable GZIP compression.
Install YSLOW, PageSpeed....for more recommendations.
YSLOW
PageSpeed
Then, come backend optimization:
Cache frequently accessed data
Do some code refactoring.....more
Try a profiler (the JetBrains one is good) on your application, it'll show you where your pinch points are. If you think it's database related, run explain plan/showplan on your queries to show how long they're taking and where they're spending their time. Really, your bottleneck could be anywhere, it'll take some legwork to track it down (it could even be network related).
Once a user is authenticated, cache his logged-in status and use that in your code; see if this makes a difference. Also, cache the data per user. You could use Session state to do this.
Also, set the trace attribute to true in your page directive tag - just to be sure this is what is causing the performance hit.
OutputCache can increase some shared partialview/usercontrol.
I have an ASP.NET application that does a large database read. It loads up a gridview inside an update panel. In VS2008, just running on my local machine, it runs fantastically. In production (identical code, just published and put on one of our network servers), it runs slow as dirt.
Debug is set to false, so this is not the cause of the slow down. I'm not an experienced web developer, so besides that, feel free to suggest the obvious.
I have been using Firebug to determine what's going on, and here is what that has turned up:
On production, there are around 500 requests. The timeline bar is very short. The size column varies from run to run, but is always the same for the duration of the run.
Locally, there are about 30 requests. The timeline bar takes up the entire space.
Can anyone shed some light on why this is happening and what I can do to fix it? Also, I can't find much of anything on the web about this, so any references are helpful too.
EDIT: I forgot to mention that I am using the exact same database for both local and production environments.
EDIT: __EVENTTARGET points to the timer that updates the progress.
EDIT: Timer appears to be working - I set it to a larger interval, which shows me that the local app is processing ~50000 records/second and that the production app (same database, same code!) is processing at best ~5000 records/sec.
Back to square one, mysteriously slow app. :(
My guess would be the size of the database you're using on your dev box vs. production. Is it possible there is something happening for each row of your gridview that only happens 30 times on your box becuase it has less data than production?
Systematic debugging - strip it down and add things back one at a time until you see the change.
Brandi,
Can you check the Event Viewer logs for the web server? Do you have anything failing in there?
Are you running the app in VS2008 off of IIS or the dev server?
Anytime I've experienced strange discrepancies between seemingly identical dev and prod code, I've learned to have a quick look at the machine.config file in production.
If you have access to it, you might compare it to your local copy, and specifically review these settings (although the linked post doesn't refer to your exact problem per se.)
I've come to accept that this may be a processor issue based on this other post:
ASP.NET Website Slow Performance on production server
Thanks to everyone who helped answer.