Flow base install extremly slow

Using Neos & Flow Flow App Development
1

Hello again!

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…

Does anyone have an ideo, whats going wrong here?

Thx, Frank

2

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
3

Did you check if it’s really flow that is taking so long or a dns issue or similar ?

4

Thank’s for your replies and suggestions!

I’ve tested Marcs idea as follows

time ./flow help

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…)

Remark: its a Flow Application Framework 8.3.9

Are there other sugestions?

5

Hello, here some more infos!

Finally I’ve delete the entire installation and restart the installation.
Theese steps were done (note: FLOW_CONTEXT Development):

composer create-project --keep-vcs neos/flow-base-distribution /path/to/inst 8.3.9
sudo ./flow core:setfilepermissions john www-data www-data
composer remove neos/welcome
composer require neos/fluid-adaptor
./flow kickstart:package Acme.TestProject
sudo ./flow core:setfilepermissions john www-data www-data

Until this point of installation all is fine!
(Of course a call via browser it results in a 404 error, but response comes immediately!)

In CLI mentioned time test delivers theese values:

   real    0m0.210s
   user    0m0.162s
   sys     0m0.048s

After editing Configuration/Settings.yaml like this:

Neos:
  Flow:
    mvc:
      routes:
#        'Neos.Flow': TRUE
        'Acme.TestProject': TRUE

and adding this “Routes.yaml” to Configuration directory

-
  name: 'TestProject'
  uriPattern: '<TestProjectSubroutes>'
  defaults:
    '@package': 'Acme.TestProject'
    '@format':  'html'
  subRoutes:
    'TestProjectSubroutes':
      package: 'Acme.TestProject'

the described problem arises…

Finally this note: revert all this editing problem persists!?

I don’t see any mistake, but maybe only a typo? :face_with_hand_over_mouth:

Any suggestions?

6

Again new insights!

The problem is caused by global Settings.yaml when
persistence -> backendOptions
are present!?

If they are removed, the system works as expected.
The database is available on localhost and accessable in flow context (but that’s the next step…)

Database is current stable mariaDB.

7

Can you check with persistence → backendOptions but without your package routes?

8

Hello Christian,
it seems that’s the problem. Our posting seems to overlap…

9

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 :joy:

10

Hello Christian,

I’ve removed all Routs.yaml and placed the (default) backend options.
Now browser request are fine, but CLI problem persists.

That is reproducable: without backend options okay, with 30 secs. :pensive:

11

Remote debug for these things is always a bit hard. Which FLOW_CONTEXT do you use on CLI and on web?

12

Your are right! Remote debugging … I know it.

Web and CLI are both Development.

BUT: WHAT A MESS!! I got the solution! :rage:

Default host: '127.0.0.1' replaced with host: 'localhost'

Days of debugging… But thank you for your help!

2 Likes
13

Glad that you could pinpoint the problem. In the afterthought asking an xdebug profile would probably also have shown who is at fault :smiley: … 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?

14

Hello Marc Henry!

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!?