Slow site

[sandomatyas]

There is a site which I want to speed up a bit. It consumes a huge amount of CPU resources.
I tried to debug a bit, installed Xdebug and checked the result with qcachegrind. I attached the call graph.
If I'm right the main consumer is something around VirtueMartModelProduct->getProducts

There is an enabled cache on the site and with normal traffic it works more or less okay but a crawler can hang the whole site

Joomla 3.8.5, VM 3.2.12

[jjk]

If it is a new problem with a website which was much faster previously, it might be that it is affected by a change in Joomla 3.8.4, which results in old sessions not deleted anymore with certain server configurations. Check if your session table in the database has a reasonable size. Earlier today I've read a post on Github, where the session table had grown to 9 gb with 10 million rows. If the table is huge, 'empty' it with phpmyadmin.

If you enable VMDebug in VM configuration > Advanced Settings > Enable debugging of methods 'for all', it might give you some insights about loading times and memory usage, too.

[Studio 42]

GetProducts load all products and add product object with all details.
With some poor plugins, you can have many memory used and Virtuemart itself cache the whole product.
Try to only display max 18 products, should really help.
Note that on using many child/parent, memory used can be multiplied X2 or more depending of course how you use it.

[sandomatyas]

The site was always slow bit nowdays it has more traffic so it's worse than before.

I reduced 50 products/page to 25.
There are only few child products, but ~10.000 normal products.

There are only few sessions in the database (~200 right now)

This is the result of vmdebug

Üzenet

1 vmdebug Show All Errors, PHP-Version 7.0.27

2 vmdebug 2 Languages, default shoplanguage (VmConfig::$jDefLang): hu_hu hu-HU Selected VM language (VmConfig::$vmlang): hu_hu hu-HU SEF: hu

3 vmdebug vmTime: time to load config: 0.00350689888000488

4 vmdebug There is no requested itemid loaded home Itemid Var1:

101

5 vmdebug 2 Languages, default shoplanguage (VmConfig::$jDefLang): hu_hu hu-HU Selected VM language (VmConfig::$vmlang): hu_hu hu-HU SEF: hu

6 vmdebug Start used Ram 10M

7 vmdebug Common jQuery is disabled

8 vmdebug getVendorId normal shopper

9 vmdebug My Memory Limit in Bytes 536870912

10 vmdebug vmTime: getSearchCustom after setUserState: 5.00679016113281E-6

11 vmdebug vmTime: getSearchCustom End: 0.000288009643554688

12 vmdebug $limitStart Var1:

0

13 vmdebug vmTime: sortSearchQuery products: : 0.000523805618286133

14 vmdebug vmTime: Manufacturers by Cache: 0.00499892234802246

15 vmdebug SSL enabled

16 vmdebug Common jQuery is disabled

17 vmdebug Common jQuery is disabled

18 vmdebug Set 0 to 0

19 vmdebug isSuperVendor Not a vendor 0 Var1:

0

20 vmdebug Common jQuery is disabled

21 vmdebug Fallback active

22 vmdebug End used Ram 32M

23 vmdebug Peak memory peak 32M

24 vmdebug vmTime: "VirtuemartControllerCategory" Finished task : 14.4674990177155

25 vmdebug Common jQuery is disabled

26 vmdebug vmTime: Time consumed for shipment/payment plugins: 0.05259108543396

27 vmdebug Common jQuery is disabled

28 vmdebug Common jQuery is disabled

[Studio 42]

vmdebug vmTime: "VirtuemartControllerCategory" Finished task : 14.4674990177155
For 25 products ?
What are the used custom fields plugin and do you use childrens ?

[sandomatyas]

No children.
Custom fields: ~15 String type and one generic child vairant and one multivariant but not for this 25 products. There are only string fields.
The server is a quite fast one, there aren't any problem with other sites on this server. We hosted on 3 different servers and had the same problem so it must be something with the site.

[Milbo]

Note that on using many child/parent, memory used can be multiplied X2 or more depending of course how you use it.

Not really, it can also speed up your store, when correctly used. The customfields per product take the most time. You can use the customfields very expensive or cheap.
it is actually often a lot more performant to use a pattern. it is very often so that a vendor adds to any product always the same customfield. In this case it is a lot cheaper to use a parent having the customfield and only children. Why?
All is cached in RAM. So when you load a parent product with customfield you do that one time, for maybe 50 products. So you load 51 products, but you spare to load 50 times the same customfield. Customfields are product depended, so there is no cached customfield, when you set them per product.

You can also use the strings very expensive, when use for any dropdown a new string. Or you can use a customfield String, with a predefined list. So sometimes you can replace a customfield group which creates a dropdown just with one customfield.

So for example, you have a lot products with 3-5 colors. Use a pattern with all 5 colors, and just suppress the not used colors in the child, or add a color to the child. It is still more performant than to use for any product a new list.

But of course, children can be extensive, compared to other solutions like strings.