I compiled my app in release mode. I then went ahead and 'published' the site.
Copies all files and moved them to a staging server with a static ip. Restarted IIS.
Went to another machine and hit my web site. It took about 4 seconds for just the default page, which is pure HTML with no custom framework usage, to show up. What gives???
Sounds like it is just the application pool spinning up. Assuming that you are the first person to hit it after deployment, this isn't uncommon. It appears fine after the first page hit, correct?
If you set the #Page directive variable "Trace=True" does that show you any load times which out out of place? Also, if you are connected to a database, running SQL Profiler for example will show you any database queries which are too slow.
Lastly, I had a strange issue where I had a virtual directory setup which pointed to a directory that didn't exist. The network timeout that ocurred looking it up took a while.
Related
For an ASP.NET Website where i am making updates. What would cause user sessions to reset?
From my understanding if i make any changes to files in the app_code folder or the global.asax file it will reset everyone's session but if i made a change to .cs file (in the top directory) it wont reset everyone's session?
Would it reset the session of anyone that was on that page that i updated?
Can someone help me with my understanding, thank you.
Assuming memory-based session (as opposed to sql server based).
Well, the app pool restart will blow out session.
(so, in some cases even un-handled errors will blow out session).
Modify web config?
that will case app pool to restart (and blow out session).
Update any folder outside of app_data. Again, app pool re-start (and blows out session).
change content of bin folder - again app pool re-starts, (and blows out session).
Update code behind (.cs, or vb pages (code behind)). - again, app pool re-starts, (and blows out session). (so anything that will cause a re-compile of code).
There are probably a good many more - the above is a basic list.
You can thus consider adopting sql session based, and that will thus be far more robust, and I even re-started IIS services, and users if not doing anything just looking at their web page while logged on? They were able to continue working even after a full re-start of IIS services.
On the other hand, I now always use a asp.net web site "applcation". Thus no souce code is placed on the web server, and my compile is done with visual studio before deploying. The only big issue is that if you change to a application deployment model, the even just changing one line of code behind will force/require a full re-publish of the web site.
It looks like you are using a web site, and thus source code (code behind) is placed on the web server. Thus, IIS has the job of re-compiling such code, and thus any code change will as a general rule cause a app_pool re-start, and thus loss of session.
As noted, if you change from in-memory session to SQL server based (turn that feature on), then most if not all of your session issues will go away. Even if you not using "application deployment" and have/use code behind on the site for IIS to re-compile? Then using sql server-based session management should fix all of your session() woes.
I was witching and had my first few ASP.NET Razor Pages projects, debugging locally, publishing after, and everything went fine.
But now I temporarily took over a project from somebody with health issues, can not ask him things at the moment, maybe next month.
The projects run on two physical servers, five IIS-applications running, like API, Video-Handling, IndentityServer and a "WEB" for the user-interface. Endpoints defined in the "appsettings", I get it.
I changed some minor things at the User-Interface (WEB-Application), published it directly on the server and everything went fine. Pfff..
But... now I want to make some bigger changes and test them locally before publishing, but still using other unchanged IIS servers on the two servers, which do the "heavy-lifting". So I put some breakpoints like always, run "Debug" on Rider, express IIS server starts successfully, but I noticed the application redirects to the project on the remote server and then of course does not meet my breakpoints anymore, it is just running the old version on the server. Now I am missing something..., looked at several configuration files, how can I configure it, when it starts with the local IIS express server instead of the remote server? I want to stay on the local IIS express server, since I want to test the changes of course.
Hope I explained my issue well enough, did not know how to tell exactly.
Greetings to all!
My question has nothing to do with the initial page loads. My ASP.NET Web Site is running very slow, on IIS 10. Even when I refresh the page after a load, it takes minutes. What do I need to check?
Application Initialization Module is installed and running
App Pool is using Classic managed Pipeline mode and has Start-Mode set to AlwaysRunning
Preload Enabled in Website's setting is set to true
The same application runs fine on another server running older WinServer and IIS 8. What do I need to check?
This is embarrassing. Posting this answer so I find my own question the next time I run into this again, or someone else runs into this. My application on the other server where it runs, has caching configured so all the database pulls are cached. This new server has no caching set up. Those pulls are so slow, I am finally getting the hang of it.
I'm developing an ASP.NET 2.0 application that includes Crystal Reports (version 10, included with VS 2005). Originally, the reports were working properly, both when run from my machine using the ASP.NET development web server, and also when deployed to an IIS server.
I made some changes to the reports and re-deployed the app to the IIS server, but the report changes are not showing up when I run the application (although they are showing up when serving the app locally on my machine). Is it possible the IIS server is caching older copies of the rpt files and not flushing them properly? I suggested this possibility to the guy managing the server, but he said he re-started the app pool and it didn't make a difference. Any ideas?
The report source object has a cache duration(in seconds) property. I think it is set to 60 seconds by default. You can either shorten this and then run the report again or alternatively you can turn it off by another property "enableCacheing". I have had mixed results with turning cacheing off so I usually just use the aspx page to set the property on the report source and lower it to 1 second to refresh the report, and then raise it back up once the cache has cleared.
Double check that the new one didn't get renamed somewhere in the process and the code is still referring to the old one.
What happens if you temporarily remove the RPT file on the web server? If you don't get an error, it's loading the report from someplace else.
Are there subreports involved?
This is my set up on a stage server
compiled my web application
published website
copied the output directory from my machine to stage server
created domain account
created virtual site on a static IP
website runs under domain account created
impersonate set too true as windows integrated authentication is used with sql server
Now first time i hit my stage site, the page is slow to load which i understand, but subsequent request do take a while for the page to load.
planning to run wire shark to see what the traffic is. is there anything else that i should look for?
Note: My IIS and SQL are on the same machine.
You should run it through a profiler to see what it is spending so much time on. SQL Server includes it's own nice query profiler, and if you want a free profiler for .net, there's nprof. If you want to pay for a profiler for .Net, and it's probably worth it in the long run, there's lots of good offerings available.
Can you define slow? how many seconds?
Definitely check the queries to sql server to see what they are doing.
There is always task manager and take a look at cpu/memory. It is not hard to peg a single cpu for example. Anything else on the server?
When having problems I always like to have an empty aspx page just to eliminate other issues.