Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I am trying to make a simple server that has some heavy load processing. I am using cluster module to take this heavy load to threads and let Node make it's magic. The problem is: as I don't know how to build a thread pool, I'm afraid I might run into some trouble with pid limit.
The question: Provided that I can't change process identifier OS limit, how can I create a thread with Node that does not die (a thread that waits for a message, processes it and then waits for another message) WITHOUT using busy waiting (I want them to block while waiting for a new request)?
I can't get what you're asking for, but node cluster meant to spawn a constant number of workers (usually one per CPU core) to enable multithreading processing of your request.
Each worker works in a single thread, consuming one and only one pid. All workers share the same TCP connections, allowing requests to be distributed between them. Each worker process all request, dispatched to id, asynchronously (all at the same time) in its single thread.
Node.js designed to utilize all resources of a single CPU core by processing all incoming requests asynchronously, meaning you don't need more than numCPUs workers to utilize all your resources.
So, I cant't understand your problem with pid limit.
If you have problems configuring your cluster, see this answer and this blog post.
Summarizing my answer, properly configured cluster consists of require('os').cpus().length worker processes handling requests and one master process watching them and respawning dead ones.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 13 days ago.
Improve this question
I have a react web app which generates solutions for rubik's cubes. When the user makes a query on my site, it starts a long computation process (anywhere from 1 second - 240 seconds). Every time a solution is found, the state is changed and the user can see the new solution.
However, this app often crashes on mobile for large queries, I believe the browser is demanding too much memory and kills my page. Because of this, I want to add a node.js backend to handle the computation.
I would like for the following functionality:
When the user makes a query request, it sends that to the backend which can start computing. Every so often, the frontend can update to show the current tally of solutions.
If the user prematurely wants to cancel the process, they can do so, also killing the backend thread.
How can I set this up? I know I can very easily make HTTP requests to my backend and receive a response when it is done. However, I'm not sure how to accomplish the dynamic updating as well as how to cancel a running thread. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.
I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.
Any help is appreciated!
However, I'm not sure how to accomplish the dynamic updating. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.
Three main options:
A webSocket or socket.io connection from client to server and the server can then send updates.
Server-sent events (SSE is another way for the server to send updates to the client)
Client polls the http server on some time interval to get a regular progress report.
as well as how to cancel a running thread
If by "thread" here, you mean a WorkerThread in nodejs, then there are a couple of options:
From your main nodejs process, you can send the thread a message tell it to exit. You would have to program whatever processing you're doing in the thread to be able to respond to incoming messagessto that it will receive that message from the parent and be able to act on it. A solution like this allows for an orderly shut-down by the thread (it can release any resources it may have opened).
You can call worker.terminate() from the parent to proactively just kill the thread.
Either of these options can be triggered by the client sending a particular http request to your server that identifies some sort of ID so the server's main thread can tell which workerThread it should stop.
I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.
This means you'll have to program your nodejs server such that each one of these client/thread combinations has some sort of ID such that you can associate one with the other and can have more than one pair in operation at once.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This came up during a discussion on another spine.js question:
Since, this is significantly distinct from that question, I am upholding the "one question per post" policy of SO, by branching this off as a new question.
#numbers1311407 mentioned that
spinejs will queue the requests and submit them serially, each consecutive request being made only after its predecessor completes.
But that seems so wrong ! Why should Spine assume so much control and sequentialize all POSTS (for example) from a client ? What if the POSTS are on related URIs ? Even if Spine tries achieve some sanity by sequentializing all POSTs for each client, it still has no way of preventing concurrent and conflicting POSTS happening from different clients. So, why bother ?
But that seems so wrong !
It makes sense when you consider the design goal of spine, the realization of what MacCaw calls an "Asynchronous UI" (the title of the blog post you linked to in your related question). This paradigm attempts to eliminate all traces of the traditional request/response pattern from the user experience. No more "loading" graphics; instantly responsive user interaction.
This paradigm expects a different approach to development. Persisting to the server becomes more of a background thread that, under normal circumstances, should never fail.
This means that under normal circumstances your app logic should not be dependent on, or care about, the order or scheduling of requests by spine.
If your app is highly dependent on server responses, then spine might be the wrong library.
Why should Spine assume so much control and sequentialize all POSTS (for example) from a client ?
Because of spine's non-blocking design philosophy, your app relinquishes the flow control that you might have in another lib like Backbone, wherein you might do something like disable a "submit" button while a request is being made, or otherwise prevent users from spamming the server with non-idempotent requests.
Spine's Model#save, for example, returns immediately and as far as the client is concerned, has already happened before the server even gets the request. This means that spinejs needs to collect and handle requests in the order that they come to ensure that they are handled properly. Consider a user jamming on a "Save" button for a new record. The first click will send a POST, the second, a PUT. But the button spamming user does not know or care about this. Spine needs to ensure that the POST completes successfully before the PUT is sent, or there will be problems in the client.
Combine the order sensitivity of non-blocking UI input with the first point, that your app shouldn't concern itself overmuch with the persistence layer, and you can begin to see why spinejs serializes requests.
Even if Spine tries achieve some sanity by sequentializing all POSTs for each client, it still has no way of preventing concurrent and conflicting POSTS happening from different clients. So, why bother ?
Because the point of the solution is to give a consistent, somewhat user-error-proof UI experience to a single client. E.g. if a client creates, then updates, then deletes a record, spine should ensure that all these requests make it to the server successfully and in the proper order. Handling conflicting posts between clients is a separate issue, and not the point of the request queue.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am running some tests with WebSockets.
For the test I used the Alchemy-Websockets .NET based server.
The web application open several windows and it used to monitor different services and systems.
I am especially interested in high load situation where the server has to sends a lot
of events to the client, to reflect real time updates. I want the GUI to be fully responsive and present the data in a grid and a chart in a real time user experience.
I created the WebSocket in the main window thread, and on every incoming message I added an entry to an array that the grid is using to display (SlickGrid). To make the GUI work fine I added an setInterval of 20ms to render the grid updates, everything is working fine, very fast.
The question is whether moving the WebSocket to a worker thread is desirable or recommended. Reading about Worker threads I saw in the use cases a recommendation to handle I/O in a thread.
I think this make sense only if it is blocking.
As far as I know WebSocket is asynchronous and does not block. I read somewhere that
it is implemented in a thread internally by the browser, which makes sense.
I consider moving the WebSocket into a worker, allowing the worker to buffer or aggregate some data before moving it to the main window, In case of high event rate I see the following approaches:
The main window thread polls the worker periodically (every 20ms or so) and get the required data.
The worker sends larger chunks of data periodically.
Every time the web socket receive data, send it to the main thread - but I think it introduce the same inherent problems. (This is where I began testing, I created an infinite loop in a worker thread
and on every step I sent a message to the main thread, the GUI froze
which makes sense).
Leaving the WebSocket on the main thread is also not ideal. In case of a high load from the server, the GUI will not prioritize the WebSocket incoming message events.
Gathering data in the worker thread, seems I might miss the real time updates during high loads, since the worker is buffering.
Another issue with worker threads seem to be the data duplication, which can be solved by the newer transferable objects, not sure how well it is supported on all browsers yet.
Why not hosting the WebSocket on the main window?
So what is the best practice?
There are only two reasons to move WebSocket to Worker.
JSON.parse is blocking operation and can cause FPS loss in case of big data. Data cloning from worker adds ~1% overhead, but 99% of parsing is done in background thread.
Using SharedWorker to maintain only one connection with server.
DOM manipulation and probably drawing on canvas affects websocket packages too. I measure around 0.2ms average latency on localhost, but using the same thread I have 4-9ms spikes in regular intervals. If I don't update the DOM that frequent or move the websocket to a worker they disappear. Chrome is affected the most, Firefox is better from this perspective currently. For online gaming this can mean some sort of lag or stuttering. For me it just affects TCP latency testing somewhat. I need to increase the message sending frequency from 1ms to 100ms to get a clean chart.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Is NodeJS a good framework/codebase for a large server-side application? What I am looking to develop is a large application that will require HTTP transactions (states) and large amounts of concurrent users.
From what I've read online, NodeJS is not the best tool to use when it comes to large programs. What I've come across is as follows:
NodeJS runs on JavaScript which runs on event loops which are not very efficient when used in bulk.
NodeJS may be non-blocking, but all the requests are handled within a single thread so this can cause a bit of a bottleneck when many requests are handled.
NodeJS is built atop its own HTTP server so future maintenance will require its own sysadmin/developer hybrid to take care of the application.
There isn't as much well-tested and diverse software available for NodeJS that helps you build a bigger application.
Is there something I'm missing? Is NodeJS really as powerful as it can be?
Is NodeJS a good framework/codebase for a large server-side application?
That question is a bit subjective but I'm including actual objective points which solve real problems when working with node in a large project.
Update after working on project for awhile:
It is best as a front end / API server which is I/O bound (most front end/api servers are). If you have backend compute needs (processing etc...) it can be paired which other technologies (C# net core, go, Java etc... worker nodes)
I created this project as a sample illustrating most points - Sane Node Development:
https://github.com/bryanmacfarlane/sanenode
NodeJS is not built atop its own http server. It's built atop the V8 chrome javascript engine and doesn't assume an http server. There is a built in http module as well as the popular express web server but there's also socket modules (as well as socket.io). It's not just an http server.
The single thread does not cause a bottleneck because all I/O is evented and asynchronous. This link explains it well: http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
As far as the software module, you can search at the npm registry. Always look at how many other folks use it (downloads) and visit the github repo to see if it's actively being maintained (or is there a bunch of issue never getting attention).
Regarding "large project" what I've found critical for sane development is:
Compile time support (and intellisense): Find issues when you compile. If you didn't think you needed this like I did when I started, you will change your mind after that first big refactor.
Eliminate Callback Hell: Keep performance which is critical (noted above) but eliminate callback code. Use async / await to write linear code and keep async perf. Integrates with promises but much better than solely using promises.
Tooling: Lots of options but I've found best is Typescript (ES6/7 today), VS Code (intellisense), Mocha (unit testing).
Instrumentation/Logging: Getting insights into your app with tracing and instrumentation is critical.
Build on well vetted frameworks: I use express as an example but that's a preference and there's others.
Node.js is a very good tool to build distributed network services. What is your large scale application design is more than a question 'which tools to use'. A lot of people use node.js in a very heterogeneous way together with ruby, php, erlang, apache & nginx & HAproxy. If you don't know why you need node you probably don't need it. Possible reasons to consider node:
you want to share common Javascript code between server and client
you expect highly concurrent load (thousands to hundreds of thousands simultaneous connections per server)
you (or your team) is much more proficient with JavaScript than with any other available language/framework
if one of 7600+ modules is implementing large portion of required functionality
One "issue" with NodeJS, is that building a large application requires discipline on the part of the developer / team.
This is particularly true with multiple teams within the same company. Existing frameworks are a bit loose, and different teams will come up with different approaches to solving an issue.
KrakenJS is a framework, built on top of express. It adds a layer of convention and configuration that should make it easy(er) to build large projects, involving multiple teams.
Really NodeJs is powerful in its own way, Some more information,
You can run multiple instance of your app under load balance to handle massive request.
Choose NodeJs to read 2000 files instead calculating 20th prime number.
Put NodeJs busy with reading/writing in files or ports.
Very useful when you need to broadcast your response to multiple client.
Don't care about dead lock in NodeJs, But care about how frequent you are doing same operation.
Most important thing is, the values live in V8 engine until the process is terminated. Be sure how much lines of code, you are going to feed in NodeJs.
I find the most important thing is to use CPU time as least as possible. If your application needs to use CPU intensively, event loop latency would increase and the application would fail to respond any other requests.
So far as I have learned, It's the raw speed and async await that makes the biggest difference.
For those who are moderately skilled in Javascript and particularly understand REST as well as the above mentioned aspects, node.js is one of the best solutions for big enterprise applications.
Correct me if I am wrong, but even using raw express (without those frameworks built on top of it ) is actually good enough if teams agree on certain conventions and standards to follow.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am looking for real-world scenarious for using Web Workers API.
John Resig (of jQuery fame) has a bunch of interesting examples of using web workers here - games, graphics, crypto.
Another use is Web I/O - in other words, polling URLs in background. That way you don't block the UI waiting for polling results.
Another practical use: in Bespin, they’re using Web Workers to do the syntax highlighting, which you wouldn’t want to block your code editing whilst you’re using the app.
From Mozilla: One way workers are useful is to allow your code to perform processor-intensive calculations without blocking the user interface thread.
As a practical example, think of an app which has a large table of #s (this is real world, BTW - taken from an app I programmed ~2 years ago). You can change one # in a table via input field and a bunch of other numbers in different columns get re-computed in a fairly intensive process.
The old workflow was: Change the #. Go get coffee while JavaScript crunches through changes to other numbers and the web page is unresponsive for 3 minutes - after I optimized it to hell and back. Get Back with coffee. Change a second #. Repeat many times. Click SAVE button.
The new workflow with the workers could be: Change the #. Get a status message that something is being recomputed but you can change other #s. Change more #s. When done changing, wait till status changes to "all calculations complete, you can now review the final #s and save".
I have used them for sending larger amounts of data from the browser to server. Obviously, you can do this with regular AJAX calls, but if this takes up one of the precious connections per hostname. Also, if the user does a page transition during this process (e.g clicks a link), your JavaScript objects from the previous page go away and you can't process callbacks. When a web worker is used, this activity happens out of band, so you have a better guarantee that it will complete.
Another Use case:
Compressing/De-compressing files in the background, if you have a lot of images and other media files that are exchanged from the server in compressed format.