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?
Related
I'm new to Progressive Web Apps, and I'm adding a Service Worker to my app for the very first time. It's a simple Service Worker, with my goal being purely to test that it is being registered properly. The file is serviceWorker.js:
console.log('Hello Service Worker');
I'm adding this to an application that I'm running with the Webpack Dev Server. I'm using a self-signed certificate locally with it. I setup the Service Worker in my index.tsx (React Typescript) like this:
if ('serviceWorker' in navigator) {
navigator.serviceWorker
.register('/service-worker.js')
.then(() => console.log('Worker registered'))
.catch((ex) => console.error('Worker registration error', ex));
}
However, when I start the dev server and go to the app, I get an error:
Failed to register a ServiceWorker for scope ('https://localhost:3000/') with script ('https://localhost:3000/service-worker.js'): An SSL certificate error occurred when fetching the script.
The URL, https://localhost:3000/service-worker.js, does indeed work, the browser is just blocking it because of the self-signed piece of the cert.
I'm using Chrome Browser on on M1 Pro MacBook running MacOS Monterey, with Webpack 5.
For the record, I'm aware of plugins like Workbox, I would prefer not to use them at this time because I'm still very new to Service Workers. I believe in working with the low-level constructs when starting with a new tech to understand them better before embracing easier abstractions.
I'm not aware of any features—including service workers—that require HTTPS on localhost.
localhost, and equivalent IP address ranges, are specifically excluded from HTTPS requirements by Chromium-based browsers, and both Firefox and Safari follow that, at least when it comes to service workers.
So I would suggest that you just access your web site via http://localhost:3000 instead.
There are more details in this older answer.
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
I managed to deploy my first cloudflare worker using serverless framework according to
https://serverless.com/framework/docs/providers/cloudflare/guide/
and it is working when I hit the cloud.
During development, would like to be able to test on http://localhost:8080/*
What is the simplest way to bring up a local http server and handle my requests using function specified in serverless.yml?
I looked into https://github.com/serverless/examples/tree/master/google-node-simple-http-endpoint
but there is no "start" script.
There seem to be no examples for cloudflare on https://github.com/serverless/
At present, there is no way to run the real Cloudflare Workers runtime locally. The Workers team knows that developers need this, but it will take some work to separate the core Workers runtime from the rest of Cloudflare's software stack, which is otherwise too complex to run locally.
In the meantime, there are a couple options you can try instead:
Third-party emulator
Cloudworker is an emulator for Cloudflare Workers that runs locally on top of node.js. It was built by engineers at Dollar Shave Club, a company that uses Workers, not by Cloudflare. Since it's an entire independent implementation of the Workers environment, there are likely to be small differences between how it behaves vs. the "real thing". However, it's good enough to get some work done.
Preview Service API
The preview seen on cloudflareworkers.com can be accessed via API. With some curl commands, you can upload your code to cloudflareworkers.com and run tests on it. This isn't really "local", but if you're always connected to the internet anyway, it's almost the same. You don't need any special credentials to use this API, so you can write some scripts that use it to run unit tests, etc.
Upload a script called worker.js by POSTing it to https://cloudflareworkers.com/script:
SCRIPT_ID=$(curl -sX POST https://cloudflareworkers.com/script \
-H "Content-Type: text/javascript" --data-binary #worker.js | \
jq -r .id)
Now $SCRIPT_ID will be a 32-digit hex number identifying your script. Note that the ID is based on a hash, so if you upload the exact same script twice, you get the same ID.
Next, generate a random session ID (32 hex digits):
SESSION_ID=$(head -c 16 /dev/urandom | xxd -p)
It's important that this session ID be cryptographically random, because anyone with the ID will be able to connect devtools to your preview and debug it.
Let's also define two pieces of configuration:
PREVIEW_HOST=example.com
HTTPS=1
These specify that when your worker runs, the preview should act like it is running on https://example.com. The URL and Host header of incoming requests will be rewritten to this protocol and hostname. Set HTTPS=1 if the URLs should be HTTPS, or HTTPS=0 if not.
Now you can send a request to your worker like:
curl https://00000000000000000000000000000000.cloudflareworkers.com \
-H "Cookie: __ew_fiddle_preview=$SCRIPT_ID$SESSION_ID$HTTPS$PREVIEW_HOST"
(The 32 zeros can be any hex digits. When using the preview in the browser, these are randomly-generated to prevent cookies and cached content from interfering across sessions. When using curl, though, this doesn't matter, so all-zero is fine.)
You can change this curl line to include a path in the URL, use a different method (like -X POST), add headers, etc. As long as the hostname and cookie are as shown, it will go to your preview worker.
Finally, you can connect the devtools console for debugging in Chrome (currently only works in Chrome unfortunately):
google-chrome https://cloudflareworkers.com/devtools/inspector.html?wss=cloudflareworkers.com/inspect/$SESSION_ID&v8only=true
Note that the above API is not officially documented at present and could change in the future, but changes should be relatively easy to figure out by opening cloudflareworkers.com in a browser and looking at the requests it makes.
You may also be able to test locally by loading the Cloudflare worker as a service worker.
Note:
Use a local web server with https:. Workers won't load using file: or http: protocols.
Your browser will need to support workers, so you can't use IE.
Mock any Cloudflare-specific features, such as KV.
<!doctype html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<!-- Service worker registration -->
<script>
if ('serviceWorker' in navigator) {
// Register the ServiceWorker
navigator.serviceWorker.register('/service-worker.js')
.then(
function(reg) {
// Registration succeeded
console.log('[registerServiceWorker] Registration succeeded. Scope is ' + reg.scope)
window.location.reload(true)
})
.catch(
function(error) {
// Registration failed
console.log('[registerServiceWorker] Registration failed with ' + error)
})
} else {
console.log('[registerServiceWorker] Service workers aren\'t supported')
}
</script>
</body>
</html>
Dollar Share Club created Cloudworker. It is not actively maintained, but it is a way to run Cloudflare Workers locally.
You can read about it on the Cloudflare blog in guest post by the original maintainer of Cloudworker.
Config
We have a play 2.1.0 with angularjs setup in a production mode.
We have reverse proxy load balancer setup with apache 2.2 something like mentioned in here
http://www.playframework.com/documentation/2.1.0/HTTPServer
This whole app is running in an iframe inside navigated from a jboss application.
Problem
Most of the time it works and sometimes when the connection is left idle for 2/3 hours, untouched, no one hit the reverse proxy url to load the jboss/play, then we are getting the 502 proxy error in the iframe content after a few mins wait.
Play receives the request, but somehow decides not to respond at all. This occurs only for the first time or couple of time after the wakeup. Then when we refresh the page play receives the request and responds it properly.
Tried
We get a tcpdump on the play port and it we have got all the requests being received, but no response sent from play for the failed scenario. Whereas the same request got responded by play subsequent times.
X-Forwarded-For: ,X-Forwarded-Host: X-Forwarded-Server: .. Connection: Keep-Alive - all these headers are being sent in the lost response tcpdump.
Tried KeepAlive, with timeouts in the proxy server, not much help. Why the play didn't respond for the initial connections after idle state, is there any conf we can set to keep it alive?
Workaround
Polling the play server url constantly every half an hour from the same server makes this issue not reproducible.
Still any help/suggestions would be really appreciated to fix this issue..
I tried to solve this problem myself. Approaches like the answers mentioned here and here did not change anything.
I then decided to go for nginx again which I have been using with Play applications before. The setup is to be found here. Since then the problem is gone.
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.