Currently I dev a new flow-only application.
With that, starting with a flow base installtion as usual, I have trouble with it - but only on one server.
Calling via Browser one wait about 30(!) seconds to get a response.
On CLI actions its the same.
Same base installation on an other server runs without any issues.
I did a PHP perf test without seeing a problem.
Checked also the file times of rebuild flow classes after a “flow:cache:flush”: time diff is about 6 secs.
CPU and mem values while calling application via browser shows no remarkables.
OS is Ubuntu 20.04 Sever, PHP 8.3
I’ve never had such problems with other Flow application instances…
Is this slowdown only encountered for the first request in the given flowcontext, so that caches have to be build up an proxies compiled or for every request?
For web requests it also depends on what youre action does, but as you said if cli is also slow that is really strange. flow help for example should take no time really once compiled.
./flow help 0.08s user 0.06s system 91% cpu 0.149 total
The resonse comes immediately, than nothing happens for a while (the mentioned 30 secs), than returns to prompt and show this result (help text left out here!)
real 0m30.419s
user 0m0.165s
sys 0m0.079s
I have no idea what is “processed” in this “idle time”.
(I have created several flow applications, but never had this behaivior…)
the routes? Yeah the configuration looks ot me like you are creating an infinite loop! You include these routes and also include them as subroutes, which includes subroutes, which inlcudes subroutes, which includes subroutes… you get my drift
Glad that you could pinpoint the problem. In the afterthought asking an xdebug profile would probably also have shown who is at fault … or checking if flow flow:core:compile runs successfully at first.
The question im having is how can we improve the DX here, and it seems we already throw an recursion exception but not in your case?
There is even a test for it:
But maybe it just gets swallowed or logged and we didnt check?
Sorry for my late reply! No, there was no exeption thrown in my case.
If I’ve more time I can re-test my old config of course.
But I woundring about this “retarding repsonse” with db host 127.0.0.1.
In distributed flow base install there is no database access involved and I don’t understand why a faulty host defintion results in such behavoir!?