Django 3.2 – News on compressed fixtures and fixtures compression

If it wasn&#x27;t for Haskell&#x27;s IHP framework then Django, Ruby on Rails and CakePHP would be fighting to come dead last in the techempower composite benchmark <a href="https:&#x2F;&#x2F;www.techempower.com&#x2F;benchmarks&#x2F;#section=data-r20&amp;hw=ph&amp;test=composite" rel="nofollow">https:&#x2F;&#x2F;www.techempower.com&#x2F;benchmarks&#x2F;#section=data-r20&amp;hw=...</a><p>Django, RoR - they&#x27;re almost 2 orders of magnitude behind the fastest frameworks on the composite test and they&#x27;re an order of magnitude behind the majority of Java &#x2F; Go - i was going to say C# here but i see asp.net is much faster than the surprisingly homogenous performing &quot;usual suspects&quot; of enterprise web frameworks.<p>And yet, if i had to launch a site tomorrow, it&#x27;d be Django i&#x27;d reach for - and with zero hesitation. Instagram, Youtube, Github, Facebook, Dropbox etc. etc. all launched on these &quot;slowest of the slow&quot; stacks and then optimised. Did anyone start out on a lithium (c++) or actix (rust) or other incredibly high performance stack?<p>This is all a big diversion anyway, I think these benchmarks measure the wrong thing entirely. Instead - show me some measure of how easy &amp; cheap it will be for me to change or add a behaviour to my site 3 years down the road if i&#x27;ve stuck to the prescribed idiomatic approach.

Is anyone making extensive use of static fixtures? If so what do you like about them vs. using setUpTestData on dynamically generated models (optionally using something like FactoryBoy to make your fixture code more flexible)? I found static fixtures to be brittle and hard-to-maintain, because you need to manually edit them, or have code to regenerate them, every time your schema changes.<p>Recently I&#x27;ve been tempted to revisit them and build out a manage.py command to run the domain scenarios that generate these fixtures (to make it easier to keep them up to date), since when testing DB migrations you often actually do want to have stale&#x2F;old-schema DB state, instead of the default of using the post-migration code to generate your test fixtures. But I&#x27;m still not sure I&#x27;d prefer them in many tests outside of the migration-testing usecase.

Not including Zstandard is a lost opportunity -- it is far more appropriate than XZ or LZMA for real-time applications like serving web pages. Should be easy to add, though, and likely would be a very nice compromise between space, memory, and speed (including tuning various levels of Zstandard compression).<p>gzip is basically never worth using anymore except for backwards compatibility; zstd is both faster and more space efficient.<p>lz4 similarly is worth adding for utmost speed but I tend to think zstd is better in practice (particularly when the control plane is Python where perf is somewhat limited anyway).

Looks like .gz is basically a free lunch in terms of CPU&#x2F;memory impact with a decent size savings.