I'm not currently suffering from this. In the past with .NET I have
definitely suffered from some long memory loads of DLLs.
The stuff I'm doing now is a lot of back end batch processing where how
fast the initial response is is pretty negligible compared to a process
that lasts for 10+ minutes.
Fred,
The thread (and Ben) is talking about "lazy load" in the sense of "wait until
the first request comes in, only then load things". This used to be the way all
of Django behaved until 1.7 and the app refactor. These days, it only applies
to some parts -- middleware is the topic of this thre
Ben,
If lazy loading is causing you problems, here's good info on how to
force Django to load everything up front, by calling select_related()
and prefetch_related() in cases where you need to. And also how to
make that the default via use_for_related_fields and custom managers:
- https://docs.d
I'm not too familiar with the code you're referencing, but I'm personally
really annoyed by lazy loading. It has a tendency to make selenium tests
timeout inconsistently in CI, as well as give the impression to my bosses
that the app is slow rather than just the first load which is usually what
Great!
Well the two line patch I suggested to `get_wsgi_application` solves the
problem. But it still leaves the lazy loading mechanism in the code base.
Getting rid of it would obviously be preferable, but is more complex. I'll
work on producing a patch for that though.
Dave
On 25 Mar 2016 10:08
+1 -- Patches welcome :D
On Friday, March 25, 2016 at 11:02:26 AM UTC+1, Aymeric Augustin wrote:
>
> On 24 Mar 2016, at 17:39, David Evans >
> wrote:
>
>
> Currently, middleware is initialized lazily on serving the first request,
> rather than on application start. There may well have been good
On 24 Mar 2016, at 17:39, David Evans wrote:
>
> Currently, middleware is initialized lazily on serving the first request,
> rather than on application start. There may well have been good reasons for
> this historically, but I don't think they apply any longer.
Indeed, since 1.7 and the app-l
Hi all,
Currently, middleware is initialized lazily on serving the first request,
rather than on application start. There may well have been good reasons for
this historically, but I don't think they apply any longer. Lazy
initialization is unhelpful if a middleware class throws an error (e.g t
