I am creating a real-time server to handle many parallel request from clients.I have read articles about multi-threading and multiprocessing with their own pros and cons but I am confused what should i use.
my server will accept request from client, parse its request header and do database query and such stuffs afterwards.
So should I use multiprocessing, where I create new process to handle each client request or just threads would be fine.
Also their can be possibility of heavy traffic.
Related
I need to write a load test for a web application which uses the WebSocket protocol for sending some server states to users and in parallel users send requests with data from this server state.
I need a socket client which will listen to the socket and update the current server state and at the same time need to send HTTP requests with data from the current state.
Can implement it on Apache JMeter? If yes may you know some useful articles (not about BlazeMeter parallel controller) or examples?
Or can you advise some tools which better for this target and which can generate a concurrent load of at least 20k users (currently use Jmeter cluster)? Thank you in advance!
One JMeter thread (virtual user) can only execute one Sampler at a time, if you need to run 2 requests at the same moment you need to either need to use 2 different Thread Groups or if you prefer to stay with 1 thread group you can use i.e. If Controller so "even" users would run HTTP requests and "odd" WebSocket or vice versa.
If you need to pass data between threads (virtual users) either use JMeter Properties or Inter-Thread Communication Plugin
I read that a Go application receives connections directly from clients using a built-in web server, not running behind a web server such as Apache. Also, I read network servers, such as Apache, deal with incoming requests using multiple processes created by fork().
Is this also true for a Go application, or does it operate on a single process and handle incoming requests by multiple threads?
Go applications typically use the net/http package to implement a web server. The documentation for that package says:
Serve accepts incoming HTTP connections on the listener l, creating a new service goroutine for each. The service goroutines read requests and then call handler to reply to them.
Goroutines are scheduled on one or more OS threads.
The package does not use fork.
Does node.js is create an instance of a node.js for each client, or there is only one instance of node.js server for a whole variety of clients and unique instances created only for paths for each client ?
Nodejs doesn't create a new server instance for each client, neither do other options out there.
You're probably thinking of multithreading as traditionally multithreaded web servers create a new thread for each client request, however since node.js runs JavaScript which is single threaded the answer is no - every client request is handled by the same single thread.
That is why Node.js and JavaScript are often associated with the word blocking referring to the fact that if you write code that takes a long time to complete, it will block all the other users from getting served. You don't however have to worry about blocking when performing I/O since Node.js (JavaScript) is asynchronous - meaning that client requests won't block each other when performing I/O operations such as network requests or disk reads.
To read more on Node.js being single threaded, see this S/O answer: Why is Node.js single threaded?
I am building a web app which has two parts. In one part it uses a real time connection between the server and the client and in the other part it does some cpu intensive task to provide relevant data.
Implementing the real time communication in nodejs and the cpu intensive part in python/java. What is the best way the nodejs server can participate in a duplex communication with the other server ?
For a basic solution you can use Socket.IO if you are already using it and know how it works, it will get the job done since it allows for communication between a client and server where the client can be a different server in a different language.
If you want a more robust solution with additional options and controls or which can handle higher traffic throughput (though this shouldn't be an issue if you are ultimately just sending it through the relatively slow internet) you can look at something like ØMQ (ZeroMQ). It is a messaging queue which gives you more control and lots of different communications methods beyond just request-response.
When you set either up I would recommend using your CPU intensive server as the stable end(server) and your web server(s) as your client. Assuming that you are using a single server for your CPU intensive tasks and you are running several NodeJS server instances to take advantage of multi-cores for your web server. This simplifies your communication since you want to have a single point to connect to.
If you foresee needing multiple CPU servers you will want to setup a routing server that can route between multiple web servers and multiple CPU servers and in this case I would recommend the extra work of learning ØMQ.
You can use http.request method provided to make curl request within node's code.
http.request method is also used for implementing Authentication api.
You can put your callback in the success of request and when you get the response data in node, you can send it back to user.
While in backgrount java/python server can utilize node's request for CPU intensive task.
I maintain a node.js application that intercommunicates among 34 tasks spread across 2 servers.
In your case, for communication between the web server and the app server you might consider mqtt.
I use mqtt for this kind of communication. There are mqtt clients for most languages, including node/javascript, python and java. In my case I publish json messages using mqtt 'topics' and any task that has registered to subscribe to a 'topic' receives it's data when published. If you google "pub sub", "mqtt" and "mosquitto" you'll find lots of references and examples. Mosquitto (now an Eclipse project) is only one of a number of mqtt brokers that are available. Another very good broker that is written in Java is called hivemq.
This is a very simple, reliable solution that scales well. In my case literally millions of messages reliably pass through mqtt every day.
You must be looking for socketio
Socket.IO enables real-time bidirectional event-based communication.
It works on every platform, browser or device, focusing equally on reliability and speed.
Sockets have traditionally been the solution around which most
realtime systems are architected, providing a bi-directional
communication channel between a client and a server.
This is more of a design question rather than implementation but I am kind of wondering if I can design something like this. I have an interactive app (similar to python shell). I want to host a server (lets say using either node.js http server or socket.io since I am not sure which one would be better) which would spawn a new child_process for every client that connects to it and maintains a different context for that particular client. I am a complete noob in terms of node.js or socket.io. The max I have managed is to have one child process on a socket.io server and connect the client to it.
So the question is, would this work ? If not is there any other way in node to get it to work or am I better off with a local server.
Thanks
Node.js - is single process web platform. Using clustering (child_process), you will create independent execution of same application with separate thread.
Each thread cost memory, and this is generally why most of traditional systems is not much scalable as will require thread per client. For node it will be extremely inefficient from hardware resources point of view.
Node is event based, and you dont need to worry much about scope as far as your application logic does not exploit it.
Count of workers is recommended to be equal of CPU Cores on hardware.
There is always a master application, that will create workers. Each worker will create http + socket.io listeners which technically will be bound to master socket and routed from there.
http requests will be routed for to different workers while sockets will be routed on connection moment, but then that worker will handle this socket until it gets disconnected.