I built a lightweight Python/Flask web app for an upcoming local conference. It mainly performs CRUD operations with a little computation when retrieving query results. Around 500 people may use it throughout the event, although I estimate roughly 20–30 concurrent requests during busy periods. I currently have it running on a small personal AWS setup with a CloudFront URL, but I'm not sure whether the instance, database, or application server is configured appropriately.
What kind of hosting and infrastructure would be sufficient, and how should I test it before the event? I'm considering Gunicorn and would especially appreciate advice about handling traffic spikes, database concurrency, response times, and realistic load-testing tools. I can arrive a day early, so I may be able to test it on the venue's Wi-Fi as well.
3 Answers
Use a real load test before the event rather than guessing. k6 and Locust are both good options; Locust may feel natural since it’s written in Python. Exercise the actual endpoints, especially the slowest page and any write operations, then ramp up to around 30–50 concurrent users and include short bursts to imitate people arriving between sessions.
Watch the error rate, p95 response time, CPU, memory, and database performance. If errors remain at zero and response times stay comfortably low under the spike, you’re probably in good shape. Five hundred users over a whole day is very different from five hundred simultaneous users.
Gunicorn should handle 20–30 concurrent requests for a lightweight app, but remember that synchronous workers handle one request at a time. A modest threaded setup could look like `gunicorn -w 3 -k gthread --threads 4 app:app`, adjusted based on your memory and measured results. Don’t add workers blindly; too many can make a small instance worse.
The conference network may be a bigger practical risk than the server. Test from a phone on the venue’s guest Wi-Fi during setup, ask the event’s IT staff about capacity and restrictions, and have a fallback such as cellular access if possible. Also make sure you have backups, logging, health checks, and a simple way to restart the service before event day.
For this amount of traffic, your Flask app itself probably won’t be the bottleneck. A small AWS instance with Gunicorn should be enough, especially if requests are quick. You can put nginx in front to handle static files and leave CloudFront for static assets. Don’t cache dynamic CRUD responses unless you’re certain the data can be stale.
The database deserves more attention. If you’re using SQLite, concurrent writes can lock the database and cause requests to wait or fail. PostgreSQL is a safer choice if several attendees will be submitting data at once. A managed database reduces the amount of operational work, although it costs more.
The sudden bursts are what worry me most, so I’m planning to test shortly after the venue opens and between sessions rather than only running a steady load test.