I have develop an asp.net-core MVC 3.1 application.
This application is hosted on a Linux server.
This webapp is launched by systemd with this command:
/usr/bin/dotnet /pathto/myapp.dll
I have an nginx web server which act as a proxy:
Here is my nginx site configuration:
location / {
proxy_pass http://localhost:5000;
...
}
Here is a description of my problem:
The application is very slow on the first page (about 30-40 seconds. I have a very basic sql server command on this page).
Then the application respond quickly (1 second).
I can go back on the previous page, the application respond quickly
I wait about 2 hours
The first page is slow again.
I am wondering something: Is it possible kestrel deletes at some interval compiled cache or something like that ? And when a user hits again the first page, kestrel compile something on the fly ?
This is strange because my app is stilled compiled (dlls)
Thanks
Related
I have a nuxt application running in universal mode and deployed on debian, proxy-passed nginx with pm2 as the process manager. (With laravel as the backend)
The app gets to 504 error randomly only on ssr. Meaning that only once in ten times of page refresh, when reading the first doc (server-rendered html) it gets to 504. No matter in which page it is.
I have checked everything including nuxt server requests(the requests being sent in fetch, asyncData and nuxtServerInit), none of the APIs have delay in backend response and all of them work well.
Can you guess what can be the problem and where it originates?
Maybe network, the communication between pm2 and nginx, server resources, the frontend code itself, etc?
I started to code my new website using ASP.net core
Everything runs properly with development environment: Open VSCode and F5 to run.
But after i publish all of them to IIS, it runs with 404 error
This localhost page can’t be found No webpage was found for the web
address: https://localhost:1111/ HTTP ERROR 404
The error page is displayed when the page connects database to runs backend actions.
Any actions in published web that don't use database such as href to another link, run javascript validation, ... would run with no 404 error
Do I miss anything or make something wrong?
here're the steps that i did to publish my site
open terminal and run dotnet publish --configuration Release
copy publish folder in bin\Release\netcoreapp2.2\publish to the publish folder in IIS setting
open IIS and add application pool with .net CLR version is No managed code
add website with application pool above, bind type is https, hostname is localhost, and tick all 3 checkboxes (Require server name indication, Disable HTTP/2, disable OCSP Stapling), SSL certificate is IIS Express Development Certificate
I forgot the page that guided me those steps
I myself have found the cause. The reason that the web app return a 404 page when I post something to backend to process database is I used windows authentication in my database connection string. So it couldn't access the database when I publish to IIS. When i change connection using sql server authentication, it works properly
unfortunately our production site dies every time IIS recycles the APP pool after 29 hours (default recycle phase). It seems like the entire application gets into a stall and becomes unresponsive. In most cases I need to restart the entire server.
Our site is an ASP.NET Core app running on Elastic Beanstalk and right now I do a preventive url/server swap every night - just in case.
As Kestrel doesn't need recycling but needs a reverse proxy to start it up I was wondering if I could set the IIS recycle period to never to solve the problem.
I can't see anything in the logs that shows a problem.
Also, whenever it happens the server is running on low CPU and nothing seems to be going on at all.
Thank you for your help!
Best,
H
In the .ebextensions folder add a file named iis-settings.config with the contents:
commands:
setIdleTimeoutToZero:
cwd: "C:\\windows\\system32\\inetsrv"
command: "appcmd set apppool /apppool.name:DefaultAppPool /.processModel.idleTimeout:0.00:00:00"
setPeriodicRecycleToZero:
cwd: "C:\\windows\\system32\\inetsrv"
command: "appcmd set apppool /apppool.name:DefaultAppPool /.recycling.periodicRestart.time:00:00:00"
See here for more details on ebextensions https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions.html
IIS 7.5 warm up (IProcessHostPreloadClient) is not working when application pool's Managed Pipeline Mode set to Classic, if the Managed Pipeline Mode set to integrated Mode it works fine.
Not sure if i have to do anything special for classic mode to work
I am following this url
http://weblogs.asp.net/scottgu/archive/2009/09/15/auto-start-asp-net-applications-vs-2010-and-net-4-0-series.aspx
We had the same problem on our IIS 7.5 (Windows Server 2008 R2). There is a delay about ~30 seconds until the web site appears. We also tried to solve it via ScottGu´s blog with no success. So we installed a cronjob that executes C# code and does a fire-and-forget request to the webserver:
public static void WarmUp(string pUrl)
{
var lWebClient = new WebClient();
lWebClient.DownloadStringAsync(new Uri(pUrl , UriKind.Absolute));
}
Execute the WarmUp:
WarmUp("http://hostname");
After that call + ~30 seconds, our web site will appear directly in the browser.
I have a Pylons app that I'm trying to set up using Apache and FCGI. The Pylons INI file has this in it:
[server:main]
use = egg:Flup#fcgi_thread
host = 0.0.0.0
port = 40100
This used to work on an old CentOS server with Pylons 0.9.7, but now I'm trying to set it up on a new one, running Ubuntu 10.04 and Pylons 1.0. I can connect to the app and load main page, but it's very slow. It then makes AJAX requests and the HTTP responses to those are all messed up: sometimes I'll get half of the response text (eg. half a GUID that the server sent), other times there will be HTTP headers and binary junk in the body of the response. Each response is also delayed by about 15 seconds. The app works fine on the same server when using Paster directly.
I've never seen anything like this before. Any idea what's going on?
In case anyone else runs into this, turning off the gzip module in Apache fixed the problem. I still don't know why it happened.