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
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.
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.
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
vmdebug vmTime: "VirtuemartControllerCategory" Finished task : 14.4674990177155
For 25 products ?
What are the used custom fields plugin and do you use childrens ?
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.
Quote from: Studio 42 on March 08, 2018, 00:49:11 AM
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.