I built a lightweight Python/Flask web app for a local conference. It mainly performs CRUD operations with a small amount of computation when retrieving query results. Around 500 people may use it during the event, with an estimated 20–30 requests happening concurrently, possibly in bursts when sessions end.
I currently have it running in my personal AWS account with a CloudFront URL, but I'm inexperienced with deployment and infrastructure. I'd like to know whether Gunicorn and a small instance are enough, what database setup would be appropriate, and whether I should put Nginx or another service in front of the app. I'm especially concerned about response times, database locking, and avoiding an outage during sudden traffic spikes.
What load-testing tools and test scenarios would you recommend? I'm willing to arrive early and test from the actual venue network. I'm looking for practical advice that will help me validate the setup without overengineering it.
4 Answers
Use a straightforward load test against your real endpoints. Locust is a good fit if you already know Python, while k6 is also easy to learn. Start with normal traffic, then ramp up to 30–50 concurrent users and include short spikes rather than only testing a steady stream.
Track the error rate, p95 response time, CPU, memory, and database behavior. Test the heaviest page separately, especially the endpoint that performs the most queries or computation. If errors remain at zero and p95 latency stays comfortably low, you probably have enough capacity. You don’t need an elaborate performance-testing system for this event.
Twenty or thirty concurrent requests is not much for a lightweight Flask app. The database is more likely to cause trouble than Gunicorn. If you’re using SQLite, concurrent writes can lock the database file and make requests wait or time out. PostgreSQL is a safer choice, especially through a managed service.
For Gunicorn, keep the worker count modest and match it to the memory available. Something like `gunicorn -w 3 -k gthread --threads 4 app:app` can handle quick requests, but measure rather than assuming those exact settings are ideal. A small instance with around 2 GB of RAM should be more than sufficient if the database is separate.
Good point about SQLite. I had been thinking mostly about the application server, but concurrent writes and the slowest database query are probably the areas I need to check first.
For this amount of traffic, a small AWS instance should be plenty. The main benefit of managed services is reducing the operational work you have to handle yourself, so a managed database and simple hosting setup may be worth the extra cost. Keep the architecture boring: Gunicorn behind Nginx, static assets through CloudFront, and dynamic CRUD requests sent directly to the application. CloudFront won’t help much with uncached dynamic API responses.
That makes sense. I’m going to focus on a simple managed setup rather than trying to build every infrastructure component myself.
Don’t overlook the conference network. The venue Wi-Fi may be slower or less reliable than your server, and it can easily become the real bottleneck. If possible, test from a phone on the guest network during setup and ask the event’s IT staff about expected capacity. Also have a backup plan, such as letting users switch to cellular data or providing a simple fallback if the network is overloaded.
About capacity: 500 users over a full day does not mean 500 simultaneous users. One properly configured small instance should handle your estimate, provided the database and slow queries are under control.
I hadn’t considered the venue network seriously enough. I’ll arrive early to test there and treat that as part of the deployment validation.
The burst testing advice is especially useful. I’ll test what happens when many users arrive at once instead of only simulating a smooth increase.