AJAX very slow on TYPO3 12.4.32, PHP 8

[GeorgeTodea]

Hello,

set up lux and added it on a link to a page or PDF, doesnt matter. It takes up to send the email or generate the PDF between 16 and 25 seconds.

This is what is sent via POST:

?type=1518815717&tx_lux_fe[dispatchAction]=email4LinkRequest&tx_lux_fe[identificator]=cbaea603a5a7c624a6b9683467de4b67&tx_lux_fe[arguments][sendEmail]=true&tx_lux_fe[arguments][href]=/products&tx_lux_fe[arguments][pageUid]=7670&tx_lux_fe[arguments][values]= some values

Is is something to have a look inside LUX configuration?

Thanks

[einpraegsam]

Thx for your input.
This is way to long for such requests.

Some questions from me:

• Pls write down TYPO3, LUX and PHP version
• Did you check https://github.com/in2code-de/lux/blob/develop/Documentation/Technical/FAQ/Index.md#how-to-increase-performance

[GeorgeTodea]

TYPO3 12.4.32, PHP 8.3.21, LUX 38.4.0

No, I did not check that link. Will see how I can improve there.

[einpraegsam]

If you still need help, come back to me later. I still have some ideas.

[GeorgeTodea]

@einpraegsam tried next things:

1. update to latest version
2. useCacheLayer was already enabled
3. no needed as its still fresh and only I am testing this
4. tried the same on Mittwald as in the article, was worse
5. I dont want to try this yet

so in the end, updating to latest version reduced it to around 14 seconds. But still slow, isnt it?

[einpraegsam]

So, if 3) is not needed because there is not that much data yet in the database, it sounds very strange.
Can you check if the index is set correct in the tx_lux tables (as defined in ext_tables.sql).
Are you a LUXenterprise customer? If so, we could offer support by checking your installation.

[GeorgeTodea]

More exactly, which index to check?

No, I am not a LUXenterprise customer, but I can propose that to the client.

[einpraegsam]

When opening the ext_tables.sql you can see KEY definitions per table. You could check in your database, if the indexes are set correctly.
Here an example screenshot from PhpStorm:

[einpraegsam]

Any update for us?

[GeorgeTodea]

Hello @einpraegsam ,

at the moment, moved on with other work to do, but the issue is still there.

I have to check if the indexes are set correctly, but I guess maybe later this week, if not, in a few weeks.

Thanks

[einpraegsam]

Thank you for your feedback,

I'm willing to help you. If there is really no progress, contact me again. I'm sure, we are going to find the bottleneck.

[GeorgeTodea]

@einpraegsam wondering if this has something to do with my errors in log like:

Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1294587217: The page is not configured! [type=1520192598][]. This means that there is no TypoScript object of type PAGE with typeNum=1520192598 configured. | TYPO3\CMS\Core\Error\Http\InternalServerErrorException thrown in file /html/deploy/releases/131/vendor/typo3/cms-frontend/Classes/Controller/TypoScriptFrontendController.php in line 1528. Requested URL: https://www.someUrl.de/products/some-materials?type=1520192598

I get this for all roots.

LE: disabling it temporary from TS make the error go away. What is it used for? Can I fix it somehow?

[einpraegsam]

Hi, I'm not sure if this is related to the slow requests.

Explanation:
There is an URI to render content elements in lightbox together with LUXenterprise. Such URL is rendered in an data-attribute with LUX (see https://github.com/in2code-de/lux/blob/develop/Configuration/TypoScript/Lux/11_PageConfiguration.typoscript#L52).
Maybe a bot or broken software stumbled of the url and tries to call it. But the typeNum is registered in LUXenterprise.

[GeorgeTodea]

Actually the requested URL is https://www.someUrl.de/products/some-materials?type=1518815717&tx_lux_fe[dispatchAction]=email4LinkRequest&tx_lux_fe[identificator]=&tx_lux_fe[arguments][sendEmail]=false&tx_lux_fe[arguments][href]=/fileadmin/somePdf.pdf&tx_lux_fe[arguments][pageUid]=7670&tx_lux_fe[arguments][values]=...

So this is

lux/Configuration/TypoScript/Lux/11_PageConfiguration.typoscript

Line 40 in e924007

# Uri to send tracking requests to

But still can't figure out why is so slow. Even on local machine, it gets 8 seconds to finish.