I'm looking for a simple way to know how many records are being created by my Node.js analytics service. I came across average-requests-per-minute Express middleware, but the author says:
Disclaimer: it's very simple, trivial, keeps things in memory, and does not verify all the parameters. It is not tested well (yet), so use at your own risk.
That makes me not event want to use that module in development...
What is a simple way to calculate average requests per minute in an Express app, managed by pm2, ran on EC2?
You can try pm2 custom metrics.
Related
I am building a Node application that has a front end standard API for a SPA and a backend service that is constantly polling another API, I am going through the Node documentation in regards to clustering, forking and workers and am a bit confused and am unable to come across anything that adequately addresses the question I have.
I would like to have the 2 different API's on 2 different server cores but use the same codebase. I have experimented with 2 node entrance files app.js and app1.js both work just fine on the same server, but this was a very very simple implementation.
Is this wise to do? As stated above I will need to have the same codebase available for both services to perform business logic.
I am having a hard time finding examples or envisioning what this would look like, would I just do the 2 app.js entrance files? What about getting these services on different processor cores? Is this possible? I am assuming I could communicate between them using IPC? But do I use clustering? Forking?
A quick and simple example would be very useful as I am still pretty new and this is very advanced for me at this stage but I just need a small boost in how to get this rolling. Thanks for any help.
I built a SaaS API in NodeJS (Koa) I would like to implement two types of monitoring. First one is a general monitoring of the API that would include CPU usage, error rates, latency, etc. In the second one I am interested in how many unique visits certain API route had. This will be returned to a user using some other API route.
I have tried swagger-stats which seem to fit my purpose when integrated with elastic search. Are there any other monitoring packages?
i can recommend pm2. it is convinient process manager. then, it support monitoring, and logging you can setup by use 'npm install pm2 -g',
if you want to more information, go to http://pm2.keymetrics.io/.
it is very useful me, i hope that you too!
I am planning to build a nodejs application as back end of a web application.
This server application will provide a rest api, websockets service and process to scrape some sites with a headless navigation (like zombie.js) each n hours to feed a database.
I would to ask if it's a good approache build all the things in one nodejs instance or if it's better use several nodejs applications for every task.
If you are having small size application (which doesnot require scale in future), you can keep all the stuff Rest, Socket, scraping on the same project).
Note: After scraping if you are processing HTML content, it will take some time to process that in Sync manner. So at that time event loop will be blocked. So Rest API will not handle any request. In this scenario, you can keep Rest and Socket combinely in one project and Scraping thing in another project.
If you are planning to scale in near future, I suggest to Keep Seperate Instance, considering Benefit of SOA in scaling.
In my opinion better way is using different Node.js applications. First one will server your API. Another one will work as a socket server on different port.
About scraper it can be PHP (as well as nodejs) script which will run as a cron job. How to setup cron job you can check this question:
https://askubuntu.com/questions/2368/how-do-i-set-up-a-cron-job
or this tutorial for Ubuntu server: https://help.ubuntu.com/community/CronHowto
I think it will be best approach.
I'm finishing up building my first site with node.js and I'm curious if there is a checkoff list for all the things that I should complete before I get it up. In development when certain values are not expected in my database calls, (using Mongoose), my site will just die (e.g. node segfaults).
I'll also be using this on a VPS of mine that already have Apache installed on it, so will I be able to run both or do I need to look into something else for that?
Basically once it's up, I want to keep it up, and I'd like to know of any standard precautions I should know of before doing so.
Thanks!
I'm currently in a similar situation (about to deploy my first app on a private VPS), and here is the list I came up with:
1- Error logging: I used a simple WriteStream here, nothing too fancy.
var fs = require('fs');
//You might want to specify a path outside your app
var file = './log.log';
var logger = fs.createWriteStream('./log.log');
app.configure(function(){
//...
app.set(express.logger({stream:logger}));
/...
});
2- Use Forever to ensure that your script will run continuously. Yes, they are plenty of other solutions (using a daemon, for example), but I've been using forever for a while now, and never had any problems.
3- Consider setting up an admin interface. This was actually a requirement in my case, so I went ahead with smog, which will look very nice, especially for your client :).
4- If you use forever, you can monitor its state using Monit. Check out this blog post for a basic setup.
5- If you are using Mongo, consider developing a backup strategy of your data. This page is a very good starting point.
Note that this list does not contain any information regarding multi-app, multi-machine or multi-core support.
If multi-app support interests you, nginx seems to be a trusted solution. This (brilliant) SO answer will help you get set up.
If you have many spare machines to use, node-http-proxy was developed by nodejitsu, and allows you to expose only one machine and reverse-proxy the rest.
If you are looking for multi-core support, cluster comes bundled with node, so you can spawn N different processes (N being the number of cores you have) and have them listen to the shared port.
And, since we all love to hear a nice story, here a few posts about nodejs/mongodb use in production and the lessons learned:
1- Lessons learned from launching i.TV
2- Using Mongodb for 2+ billion documents on craigslist
Given that Node.js is not a web server like Apache or IIS, there's no checklist of configuration settings to follow. Also, given that the modules and/or frameworks you use can vary widely based upon the project you are creating, checklists would always miss something...especially as the Node.js ecosystem continues to evolve and grow.
As such, I'd suggest reviewing the material here as they answer your questions and are generally useful no matter what you are doing with Node.js:
What should every programmer know about web development? - list you should run through to be sure you didn't forget anything generally relevant.
Node Express Mongoose Demo - example code that can show you how to handle errors gracefully, structure your code, use require statements to break up code, add environment-specific configuration, etc.
Node.js Best Practice Exception Handling - additional info on handling problems
Apache and Node.js on the Same Server - the most simple answer is "sure, just make sure you are using different ports". If you want both to run and answer on port 80, then things are more complicated.
I am concerned that your app dies "when certain values are not expected in my database calls".
Mongoose is a nice tool because it allows for custom data validations on individual fields, can filter out data that doesn't fit into the Schema you have defined (keeping your documents consistent), and with the right settings can throw errors when there is 'bad data' passed to it rather than send bad data to the database, and more...
I'm wondering what you are doing that an unhandled error is making it pass Mongoose and past any callback function knowing that callbacks usually take the format function(err, data) and present the opportunity to deal with the error immediately.
I have a question - does anyone has any benchmark data re. using Express JS framework vs pure Node.js?
Is this something that even should be considered -- or using Express or similar framework is definitely a MUST if you're building a more or less large web app?
EDIT:
The article I linked to below disappeared, and I couldn't find it after searching around a bit. However, in lieu of that, here are a couple of relevant references with sufficiently scientific benchmarks:
https://github.com/koajs/koa/blob/master/docs/koa-vs-express.md#is-koa-faster-than-express
http://serdardogruyol.com/?p=111
http://qzaidi.github.io/2013/07/20/surprises/
Although this doesn't answer the delta part of your question, there's some absolute statistics about ExpressJS performance here:
Updated Link
http://blog.perfectapi.com/2012/benchmarking-apis-using-perfectapi-vs-express.js-vs-restify.js/
Looks like, on a small Amazon instance, Express averages:
a very respectable 1,600-1,700 requests per second
Express is a convenience wrapper around node.js, and should not add much latency to your server; your code would probably go through many of the same steps anyway. That being said, if your load tests (or hapless customers) find the server is too slow and/or not scalable, then you should profile at that time, and the bottleneck probably won't be Express.
BTW, even though Express calls itself "high performance", they're naughty for not posting measurements.