3 ms·
> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app in
by nawitus 11y ago
> Run one instance of your app per core you have available and use IPTables to round robin (or whatever. you can get fancier if you feel like it) to each app instance.
But if you're using Flask and you have 4 cores with 4 instances, and you're making 4 database requests at the same time you're whole application is suddenly locked. And it's not uncommon for a single view to make up to 4 separate database requests. Most modern web applications are I/O bound, therefore a single Node.js process would have better performance here.
- ianamartin 11y agoThat hasn't been my experience. If your ACLs are set up properly, you won't encounter a full table lock, and therefore won't have problems like you described. I agree that this could be a problem in theory. In practice, it has not been. Again, it boils down to how you architect your code. EDIT: you need to stick your sessions to a specific instance. Otherwise, you are correct that there's a problem. But as long as you stick your sessions, there's no problem with a database lock.
- nawitus 11y agoI wasn't talking about database locks. My point was that making a database request takes a really long time relative to processing a request in the web application. Therefore the web application spends most of the time doing nothing and waiting for the database request to complete.
- ianamartin 11y agoSo, write data-backed applications without calling a database? Not sure what you are getting at here. If you are talking about the raw scalability of your database, yes, you are correct. The speed with which you are able to get info from your DB will be a limiting factor. But that's a totally different point than the one I was making, which was about how to scale Python, not your database. If I understand you correctly, the time spent in retrieving stuff from your database will be a limiting factor no matter what language you are using. The DB I/O will eventually limit C# or go or node.js or whatever. I really don't see how this is relevant. But since you brought it up, you can really cut down on data access times by relying less on ORMs and getting your fingers dirty with stored procedures and building tables that make sense to SQL instead of pretending everything in your RDBMS is a class.
- nawitus 11y agoNode.js can asynchronously make multiple (i.e. hundreds) database requests without locking the instance.
- mixmastamyk 11y agoWhy do you believe four requests from python would lock a database but hundreds from js wouldn't?
- dorfsmay 11y agoWait, in PROD, you don't use Python as the server, you stick uWSGI in front of python/flask, that will deal with the network I/O limitation.
- nawitus 11y agoHow does uWSGI help here? The OP recommended running 4 instances of Flask/Python, and with uWSGI you still have 4 instances. It doesn't help with I/O.
- dorfsmay 11y agoBecause with uWSGI you can mix a number of threads and processes (recommended because more processes than cores wastes time with context switches, and a low number of threads per process is a waste of cycle. uWSGi is an event loop (not unlike node) which makes dispatching requests to threads and processes very easy.
- devishard 11y agoIt has not been my experience that web applications are I/O bound using typical architectures in Python. I think you would have a very hard time arguing that Node.JS is more performance than nginx.
- nawitus 11y ago"It has not been my experience that web applications are I/O bound using typical architectures in Python." Okay, my experience differs. Most modern web applications are relatively lightweight, and are mostly "proxies" or thin wrappers between the load balancer and the database.
- devishard 11y agoThat's exactly the kind of apps I usually write, and nginx is fast enough that the DB is typically the bottleneck. In rare cases I've run into CPU as the bottleneck for computationally intensive tasks. If I/O is your bottleneck, then that indicates to me that Node.JS is actually performing worse for you on I/O than nginx is for me.