Files
firecrawl/apps
mogery c90a794514 perf(api): overlap requests-row insert with v2 search work, expose DB pool gauges
Two changes from the /v2/search longtail investigation:

1. v2/search: logRequest was awaited at the top of the controller, so every
   search paid the Postgres insert (queued behind the saturated pool —
   p90 ~6.6s) before any search work started. It's now kicked off
   un-awaited and awaited just before the logSearch child insert, keeping
   the request_id FK ordering (same pattern as the scrape controllers).
   robustInsert never rejects, so the await cannot throw.

2. Admin /metrics: expose db_pool_waiting_count / db_pool_idle_count /
   db_pool_total_count / db_pool_max_count gauges per application_name
   (firecrawl-api, firecrawl-api-rr, firecrawl-index) so pool saturation
   is visible in Prometheus instead of only via the throttled warn log.
2026-08-27 20:59:04 +02:00
..