django-startup-time

작성자: posthog

모든 프로세스(웹, 셀러리, 템포럴, 마이그레이션, 셸, CI)가 부담하는 django.setup() 경로에서 무거운 임포트를 제거하세요. AppConfig.ready()를 건드릴 때 사용하세요,…

npx skills add https://github.com/posthog/posthog-foss --skill django-startup-time

Django startup time

Full background — the four mechanisms (lazy router, model registration, receiver wiring, boot GC window), the regression guards, how to add code without regressing them, how to measure, and the detailed trap write-ups: docs/internal/django-startup-time.md. That doc is the single source of detail; this skill is the trigger and the checklist.

The guards live in posthog/test/repo_invariants/test_startup_import_budget.py. When one fails, defer the import — don't remove an entry to dodge it. Conversely, when you deliberately defer a significant heavy lib off setup, add it to FORBIDDEN_AT_SETUP (after confirming it's absent from a bare django.setup()). Never pin a product facade or its contracts module there: facades must stay importable from anywhere, so pin the heavy module you deferred instead. New imports nobody has named yet are caught by test_no_new_heavy_imports_at_setup: any package not in posthog/test/repo_invariants/setup_import_baseline.txt costing ≥100ms at setup fails the build — defer it; baseline only what every process genuinely needs at setup.

Defaults when adding backend code

  • New app/product: register models from models/__init__.py, wire receivers from AppConfig.ready(), keep ready() light.
  • New receiver: wire it at the owning AppConfig.ready(), from a dedicated light module (activity_logging.py, signals.py) — never via the API/viewset module, even if it looks light today; those accumulate heavy imports and ready() silently inherits them.
  • New heavy dependency (vendor SDK, Temporal/AI/ClickHouse, pandas/pyarrow/scipy): import it function-locally on the path that uses it with # noqa: PLC0415, never at module scope.
  • Schema types on a setup-path module: enums from posthog.schema_enums (cheap); pydantic models from posthog.schema only inside the method that uses them. No module-level from posthog.tasks... on setup paths — CeleryQueue lives in posthog.celery_queues.
  • New viewset/route: it no longer loads at setup — don't rely on import side effects; routes go in rest_router.py, not the __init__.py shim.
  • Where to cut: at the setup-path entry (the module ready() wires, a model file, apps.py), never inside a module that consumes a product facade. When a facade reaches setup, the entry defers the implementation module that leads to it; facade imports stay at module scope. If the setup path needs one symbol from a heavy module, move it to a light module and re-export it.
  • Any deferral relocates cost — ask which process pays now, on what path, and whether that path is latency-sensitive (background workers paying lazily: fine; web workers paying on first requests: usually not).

Traps to check before you commit

One line each — the doc has the full write-up and the fix recipe for every entry.

  • ready() re-drags a heavy dep onto startup — importing a receiver's module runs its module-level imports too; re-measure after wiring.
  • Silent receiver loss — lost receivers don't error; reproduce in a process that does NOT build the router (manage.py shell, celery, migrate).
  • Models vanishing from the registry — a model reachable only via a viewset import breaks makemigrations/admin/mypy; import it from models/__init__.py, then dmypy stop.
  • Lazy-router merge conflicts — keep the __init__.py shim, port master's aggregator deltas into rest_router.py.
  • Aggregator package __init__s — shim with PEP 562 __getattr__, via importlib.import_module and an __all__ whitelist (catch-alls recurse or deadlock on sibling imports).
  • Serializer field kwargs run at import — choices=... inputs can't be function-locally deferred; move the constant to an import-light module.
  • Vanished re-exports — regenerating/shimming a module drops names other code imported from it incidentally (e.g. schema.BaseModel); grep for consumers of the old namespace, including relative-import spellings.
  • Patch targets break on call-time imports — @patch("mod.helper") stops intercepting once mod imports helper at call time; patch the defining module instead.
  • Snapshot regen on a bad merge — regenerate .ambr against the merged branch, then confirm it isn't masking a regression.
  • Measuring the wrapper, not the work — time inside the process; importtime + tuna, not pyinstrument; grimp for cycles and door enumeration.
  • Guessing where to defer — run hothog on the importtime log; its 1-cut@ column names the dominator to defer at, and --compare gives the before/after. Name this skill and hothog in the PR's agent context, so a reviewer knows how the cuts were chosen.
  • Phantom importtime costs from GC — re-capture with gc.disable(); if the cost vanishes, the finding is GC, not the module. Keep the entrypoints' GC window closing in a finally.

posthog의 다른 스킬

error-tracking-hono
posthog
PostHog 오류 추적 for Hono
tuning-incremental-sync-config
posthog
동기화의 구성은 ExternalDataSchema에 저장되며, external-data-schemas-partial-update를 통해 언제든지 변경할 수 있습니다. 대부분의 변경은 비파괴적이며(다음 동기화에 적용됨), 일부 변경(sync_type 전환, 기본 키 변경)은 동기화된 데이터 손상을 방지하기 위해 신중한 처리가 필요합니다.
playwright-test
posthog
플레이라이트 테스트를 작성하고, 실행이 잘 되며, 불안정하지 않도록 하세요.
error-tracking-ruby
posthog
PostHog Ruby 오류 추적
authoring-log-alerts
posthog
PostHog 프로젝트의 서비스에 유용하고 노이즈가 적은 로그 알림을 작성합니다. 사용자가 로그에 대한 알림 설정을 요청하거나 추가해야 할 알림을 제안할 때 사용하세요.
making-scenes-tab-aware
posthog
Guides converting PostHog frontend scenes to be tab aware for internal scene tabs. Use when adding or refactoring a `SceneExport` scene, fixing state leaking…
posthog-survey-creator
posthog
PostHog에서 안내 대화를 통해 설문조사를 생성하고 구성합니다. 사용자가 설문조사를 만들거나, 사용자 피드백을 수집하거나, 실행하려 할 때 이 스킬을 사용하세요.
authoring-scouts
posthog
PostHog Signals 스카우트를 작성, 편집 및 조정하는 방법 — 프로젝트를 스캔하고 Signals 인박스에 보고서를 작성하는 예약된 에이전트입니다. 사용자가…