We have a whiteboard application powered by NodeJS sitting on a 'cloud' server (rackspace cloud). I recently scaled our server up to accommodate for the anticipated traffic with our launch, and in the process it shut down NodeJS. We are launching our product in a few hours, and our NodeJS developer has gone for the day.
The whiteboard application is supposed to run at http://rayku.com:8001 (the port is opened). However, it's not working because the port isn't listening to anything with NodeJS shut down.
I honestly have no idea which js file to run in order to start NodeJS for the whiteboard. There are many js files in a 'whiteboard' folder. Do you know what type of code I should look for that might suggest it is the right one? Or, do you know what types of logs I can dig up that might point me in the right direction?
Much appreciated
Look for app.js, server.js or something similar. It isn't required but a lot of people use app.js from what I have seen.
node or nodejs is typically the command to start. You may need to set environmental variables or arguments depending on how the developer set things up.
Also make sure to run it with screen or forever so it doesn't quit when you log out.
For common code. createServer is probably what is used to open the server itself. That is consistent between the core libraries and a lot of the frameworks. There might be another file that loads the module prior to executing so running might not work.
Related
I'm attempting to scale a Node.js application but am a little confused on one piece of it. I moved all my static files to the gateway server running NGINX, and it routes them accordingly. Now looking at the waterfall diagram in Chrome's dev tools, I notice a full second of wait time to access the socket.io javascript file. I'm assuming that is because this is still being accessed from the application server, not the web server. My question is, can I move this file to the web server to have it load faster? It's an npm module so it seems a little fishy to me, like it needs some sort of interaction with the application server to initialize the connection or something. Or am I thinking about this all wrong? Thanks!
I'm using node v6.10.0 and trying to figure out why my --debug-brk is so incredibly slow. Without this flag (with just --inspect or --debug), it's almost instantaneous, though the debugger still takes forever to attach.
This one flag dramatically increases the load time. My project is taking 50s+ to start up when debugging is enabled.
Any ideas on how to start debugging this issue?
Edit: To be clear, it's happening across two computers and does NOT happen with Hello World.
Edit 2: More detail. I'm using es6. I used webstorm to log out what was going on and found that it was just taking forever to read all my modules? Perhaps that's what's going on?
Is there a way to speed this up? It's taking 34 seconds just to load all the require statements.
Edit 3: It's absolutely the files and require statements. I moved some of the require statements to only load after the database connection is established. The connection is established instantly, but the process hangs on moving forward after that (again for several, several seconds).
Is there any way to speed this up?
What do you mean by "load time"? Are you talking about time between opening the frontend (e.g. Chrome DevTools) and hitting the breakpoint on the first line of your script?
From your description it sounds like there's an issue with the socket connection being slow. Some things to check:
If the URL your Node.js version outputs has localhost - replace it with 127.0.0.1. Some OSes use DNS to resolve this name and might fail to resolve it or to be slow.
Do you have any issues with the network access? Particular Chrome DevTools version has to be downloaded for your node version, this might be slow.
This might be a bug in particular Node.js version (I cannot recall anything specific that might've caused this). What is puzzling is that it is app specific - when you run with --debug-brk or --inspect-brk no JS is executed until after the debug frontend is connected.
Please consider reporting this issue on Node.js bugtracker - feel free to CC me directly (add #eugeneo anywhere in the bug description)... Is there any chance I could see your code - e.g. is it on GitHub? Also - can you please try a newer Node version?
I know to start my Node app I type in the Win shell, node app.js.
But this is obviously not how a webhost would maintain a Node webserver (ie what happens if there is a power outage, a Node exception, etc).
I see things like Forever and running Node as a Windows service, but I feel like the creator of Node must have had a different idea? Something like Apache is installed as a Windows Service so that it runs even if the server reboots - what is the correct method of doing this for Node? I don't like the idea of introducing another piece of software just to keep the server going.
Thanks.
The problem is that many systems do not do that. For instance MongoDB doesn't even run like that on windows.
The best solution I have found is this https://nssm.cc/
Also you have to consider even on Linux you need to run something like upstart to keep node programs running when you close the console.
So I thought about giving node.js a try seeing the possibilities it has for a little test chat project (with mysql) I'm doing.
But what I couldn't find out is where to run the file from and whats most common.
What I currently have:
A FreeBSD server with latest Node and PHP 5.3.x
A vhost
some tutorials on how to start with node (which I looked through and got exited about)
knowledge on how to run it from terminal without having to keep my terminal open (screen)
So far so good.
What I need:
Some basic information of where to put the (lets say:) chat.js file.
Most logical port to run it on
So the web root (www) runs on a user (not root obviously). And the webroot has an underlying folder where I could put the script (away from visitors grabby little hands). This seems to me to be the most safe place to put it seeing nobody can get to it, which is probably what I want seeing I'm going to connect to a db and don't want my DB login data out there (I don't know how this works yet but I'll figure out db connect with node later, no answer required).
But if a file is not in the webroot, it seems to me a connection cannot be made from outside. Cause my webroot is configured to only allow 80 (or ssl on 443) incomming traffic, which is logical. Outgoing obviously has no problems.
All the examples that I found don't really help me. They just do everything on a local machine, which sucks for me cause I don't want to do that.
So what I would like to is the best practice for:
Where to put the file
port to run it on.
What is Node.js?
A lot of the confusion for newcomers to Node is misunderstanding exactly what it is. The description on nodejs.org definitely doesn't help.
An important thing to realize is that Node is not a webserver. By itself it doesn't do anything. It doesn't work like Apache. There is no config file where you point it to you HTML files. If you want it to be a HTTP server, you have to write an HTTP server (with the help of its built-in libraries). Node.js is just another way to execute code on your computer. It is simply a JavaScript runtime.
A nice tutorial How to Deploy Node JS Applications, With Examples
You'll need to have your non-node application on port 9000 (for
Apache, this will be in /etc/apache2/ports.conf and in your
sites-available file for your site), and you'll need your node
application to listen on 8080. You'll also need to set up DNS 'A'
records for the different hostnames you'll be using for your servers.
Companies like Heroku allow for automated deployment of apps from the desktop to the cloud.
Nodejitsu provides a tool called jitsu that makes deploying an Node.js application super simple. You can install jitsu with npm.
npm install jitsu -g
Heroku How To
Getting started with jitsu
Use monit, forever, upstart or systemd to start your node server. Use Varnish or HAProxy or Nginx (Nginx not work with websockets).
Ultimately you can stick it anywhere you want. I recommend running your application using Forever or similar instead of directly with Node. I usually keep my apps in /var/ and let each one run under a unique user. I do not recommend keeping them in your http root, as your .js files are should NOT be interpreted by Apache, php, etc.
To be clear - you do NOT need a traditional webserver, nor do you need php,mySQL or anything else. Node is all you need. It'll serve content directly - it IS the webserver.
Often times you'll have each app use a high port number (3000+) and use NGINX to proxy them all to different hostnames off of port 80 (allowing you to easily have multiple apps on a single machine). If you aren't using some sort of proxy, then 3000 is very default, but there is no correct or incorrect port, so long as you don't use a reserved port.
I am trying to set up a development environment for node.js. I assumed at first that it requires something similar to the traditional, "localhost" server approach. But I found myself at a loss. I managed to start a node.js hello world app from the terminal. Which doesn't looked like a big deal - having to start an app from the console isn't that hard. But, after some tweaking, I found out that the changes aren't shown in the browser immediately - you need to "node [appName here]" it again to run.
So, my question is:
Is there a software or a tutorial on how to create a more "traditional" development server on your local machine? Along with port listening setup, various configurations, root directories etc (things that are regular in stacks like XAMMP, BitNami or even the prepackaged Ubuntu LAMP). Since I'm new at node.js, I can't really be sure I'm even searching for the right things on google.
Thanks.
Take a look at :
https://github.com/remy/nodemon
it'll allow you to do - nodemon app.js
and the server will restart automatically in case of failure.
To do this I built a relatively small tool in NodeJS that allows me to start/stop/restart a NodeJS child process (which contains the actual server) and see/change configuration option and builds/versions of the application, with admin options available on a different tcp port. It also monitors said child process to automatically respawn it if there was a error (and after x failed attempts stops trying and contacts me).
While I'm prohibited from sharing source code, this requires the (built-in) child_process module, which has a spawn method that returns a child process I guess, which contains a pid (process id) which you can use with the kill method to kill said child process. Instead of killing it you could also work with SIGINT an catch it within your child application to first clean up some stuff and then exit. It's relatively easy to do.
Some nice reading material regarding this.
http://nodejs.org/docs/v0.5.5/api/child_processes.html