-
|
I’m rendering each page through a series of discrete “activities” (authentication checks, data-fetching steps, etc.) orchestrated by Laravel. The problem: judging from the log excerpt below, it still takes about one second from the request to the page actually being shown. Even when I switched the queue/DB cache to Redis, the total time didn’t improve. Has anyone found effective ways to shave that ~1 s off the initial render—either by tuning Laravel queues, Neo4j/PostgreSQL access, or something else entirely? Any pointers or best practices would be appreciated! Environment |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
Unfortunately, your use case isn't a good fit for workflows in general. They're meant for long-running, asynchronous processes, like retries, human input, or background orchestration, not for rendering synchronous web pages. Using them in this way adds significant overhead and can actually increase latency, which you're clearly seeing. From your logs, the individual activities are fast, but chaining dozens of them serially, even at 20ms each, quickly adds up. That's before factoring in Laravel's boot time, DB I/O, view rendering, and response handling. If your goal is to reduce page load time, you'd be better off refactoring this logic into lightweight services or controller methods, caching intermediate results during the request lifecycle, and batching your database queries where possible. Workflows are powerful, but they're not a good fit for this particular use case. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much for your response. |
Beta Was this translation helpful? Give feedback.
@ryun818
Unfortunately, your use case isn't a good fit for workflows in general. They're meant for long-running, asynchronous processes, like retries, human input, or background orchestration, not for rendering synchronous web pages. Using them in this way adds significant overhead and can actually increase latency, which you're clearly seeing.
From your logs, the individual activities are fast, but chaining dozens of them serially, even at 20ms each, quickly adds up. That's before factoring in Laravel's boot time, DB I/O, view rendering, and response handling.
If your goal is to reduce page load time, you'd be better off refactoring this logic into lightweight services or controller meth…