I've scoured the documentation and am looking for a Django setting that disables system checks (not just silences them) in production. I have a project with 20,000+ models which are autogenerated to create RESTful endpoints. These system checks take quite some time:
https://docs.djangoproject.com/en/1.11/ref/checks/#models
Having the systems check in development is necessary, even though it causes manage.py
20-30 minutes to fire up. However, any time I publish a new version to production, the first HTTP request to a production node takes 20-30 minutes to respond as well! I'd obviously like to avoid this, because after the initial request, the site is lightning fast.
While the answer in comments below references a solution to get runserver
to come up more quickly, I'm looking for a solution for production, not our development environment.
I've looked around for a setting like DISABLED_SYSTEM_CHECKS
but have only come across SILENCED_SYSTEM_CHECKS
(see here), but that just seems to silence the output rather than not running the checks that take the time. Does such an animal exist? I'm running mod_wsgi
in production. I've seen requires_system_checks
for individual commands, but am looking for a project-wide solution. Thanks very much.
I posted this question long ago, and never posted the solution I ended up using. The root problem was that with that many models (we're now up to 60,000!), each one would be validated on load. urls.py
contained all the end point routes, which would import the DRF ViewSets
, which in turn would load the serializers and models up-front. So what I did was create a sort of lazy loading, and we've open sourced it:
https://pypi.org/project/automagic-rest/
The key element was modifying the ViewSet
to load the model on-demand in __init__
, rather than up front:
self.model = getattr(
import_module(f"{self.python_path_name}.models.{self.schema_name}"),
f"{self.schema_name}_{self.table_name}_model",
)
You can view the full source in context here: https://github.com/wharton/automagic-rest/blob/master/automagic_rest/views.py#L53
This required developing a convention for DRF's basename
to hold the database name, app name, schema name, and model name, but it works well. The initial load time is now about 45 seconds for 60,000 models, rather than over three hours.