Are there best practices for testing nodejs application performance?
I'm guessing they could fall under many different types of testing (load, speed, stress). I'd like to do all of the above to find weak areas of my API and/or bits of code that are slow, maybe find some areas that can be done in parallel. Are there packages for this? I've found loadtest which looks promising.
Also, I'm using Heroku for deployment, so if there's any heroku-specific stuff out there, that would also be appreciated. I know they scale automatically with the dynos so that shouldn't be an issue. Anyway, any pointers would be appreciated, I've never had to test much in a node app before besides unit tests.
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'm wondering if some of you veterans could provide some guidance to some of us noobs.
Is there any advantage to writing vanilla Node over using Express? More specifically, any particular scenario where using Express will not be an option? And lastly for the tasks that you can use Express for, how deep should you go within the layers of abstraction to find out what's going on?
I mean there are plenty of people who can create robust and powerful web applications and they have no clue what the hell Express is actually doing for them.
Much appreciated
If I were you, I'd use express.
To be honest, Express isn't much of a web framework. It's really barebones, and barely adds any functionality on top of Node core.
With this said, however, there are some benefits:
For better or worse, express has become the 'defacto' default web framework for Node developers. There's a lot of information about it.
Express provides some core things that are useful: a routing layer (to map functions to URLs), an 'application' object that you can bind variables to for settings, etc. -- and a simple middleware model that lets you add functionality to your app easily.
Because express is so close to 'barebones' node, you can still write raw node code to work with it. It isn't at all complicated like other 'larger' frameworks: django, rails, etc.
There are a TON of third-party express middlewares you can use which add all sorts of functionality to your site. This makes building your site easier.
Finally -- the biggest reason to use express is that it does almost nothing. It isn't significantly different from using raw node except that it provides some simple abstractions over lower level stuff.
Because express is so simple, it means you don't need to learn much to use it, and can write your app in whatever way you want (it doesn't enforce any sort of patterns).
I'd like to add a few things here that might help you out. One thing that I have come to realize with software engineering is that there is never a "catch all" answer to a lot of these types of questions. Since each application is different, it is a good idea to look at the challenges and figure out what is the best tool for the job.
If you look at some of the performance tests done on the frameworks you notice that vanilla node is ultra performant. But most of the time your application isn't going to need to handle 8000 requests per second, and even if it does you can always scale your server horizontally nowadays. So you trade off a little bit of speed to gain a few benefits, such as:
Much easier to write.
The code base, in my opinion, is much easier to maintain.
A lot of the little gotchas are taken care of by the framework so you don't have to be a Node.js god.
Middleware.
Now, that doesn't mean that every single application should use express. A lot do because it is about as barebones as it gets. For instance, Walmart created Hapi because they claim that it is easier to maintain their code base with a 'configuration first' approach. So maybe if you are going to have this monster backend and a monster team, Hapi might be a good choice. If implementing something with real-time you might want to use something like socketcluster.io to help you scale websockets. It is all about picking the right tool for the right job.
That being said, there are advantages to building a server with vanilla Node, especially when learning to develop node apps. Since frameworks abstract a lot of the lower level stuff it takes away the opportunity to pick up some cool node tricks here or there. Or a lot of times if a framework is insufficient or an npm package is doing something weird it is good to have that knowledge of vanilla node under your belt to really understand what is going on. Having the skill of knowing how Node.js works is such a benefit when working with any framework.
I'm working on a quite large nodejs code base which have been refactored and migrated from legacy to new service version several times and I highly suspect that some code is not used any more.
This dead code is still well tested, but I would like to get rid of it.
I had the idea to run 1 API server using Istanbul, put in in the production pool for some time (few minutes/hours/days) and see what code is actually useful (and identify probable dead code).
According to its documentation, Istanbul cover can handle long-lived processes, so this seems not to be an issue.
My concern is about memory overhead and potential slowness due to the instrumentation of the code, and more globally any thoughts, feedback and recommandation about getting code coverage based on real traffic would be very helpful.
Thanks!
Your best bet to do what you want would be to run your app on
SmartOS, OmniOS or some other illumos/OpenSolaris distro and use DTrace.
See:
http://dtrace.org/blogs/about/
https://en.wikipedia.org/wiki/DTrace
https://wiki.smartos.org/display/DOC/DTrace
I have an API written in PHP, which works with nodejs sockets. I want to test this project with PHPUnit or codeception. How to do it? What is the best way to do it? I didn't found any documentation.
PHPUnit is a unit testing framework, it doesn't really care what are you testing with it as far as it's independent blocks of PHP code, i.e., whether it's API or not, PHPUnit doesn't care. Documentation and how to get started is available here. Besides the official docs and tutorials there are gadzillions of other great resources, like this one. Codeception has a dedicated section in the docs on how to test APIs.
If this is the beginning of your testing life, you will find it much easier following the general documentation from bottom to the top and then looking at more complex stuff, like testing APIs, etc. Be ready, as this is likely to take some weeks before you can get the head around with both frameworks.
My question is rather straightforward. I started developing quite a large project and realized that node.js COULD be a viable solution. Since I am still new to node and therefore not in the position to determine if it's the right thing for me, I decided to ask here.
The project: It's basically an administration solution for gameserver providers. It includes both a web administration panel as well as server components to control everything.
My doubts are if I should use node for the panel.
It will require life updating of data (where sockets could come in handy) and we plan on developing it as a "one-page" kind of app.
Having it node means it would be able to perform tasks asynchronously and on it's own (instead of, say, php and cronjobs)
It will be distributed. Making it node would make this easy. No dependencies besides node, and a simple "npm install".
It will have multiple people connecting to it and using it at the same time.
Will node be able to handle these multiple connections well? Performance wise, will it be a good choice?
Will node (and maybe Derby) suffice to build a good web panel?
Am I right about any of the points I made, or did I miss something?
Thanks for the help!
Sincerely
-Antariano
Well you did answer yourself for some of the questions. Thanks to the asynchronous tasks node can take quite a load of connections so it should handle your app. I don't know Derby, but express is also good for your task.
Also when one node server will be insufficient you can always deploy next one and just create some communication between them. Since node is lightweight it can do the job.
Will node be able to handle these multiple connections well?
Yes.
Performance wise, will it be a good choice?
Yes.
Will node (and maybe Derby) suffice to build a good web panel?
Yes.
Am I right about any of the points
You are right with all of them.
I think node will be sufficient for this job.