Recently I hosted my database on MongoDB Atlas. My API is hosted on Vercel and it’s built with Next.js so my api routes are serverless functions. I’m using this code for database connection. (it’s official code suggested by Next.js team).
However at peak times when a lot of users use the website at the same time I can see up to 35 active database connections (many read/write operations). Is this something normal? Shouldn’t connection count always be 1?
Thank you so much for your help!
Connection amount picture
As you're dealing with a serverless solution any concurrent requests will be served from different instances, so you'll have more connections than you would if you had a well configured server based solution.
As a result you will not be sharing the connection to the database between concurrent connections.
How sequential connections are handled can vary, I'm not certain how it works with Vercel, but with AWS Lambda you can reuse a connection in a subsiquent request.
Related
My Flask API on Heroku has many endpoints that runs queries on my Heroku PostgreSQL database before returning the jsonified results to the client.
My current plan is a Hobby Basic tier, so the database can handle only 20 connections maximum.
If I set the --workers in gunicorn to something like 17, it works fine and I can handle about 1000 users sending two HTTP requests each at the same time.
But if I want to scale my API up to be able to handle a large userbase, how do I do so? 1000 concurrent user requests have a good response time with an average of 2.5s, but if I bump it to 2000 or above, it goes above 7s and such.
Using the current Basic tier, how can I efficiently make use of what I have? I have heard of Connection Pooling, will this help?
If the only way to scale up would be to pay more, how should I do it? Would it be as simple as upgrading the Database tier to Standard, and upping the workers to 100+?
I've created a few apps which utilize a postgres database, but in all of those projects, I've either used the pool or client function from the pg npm package. Recently I came across the pg-promise node package, and was just wondering if there were any drawbacks to using pg-promise over pool or client. I'm just worried about changes in runtime that would affect how many clients the app could service at one time.
pg-promise is "Built on top of node-postgres". You're still using the same pools and clients.
Nothing changes regarding the amount of connections your database will be able to handle, and unless you use a different approach to building your application (like, using transactions instead of not using transactions, or using individual clients instead of pooling), nothing will change regarding the amount of clients your app will be able to serve.
I currently have a small website hosted on AWS.
The server is a micro-instance.
On this micro-instance:
I am running nginx to serve static files and error pages
I am running my node server
I am storing my mongoDB
As the website is getting more traffic, I reached the time where I need to scale, and I am not sure what the best-practices are and what are the implication of each.
I would love any referrals to reading materials
I was thinking of having:
2 dedicated micro-instances to run the website
1 micro-instance running nginx
1 micro-instance storing the db
questions:
Would having the db stored on a separate machine make the queries
significantly slower?
Should I in fact store the db on S3 instead?
Is it justified to have an entire instance for nginx alone?
How would you go about scaling from 1 machine to multiple ones? I am guessing moving from one to two is harder than moving from two to 50.
Any advice will be greatly appreciated!
Would having the db stored on a separate machine make the queries significantly slower?
No, the speed impact would be very minimal, and this would be needed for scalability anyway. Just make sure you use the private IP addresses of your instances for any inter-instance communication so that the traffic stays inside your VPC (for both security and performance reasons).
Should I in fact store the db on S3 instead?
No, that wouldn't work at all. You can't store a DB on S3, only DB backups.
Is it justified to have an entire instance for nginx alone?
If you are getting enough traffic, then yes absolutely.
How would you go about scaling from 1 machine to multiple ones?
In general you need to move your DB to a separate server, create multiple instances of your web server, and place a load balancer in front of them. If you want automatic scaling based on traffic then you would also place the web servers in an auto-scaling group. If all this sounds difficult then I would recommend looking into moving your web servers into Elastic Beanstalk which will manage much of this for you.
If your database is a bottleneck then you might also need to setup a MongoDB cluster and balance the load across the cluster. You could also move your DB to something like mlab which would greatly ease the management of that as well.
I have one standard web dyno and worker dyno connected to the same standard 0 database.
The worker dyno runs background jobs that insert a lot of data into the database. I feel like I have noticed slower response times while browsing my site when the workers are running.
I'm always well below the 120 connection limit. Am I imagining this or does it have an impact on read time? If so, how do people mitigate it?
From the database's perspective, there is no difference between connections originating from the web dynos and worker dynos; they're both just clients of the database.
If your worker dynos are doing heavy inserts all the time, then they could certainly impact query performance as this places a lot of load on the database; how this impacts your web response times is specific to your particular application.
I would recommend starting by looking at Heroku Postgres tools for database performance tuning.
https://devcenter.heroku.com/articles/heroku-postgres-database-tuning
Without knowing more about your application I would say you could start with looking at the slowest queries related to your web requests and compare them to query time with and without the workers enabled.
For putting together a site from scratch, what are the advantages and disadvantages of using external database services, e.g. MongoHQ, Amazon RDS?
Advantage: you don't have to fix it yourself when it breaks.
Disadvantage: you can't fix it yourself when it breaks.
My take on this is simple:
If you have an application hosted on Amazon then you should go for Amazon RDS or MongoHQ(which also is hosted on Amazon). The rational is, since both your application and the database are on the same network (internally) you will get a significant performance advantage.
If your application is hosted else-where then go for a local install.
a couple more points
for
do not have to administer the Hardware
I guess they take care of security, software updates of the server (Software admin)
saves room. you do not have to find room in your building for a database cluster
disadvantages
depending on your internet speed, the speed you transfer data can be affected. if the application and data are in the same network you could say that you have 1gbit speed vs a 50mbit internet connection. times this by 1000 concurrent users?
you have to work to their release schedule. if you use a 3rd party and they update the database version which has a breaking change. You will be forced you update. if you host it yourself this upgrade will be under your terms.