I am using Next.js and express as front end and back end server. Next.js hosted on the Zeit Now, express app hosted on Heroku.
If I go to express app, I can make sure that it's working correctly and its connection to mongodb works fine as well.
When I hit index page of Next.js through Zeit, it seems to be hanging on the GET / tasks more than 10 seconds.
I am only calling 3 end points just GET methods from index.js of Next.js app. This shouldn't be hanging the whole application.
If I go to my server independently, which only takes less than 3 seconds or so to give back JSON data.
I also looked at function tab Zeit provided, but it won't show what exactly serverless function was failing.
So it is hard for me to debug this. I also set whitelist all IP from Mongo. So the database should be fine.
If anyone dealt with this before, please let me know.
My site is https://www.yaobaiyang.com
Issue happens unexpectedly, you may or may not see this error
I had the same problem on my website:
Check the limit on your plan https://vercel.com/docs/v2/platform/limits (Especially if you're in free plan, you will have some limits.
For the problem was an uncatch error, the lambda crashed and wait the timeout.
Through more understanding, the problem may appear on Heroku, Heroku's free plan is 1000 dyno hours, which is the usage time in general, and then within the 30-minute time limit, if there is no access, the server will go to sleep. . There may be a delay in reawakening, which usually takes longer than when it was active. If this is the problem, the solution is to use
Similar to pingdom or cronjob, a regular automatic request interface, request my Heroku periodically in less than 30 minutes to keep it awake.
Use a VPS like digital ocean or Vultr that runs 24 hours a day, 365 days a month, and then deploy my Node, Nginx, Http/2, etc.
Upgrade Heroku's plan to cancel the 30-minute sleep
Upgrade Zeit has more timeout.
Related
My asp.net web application is encountering down time everyday, it takes forever to respond. But once I stop and start (not iis reset) the website in IIS it will work again. Then hours/a day later it will become unresponsive again. What would be the reason? I'm suspecting an unclosed connection to database but hard to find them. The codes were made by the previous programmer.
Check the queue length which is a setting under apppool.
If its happening during a particular time of the day then please check the resource utilization like CPU/RAM consumed during that particular time.
There are APM tools like App Insight available which you can use to monitor the request response time for the requests.
You can implement Google analytics to see number of users online or requesting to see if its threshold issue.
Look into IIS logs during the time of issue and check the time-taken field. If its above normal, proceed to the following step
During the time of issue (before you restart the website), capture a manual hang dump of the w3wp process - https://blogs.msdn.microsoft.com/debugdiag/2013/03/15/debug-diagnostic-1-2-generate-a-manual-hang-dump-on-a-specific-process/
Run Debug Diag report and share it if you can. It'll tell you things that are possible going wrong.
I have a site in which i am using web API through ajax that hosts on same IIS as a different site and both application pool are different. My web API is in MVC4 and I am using SQL server for data access some web API takes 0 sec and some takes between 2 sec to 8 sec . My site is centralized on azure server .
My Problem is when 100 or more users uses my site my IIS web API site goes hang and not respond any request more . For this i looked worker processes, there some request listed and server was not responding any request.CPU utilization is 50% and Memory is 19 % at that time.
Can i assigned 4 worker processes to web API sites for this issue but don't know how its work if i assigned multiple work processes to one site .
If u have any idea please share with me how i handle above situation?
I am certain that IIS is not causing this issue. If you think the requests are being blocked by IIS, you can check CurrentQueueSize or ActiveThreads.
You can also check executing requests from command line using 'appcmd list request' command. You will be able to see which requests are taking longer time to execute and blocking requests are usually at the top.
There is a high-chance that something in the code is blocking the requests.
By the way, you have tagged this query under 'azure'. Are you running it as Azure Web App? If yes, you can use 'Kudu' to diagnose the cause.
I am guessing you using an Azure VM (As from the description I see that you have access to IIS) .If that is the case,you can capture a hang dump of the process using debugdiag and do an automated analysis to figure out what is happening in your application code.
Before the issue occurs,Please go ahead and install DebugDiag on the server
Capture DebugDiag(capture consecutive hang dumps)
Launch DebugDiag Collection and Go to the Processes tab
Reproduce the issue
capture a hang dump
right click on the w3wp.exe process
choose the option Create Full Memory dump
Capture another dump after 30 seconds and then another after 30 seconds
You should have dumps captured in the folder C:\ProgramFiles\DebugDiag\Logs\Misc\
Right click on the dump file and choose the option Analyse Hang
Now the debugdiag automated hang analysis should tell you if there is any deadlock or any other issue in your code and also shows all the hung requests and where each requests are stuck.Also look at the stacktraces of the requests and see what it is doing.
Please feel free to update the question with more details if you need any help in analyzing.
In case of TL;DR - I basically need guidance regarding what tools are available to debug requests which are issued to IIS and which stall inside a module.
I have a problem with an old ASP 2.0 app at the moment whereby it will periodically become unavailable and recycling the app pool (horrible as that may be) doesn't bring it back up 100% of the time.
So first of all it presents itself as requests entering the app pool and being trapped in state 'BeginRequest' in RewriteModule.
It is not a specific request which is always the first to experience this issue. The issue cannot be easily recreated either.
Eventually requests join this backlog and when it becomes 70+ deep the app pool fails to respond to pings from WAS and it forcibly recycles. Predictably it doesn't stop on-time and the old app pool is forced to stop. When the new app pool comes up it either works just fine or it instantly experiences the same issue as the outgoing one and requests begin to queue.
In issues like this all the official guidance is understandably focussed around looking at why the RewriteModule may choke.
I have validated my redirections and though complex there are no obvious issues with syntax (XML validates).
Likewise in inetmgr loading up the URL Rewrite Module seems to parse the configs fine and show them visually.
Basic stuff like permissions is all fine.
When the app is working normally I also used Failed Request Tracing/Logging to look at the request pipeline for a sample URL which stalled and I can confirm that there is no circular logic or weird errors presenting - the request seems to be handled just fine. This also showed me how high up the rewritemodule is invoked and from this I really don't see how the issue could be app-related as .NET isn't invoked at this point.
Annoyingly when an app pool is experiencing this issue and I can throw in requests which just stall Failed Request Tracing is no good because you actually need a request to get to the end of it's journey and fail otherwise it refuses to log anything out.
I resorted to taking process dumps of affected w3wp.exe's and running them through DebugDiag. Unfortunately the only thing I see is that threads are open accessing the rewritemodule but precious little about what they are stuck on.
As anyone else would do I've tried to track the start of the issue back to any recently installed patches or code changes but nothing matches. Likewise this is happening on 3x servers otherwise I would try reinstalling the rewritemodule. Other sites on the same server which invoke rewritemodule are unaffected.
Has anyone else experienced issues like this - the net seems to have relatively little info in this case. Perhaps you can recommend further debugging tools or approaches for IIS which I can adapt to this scenario? This is sort of a cry for help from someone more used to Apache/Nginx - sorry for the long post.
What are the specification of the free server where my meteor app runs when I do this.
meteor deploy myapp.meteor.com
Specification in terms of
Storage size
Max bandwidth
Max Connections
Processing limits
At the moment from what they're saying on the meteor-talk group, there aren't any enforced limits of any sort. Your app just sort of scales itself alongside all the others hosted there.
There is only one thing though, if your app isn't used/has no visits for a few consecutive hours its 'killed'. When someone visits it next time its put back up (of course the end user wont notice this, to them its as if it were up all along)
But what it means is background processes that you use/cron type tasks don't work well because the meteor deploy server will kill your app's task silently until the next web request comes along.
I got website that running on IIS7 that response very slow during weekend night time, after restarting the application pool the website would response fast for certain of time. As time goes (maybe few hours) the website response become slow again.
I open the resource monitor at task manager, and look for the process for the website, the Average CPU is like 6-8, what makes me curious is the Receive B/s go up to 0.8-1MB while the Sent B/s only have 200B, I don't know if that is relevant.
So I was hoping to get an insight of what is the problem here.
Your question is a bit vague. For starters, are we talking a web app, connected to a database? If so, what type of database? There could be any number of causes for this.
But from the sounds of it, I would first start with any database queries you have running. I had a similar issue to yours with a web app, which turned out to be the result of an inefficient SQL Stored Procedure. The site would slow down and grind almost to a halt, but would spring back to life after the app pool was restarted. Rewriting the main Sproc solved the problem.