Author
Topic: Slow site (Read 1869 times)

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

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.

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.

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.