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.
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 have just recently updated a web application on an IIS server, but after the update my users were receiving an incorrect input format error. This error is because the code is trying to convert a user's string input into a double which obviously doesn't work if the user passes in something like 55.5D.
Besides the bad coding practice I'm going to fix anyway, that's not the real issue. The issue is that the user was sending correct values (I watched and have input the exact same values myself) yet the program was still throwing this error. I reverted back to a previous version and the error disappeared. I haven't changed this section of code since the previous version. Anybody know what is going on here? I can't get the problem to repeat on development servers either without intentionally feeding the program bad input.
EDIT: I have tried clearing the user's and server's cache after the update, but that still received the same error, even after I put checks on the areas that were breaking (I missed some elsewhere in the code too). However, it worked great when only a few users were using it at a time, but it was breaking when many users were using it. Do ASP.NET controls have issues when many users are hitting the site?
Fully managed components in IIS do not require an application pool restart for changes to be applied. On the contrary, it will reload and JIT things again even if only web.config changes. If you are in doubt, you can always test this by including a test page with your application with a visible differentiator.
The most likely reason for your case is caching. Client-side is more likely culprit. Have you monitored http codes to verify that requests are really hitting your server and getting "live"-results (HTTP 200)?
Server-side in-process cache should be reset automatically but if you have persisted it somewhere out-of-process, they could be picked up after app upgrade..
And of course reverify that you really are testing exactly those dlls you think you are testing. If things don't make sense then verifying a wider set of assumptions can help.
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'm after some general advice here. We have an ASP.net 4 web forms application on Windows Server 2008 R2 and IIS 7.5, with SQL Server 2008. We're experiencing problems with the website timing out, seemingly at random. We've had reports of what people were doing on the site when they noticed it started timing out, and there is no consistency between these. We have also tried all of the things that users reported they were doing, and have had no joy bringing the site down. We have static html pages on the site (albeit with .net4 friendly URLs) and these pages display when the site is timing out.
At first we thought it was a cyber attack, so spend time making sure all ports were closed, remote access only available to select IPs, and routing mail through an external spam filter (allowing us to close port 25). We also ran virus and malware scans which found nothing.
We have made updates to the website at the time that these problems started appearing, however it's really too late and too much has happened on the site that we could roll back the changes without experiencing a bigger headache than we currently are.
I'm a developer rather than a support/hosting/hardware specialist, so don't know huge amounts about server setups, but I've spent a long time going through error logs looking for some positive sign. When I've looked at the error logs around the time the site went down, there has rarely been a error - sometimes there is a warning, but nothing that looks conclusive (this could be where my server inexperience could be a problem however). I'm not ruling out there being multiple issues by the way.
I set up IIS debugging tool as I noticed a w3wp.exe error yesterday (similar to this: an unhandled win32 exception occurred in w3wp.exe), but the site has continued to go down today with nothing new in the debugger. I've debugged the site locally through VS2010 and can't recreate any issue.
So really, I'm on the point where I've run out of ideas, and almost run out of hair to pull out. Can anyone who's a bit more clued up in this area, offer me some advice or a list of things to try in order to pinpoint exactly what is happening here and what is causing it to hang? Any help gratefully appreciated
We found that there were some TableAdapters in the site that were static and shared for the class. After removing them, the problem stopped. Thanks for the help anyway folks
I'm looking for a solution to a performance problem. We are using the following:
ASP.net
SQL Server
Entity framework
I am hoping that someone has run into this issue before and has solved it!
It's taking 2 at 3 times longer to execute an HTTP request on a hosted application compared to running the same application locally on debug. However, if we trace between preinit and rederer, on the server host,we are getting something like 0.250 seconds request time but, when are watching it, it is actually taking 3 or 4 seconds to render that complete page.
This is driving us crazy! Any ideas as to what is causing this and how to fix it?
Is there a program can we use to check and debug this for it's root cause? If it was happening to you, are there recommendations as to what you would you try?
Thanks you!
probably any of this:
is the data from the development computer the same that in the production(hosted) server? if not the problem is that you are not using well your ORM or have to optimize your app.
you can use firebug net panel to check if the problem is from the network...
if you are using a VPS and a cheap one, your computer might be better than the server and as the server is shared among several virtual sites their load might affect the performance of your app.
hope it helps.