Giovanni Barillari

I guess I'm back to blogging.
blog.baro.dev/p/why-mark-s...

Release Granian 2.5.0 · emmett-framework/granian What's Changed New features Human-readable CLI duration arguments (#622 by @3ok) This allows CLI arguments like --workers-lifetime 6h Workers memory usage limiter (--workers-max-rss option) Uni...

Yo! Granian 2.5 is out, now with memory limits for workers and UDS support 🚀 Check it out @ github.com/emmett-frame...

I'd say it really depends on what kind of programming you do.
Prototyping stuff? Sure
Boring things? Hell yeah
Building libraries and tools used by others? Meh
Existing 10k+ lines codebase? Definitely not
Also: how much productivity you trade now for later maintenance?
Open coffe/beer in vie ;)

How many threads? You mentioned long queries, but what's the expected concurrency on the database? To me 10 processes x N threads per container sounds a bit too much. I'd say all those threads will spend a bunch of time fighting each other for CPU time..

Yeah, I never got the point of a2wsgi. At the end of the day it is a wrapper, so you spend more CPU cycles in the translation layer with very few benefits – the network part of the request response is async, but everything is still blocking and running in a single thread.

Uvicorn does ASGI only, so that part feels strange too. The post seems to imply it also switched from WSGI (uwsgi) to ASGI (uvicorn). But given Django is not exactly designed for ASGI it feels weird.

Granian maintainer here.
Curious about how you configured Granian, feels strange to me that delivers worse perf than uwsgi.

You might want to check out Granian, usually the CPU usage is ~10-40% lower compared to uwsgi 😉

I'm not a CPython core dev 🤷‍♂️
But again, just 'cause that happens with gunicorn, doesn't necessarily mean the same for Granian. Sure if the leak is within the app, there's nothing I can do. But in Granian everything which is not your app is allocated in Rust, not Python.

To be clear: I don't think max-requests is always a bad idea. In fact, it might be added in future versions.
What I'm saying is that:
- restarting a worker (and thus a whole Python interpreter) every 2048 reqs is just a huge waste of CPU cycles
- it won't help you with scaling. Ever.

If that's the case, then you need to control the amount of concurrency to avoid memory saturation, but there's no need to restart the worker if you're not leaking memory.

I disagree. The number of processed requests is not a good metric to understand how much memory you're using. Unless you have just 1 route. You're basically guessing the memory impact, as you don't really know which requests cause the memory rise/leak.

So what you actually need is a max-rss feature, not the max-requests one, don't you?

If you need to scale workers based on the number of requests per unit of time, having the max-requests option won't help though.
I'd probably use containers and an external orchestrator driven by a load balancer metrics for that.

I was pointing out my comment on that issue that suggests using max-lifetime instead.
For the records, on some wsgi services in prod we saw memory usage becoming stable after the switch to Granian, maybe that would be the case also for you and you won't need to restart the workers at all!

Support `max-requests` and `max-requests-jitter` config parameters · Issue #34 · emmett-framework/granian One of the common problems with Django apps is memory leaks. The most common suggestion is to allow the webserver to cycle processes after serving some fixed number of requests. This bypasses memor...

github.com/emmett-frame...

"I am, even more reluctantly, exposed to genAI Discourse every damn minute of every damn day. It is relentless, inescapable, and exhausting."
blog.glyph.im/2025/06/i-th...

The Era Of The Business Idiot Fair warning: this is the longest thing I've written on this newsletter. I do apologize. Soundtrack: EL-P - $4 Vic Listen to my podcast Better Offline. We have merch. Last week, Bloomberg profiled ...

This is *very very* long.
But also *very very* good.
In fact, one of the best pieces I've ever read recently.
www.wheresyoured.at/the-era-of-t...

Python web development in a picture
#pyconit
@marcelotryle.bsky.social
@tiangolo.com
@pyconit.bsky.social

I should really start publishing charts in the Granian benchmarks suite.
Much easier to read compared to tables.
github.com/emmett-frame...

Granian 2.3 is out! 🚀
Now with mTLS and direct static files serving support :)
github.com/emmett-frame...

Yesterday, @opensourcepledge.com was on Nasdaq Tower in Times Square. I got to be there for it! Thank you to Nasdaq and congratulations to all of the featured companies who #paythemaintainers! 👏 What a great way to keep celebrating #maintainermonth! 💃

Two children at school in uniforms and it looks like Japan, both of them look like girls or femmes. One is holding a giant tuba so that it's stuffed over the face of the other one that's pinned up against the wall. The one holding the tuba is labeled every company. The tuba is labeled unwanted AI And the one against the wall is labeled me

Maybe in the near future the original SDK package can provide different extras (client,server,http,asgi) so that mine will be useless @thedsp.bsky.social @marcelotryle.bsky.social @sa.muelcolvin.com

GitHub - gi0baro/py-mcp-min: Model Context Protocol minimal Python SDK Model Context Protocol minimal Python SDK. Contribute to gi0baro/py-mcp-min development by creating an account on GitHub.

To build this extension I also made a "minimal" MCP python package, which depends only on @pydantic.dev: github.com/gi0baro/py-m....
It kinda provides just the types and abstract classes.

GitHub - gi0baro/emmett-mcp: MCP extension for Emmett framework MCP extension for Emmett framework. Contribute to gi0baro/emmett-mcp development by creating an account on GitHub.

Yo! Spent the weekend over MCP and built something.
You can now build MCP servers in your Emmett application 👀
github.com/gi0baro/emme...

Kudos to @davidhewitt.bsky.social for the huge support on this 🙌

If you run Granian on Python versions > 3.10, you probably want to upgrade to the latest 2.2.4 release, as it fixes a noticeable performance regression bug (up to 2x in certain scenarios 👀)
github.com/emmett-frame...

I'd say this is probably one of the worst times in the software industry I have ever seen in the last 13 years.
The whole narrative about "AI" to trade learning for productivity is just a cancer for young people. Promoting ignorance and incompetence is bad and stupid. Just stop it, please.

Release Granian 2.2.2 · emmett-framework/granian Patch release Changes since 2.2.1: Proper connections load balancing across workers on Linux (#546, special thanks to @aldem) Bump dependencies

If you run Granian with multiple workers on Linux, you probably want to upgrade to the latest 2.2.2 release, as it severely improves the load balancing across workers ;)
github.com/emmett-frame...