Windows 8.1 Pro, Visual Studio 2012 Update 4, MVC4 Umbraco site using SQL Azure (have also tried with a local SQL 2008 R2 db). Running through IIS.
Site runs perfectly while not debugging. However, when debugging the site is extremely slow. The default page takes nearly a minute and a half to execute. Subsequent requests take the same amount of time.
I thought this may be environmental (Surface Pro 3, i5), so went over to a MacBook Pro (i7)...issue still occurs on that PC as well.
At my wits end trying to figure out what could be causing it.
Thank you so much!
There are several thing that could be happening here. Using an Azure SQL db would cause slower initial loading of pages (compared to a local db) because of the data transfer time. However, subsequent page loads should be quick because everything would be loaded into the site cache.
If subsequent page loads are still extremely slow then this could be because the XML cache isn't being generated. Check that the settings are correct in the web.config in debug configuration.
Also, check where you are writing your debug logging to. Umbraco will write log messages to a log file in App_Data/Logs/ and also separate logs to the database. Using a remote database would make these writes slower.
Without knowing what else is happening in your project it's difficult to know what other factors may be playing a part. But you need to step through the application in debug mode in VS and you can check the event viewer for swallowed errors like timeouts. Finally, you can use a profiler to pin point exactly where your issue is.
Related
I have a problem regarding White Screen Of Death (WSOD) at my site.
I will try to explain what I have tried until now.
I know it is not a triviel error to debug, but maybe some of you have tried something similar.
Here is the setup: One Windows Server 2019 v1809 with one IIS: 10.0.17763.1.
Multiple websites with associated application pools.
It's a MVC solution, and we are using .net 4.7.2.
What I have tried:
Recycled application pools every night
Restarted the server every night
Issued a IISReset every night
Deleted temporary files in C:\Windows\Microsoft.NET\
Looked at the IIS logs
Looked at the application log, our own log
Looked at the Windows log
Searched the Internet for similar problems
Made sure there always were some traffic at the website
Made sure no errors were shown when pressing F12 in the browser, the site always returs code 200
The WSOD comes at varies times, and not all the sites are affected at the same time.
A manuel recycle of the website always helps.
My question is, have any of you encounted similar problems?
And how did you solve it?
If you need more information please ask, and I will try to provide it.
/Regards Søren
This kind of problem is very unusual in IIS, because there is almost no record and useful information in the log file.
You can try to use this plan to repair IIS.
Unregister all the versions of ASP.NET with command "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –ua". and the framework 64 also versions. 3.0 and 3.5... etc
Delete ASPNET account from "Local Users and Group – Users".
reregister ASP.NET with IIS using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –i". and framework64... net 3, 3.5 etc
Give permissions to the ASPNET account using "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis –ga machinename\ASPNET". for framework 32 and 64 and versions.
Reset IIS .
I am facing a strange issue. I have a UWP app published in store. When I deploy this app to my Lumia 930 through the store, it runs very slowly. However, the same app when I deploy to the same device in debug mode from VS 2015, it works fast. To be specific, I am relying on heaving caching in a Sqlite database for displaying the results, plus I also have lot of List processing done in my logic. In debug mode, one specific page with particular set of data takes around 3 seconds to load and show the results. The same page with same data takes 8-9 seconds when running on the same device but downloaded from the store.
Any idea, what I am doing wrong, or is there something which I am missing. The particular app in question is: https://www.microsoft.com/en-us/store/apps/series-tracker/9nblggh3slj9
Appreciate your help.
We have noticed that with the 2012 NetSuite Web services (and perhaps all other versions), when we make a call from a .NET 2.0 64-bit application, if the response does not come back quickly, then intermittently our application will hang however in the NetSuite application logs it appears the SOAP call was successful. The hang eventually times out (timeout) after 5 minutes (!) because NetSuite (or something) keeps the socket open, it just stops sending packets.
We ran a Network Trace and noticed packets coming out of order, being dropped, inexplicable duplicate acks - etc. Essentially, it "freaks out". Microsoft techs have never seen anything like it - least the ones I talked too.
We ran a simple test app that does nothing more than passport in, then do a query for Accounting Periods. It's the search method that hangs as it's parsing the SOAP response - always gets about 10s in.
As soon as we target a 32-bit environment, everything works like a charm, even though the 32-bit binary is running on a 64 bit OS. Clearly, running as a 64-bit app sets some network protocol configuration that NetSuite really doesn't like.
We tested on Azure, Amazon and on a local (to our corporate network) Windows 2008 R2 SP1 64 bit servers - physical and VM's.
We don't have hard evidence of the "why" this is happening, but after a month of pulling our hair out (we're all bald now) we think we've stumbled upon an issue. This one is so weird, however, I'm not willing to go out and claim that it's still not something we're doing. So, if you don't believe:
Open Visual Studio 2010 and create an .NET 2.0 console application targeting "Any CPU".
Do a "Add Web reference..." and add the NetSuite WSDL.
Create a simple passport login and do a search that returns something with some volume.
Run the EXE on a 64-bit OS, several times (this bug is intermittent), during peak working hours (i.e. appears around 7am - 2pm PST).
That's exactly what we did. If you go back and create a new x86 target and rebuild the project, it works fine.
I have run into an issue with VS 2012 not hitting breakpoints during the seeding process of my DB. I am on Svr 2008 R2 using EF 5. This is similar to this breakpoint issue, but not quite the same. Once I get past the seeding process my breakpoints work fine in the controllers (and I assume everywhere else).
I can get the breakpoints to work with IIS Express, but not IIS 7. Since the breakpoints that I would like to hit are in the Application_Start and the Seed process I do not have time to Ctrl-Alt-P to attach a process and attempt debugging that way. I did check windows authentication and registration of iis, those did not affect the breakpoints.
I can verify that the seeding is run with logging and how the DB is created. I would prefer not to revert to the dark ages of debugging with logs though. I would also prefer not to be required to switch back and forth between IIS Express and IIS 7.
To recreate this I started a new VS 2012 proj selected MVC4 and Internet Application. I manually changed the web.config to point to SQLEXPRESS. Then I changed the project properties > web to not use IIS Express. I created a breakpoint in the Application_Start and and a breakpoint in the homecontroller/index and ran the project. The only breakpoint that was hit was the index breakpoint. Rechecking the IIS Express allows both breakpoints to be hit.
Please let me know if you have seen this issue and have a workaround.
Thanks,
TJ
I seem to be running into lots of these types of issues lately. I clear ways to replicate them, and I leave them alone for a few days and they disappear. I am unable to recreate this anymore. I even used the same project that I was only changing the checkbox to use IIS Express.
So, when in doubt, don't pull out your hair, work on something else and be patient. Who knows, perhaps turning it off and on again worked (even though I did try that, thanks Roy).
This is not directly a question about code, but FileSystemWatcher/OS behavior. I have an app, which monitors thousends of logfiles. The app
runs since years without any problems. It was running on a Server 2003 against shares hosted on Server 2003.
If it runs on Server 2008 (R2) and the store is on Server 2008 (R2) not much events are generated. I made a simple repro which show the difference [but as I told: The long running old proggi does work properly]. The apps, generating the logs are not under my code control.
In my repro - writing such log with pauses - even a flush for the writer and/or the underlaying stream does not help].
On Server 2003 each update [write operation from the logging app] causes the FSW to fire Size changed events. On Server 2008, this happens only, when the app starts to write the logfile and when the logfile closes. No events in the middle any more. Settings the REG keys to write NTFS timestamps brought no changes to this behavior.
I am not in a position to open a call at MS, but probably, someone has seen this behavior and knows a workaround.
The workaround coming to my mind are: Downgrade to Server 2003 or to Linux. Both works as expected.
Any ideas are really very welcome.
Best regards,
++mabra
[Net 2.0 => 4.0; No question: All patches, OS also]
[edit]
Sorry, there were faults in my analyzis .... Together with the move of my
app to Server 2008, a new app came to the set of files to monitor [Change
never two things at the same time....]. The new app has another behavior,
then the apps which's logs I've read before ....
(1)The old apps use: Open/append, write, close.
(2)The new app uses: Open/create, write, sleep, write, sleep, write, close.
The FSW gives me the changed event for the old apps behavior, but not
for the new one. The FSW Notifyfilters.Size does not work like I have
expected. So, the new app's log cannot be monitored with FSW.
I found no workaround to make the chnaged event fire for size changes
alone.
But this keeps: The is Windows Server 2008 ! Windows Server 2003 and
Linux with mono even gives you the changed event for (2) !!!!! So,
my "title" was not that bad ;-)
Unhappy with .Net now ....
If someone has probably an idea, please let me now !!
And sorry for my sloppy first-time analyzis ... ;-)
br,
++mabra
Just for the case, that someone is watching this ....
I opened an Issue at MS.Connect - some weeks ago - and they
directed it to the VS team.
The bad news are from today, where they first set the issue
to "Won't Fix" and then to close.
I see this as in indirect confirmation of a bug, which
will not be fixed.
I am completely disappointed.
Anyway, best regards,
++mabra
=> MS Connect Issue