Problems with move copy products (cache related?)

[OopsIbrickedIT]

[ZC 1.5.0, PHP 5.6, MariaDb,Opcache enabled]

Hi folks,

seems our shop has possibly cache related problems. Before things worked ok but slowly. I have enabled Opcache for performance reasons and integrated 1.5.1 cache to our old 1.5.0 zc version. Now there seems to be a cache related problem on admin side and for example move or copy products/categories do not work on the admin side. Sometimes when you refresh the page move category list opens but not nearly allways. Below is zen carts phpinfo. I do not know but how local & master directive values are determined and seems they differ so If somebody wiser could tell is there something wrong with them or is this issue related to some timeout etc?

Session Support enabled
Registered save handlers files user
Registered serializer handlers php_serialize php php_binary wddx
Directive Local Value Master Value
session.auto_start Off Off
session.cache_expire 280 280
session.cache_limiter no value no value
session.cookie_domain .mycompany.com no value
session.cookie_httponly On Off
session.cookie_lifetime 0 0
session.cookie_path /home/admin /
session.cookie_secure On Off
session.entropy_file /dev/urandom /dev/urandom
session.entropy_length 32 32
session.gc_divisor 2 1000
session.gc_maxlifetime 1800 2440
session.gc_probability 1 0
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name zenAdminID PHPSESSID
session.referer_check no value no value
session.save_handler user files
session.save_path /home/admin/tmp /home/admin/tmp
session.serialize_handler php php
session.upload_progress.cleanup On On
session.upload_progress.enabled On On
session.upload_progress.freq 1% 1%
session.upload_progress.min_freq 1 1
session.upload_progress.name PHP_SESSION_UPLOAD_PROGRESS PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix upload_progress_ upload_progress_
session.use_cookies On On
session.use_only_cookies On On
session.use_strict_mode Off Off
session.use_trans_sid 0 0

All the best to ZC community and thank you in advance.

[DrByte]

I do not know but how local & master directive values are determined

Local is what's active at the time the inquiry is made. This includes anything updated during runtime (running PHP code used to build the page).
The master settings are what's set according to the master php.ini configuration of the server.

[mc12345678]

Additionally and when it not nearly opens (whatever that means), might want to check for a myDebug log... it's been a minute, but I thought that in ZC 1.5.0 they were still being logged in the cache directory. (which may want to check to be sure it's not "full".) considering that php 5.6 is "available" should also strongly consider upgrading the store to a more stable version of ZC before being forced to do something... easier to make the change now while it's at least semi operational and making money than when it is out-of-service and trying to figure out how to get it online...

[OopsIbrickedIT]

Hi,
sorry for late response and thank you for clarification DrByte & I could not agree more with MC. Cold truth is that I have been sick for nearly 8 months and pile of work has to be done before winter. Also I work in this zen cart project as a part timer and 95% of the new shop is ready but my boss seems to have fun time kicking my ###### on less important things. It would be much wiser to upgrade but I have to keep up the old system running for few weeks still.

I did forget to mention that there is a simple category caching in place made by data-diggers. I did took of the Opcache from my.cnf and investigated whats causing the issue.

Seems myIsam table locks are the cause? :

| 4689 | Query   | 274  | Sending data                 | select distinct p.products_id, p.products_image, p.products_tax_class_id, pd.products_name,
         | 0.000    |
| 4692 | Query   | 263  | Waiting for table level lock | update zen_products_description
            set        products_viewed = products_viewed+1
          | 0.000    |
| 4694 | Query   | 210  | Waiting for table level lock | select products_name
                   from zen_products_description
                   where produ | 0.000    |
| 4695 | Query   | 203  | Waiting for table level lock | select products_name
                   from zen_products_description
                   where produ | 0.000    |
| 4696 | Query   | 198  | Waiting for table level lock | select products_name
                   from zen_products_description
                   where produ | 0.000    |
| 4699 | Query   | 163  | Waiting for table level lock | select products_name
                   from zen_products_description
                   where produ | 0.000    |
| 4700 | Query   | 137  | Waiting for table level lock | select  p.products_id, p.products_type, p.master_categories_id, p.manufacturers_id, p.products_price | 0.000    |
| 4701 | Query   | 126  | Waiting for table level lock | select products_name
                   from zen_products_description
                   where produ | 0.000    |
| 4704 | Query   | 81   | Waiting for table level lock | select  p.products_id, p.products_type, p.master_categories_id, p.manufacturers_id, p.products_price | 0.000    |
| 4705 | Query   | 63   | Waiting for table level lock | select  p.products_id, p.products_type, p.master_categories_id, p.manufacturers_id, p.products_price

Could I just convert products and categories to Innodb to get row level locking instead of table level locking? Now they are Isam.

Brgds,
Oops

[OopsIbrickedIT]

Regarding latest maria db slow log after removing opcache from use is found below so the join may cause issues too, should there be an index?
Also to be more precise I do not have access to original files of datadiggers query cache 1.0 which I found from source code. Theere may be issues in that too.
Also I tried to install numinix disk cache last year and there might still be remnants of that too.

slow.log:
select count(distinct p.products_id) as total FROM (zen_products p LEFT JOIN zen_manu$
# Time: 200611 17:11:23
# User@Host: admin_vanha2[admin_vanha2] @ localhost []
# Thread_id: 980 Schema: admin_vanharotko2 QC_hit: No
# Query_time: 1.737071 Lock_time: 0.000130 Rows_sent: 30 Rows_examined: 392865
# Rows_affected: 0 Bytes_sent: 5098
SET timestamp=1591884683;
SELECT DISTINCT p.products_model, p.products_image, p.products_quantity , m.manufacturers_id, p.pr$


brgds,
Oops

[OopsIbrickedIT]

Additionally and when it not nearly opens (whatever that means), might want to check for a myDebug log... it's been a minute, but I thought that in ZC 1.5.0 they were still being logged in the cache directory. (which may want to check to be sure it's not "full".) considering that php 5.6 is "available" should also strongly consider upgrading the store to a more stable version of ZC before being forced to do something... easier to make the change now while it's at least semi operational and making money than when it is out-of-service and trying to figure out how to get it online...

Sorry MC, forgot to answer to that. There is indeed log in cache folder and I have been cleaning it up periodically. This warning is caused by missing argument and it appears twice:
[11-Jun-2020 15:13:42 UTC] PHP Warning: Missing argument 2 for cache::sql_cache_exists(), called in /home/admin/web/mycompany.com/public_html/kauppa/includes/classes/db/mysql/query_factory.php on line 191 and defined in /home/admin/web/mycompany.com/public_html/kauppa/includes/classes/cache.php on line 22
[11-Jun-2020 15:13:42 UTC] PHP Warning: Missing argument 2 for cache::sql_cache_exists(), called in /home/admin/web/mycompany.com/public_html/kauppa/includes/classes/db/mysql/query_factory.php on line 191 and defined in /home/admin/web/mycompany.com/public_html/kauppa/includes/classes/cache.php on line 22

Line 22 from cache.php: function sql_cache_exists($zf_query, $zf_cachetime) {

so it seems argument $zf_cachetime is missing but from where it is defined? I did installed cache from 1.5.1 to 1.5.0 because our previous hoster had serious performance issues and I tried to make site faster quickly.

Obviously I have made an mistake when trying to incorporate that and argument is missing, Is it supposed to be in db configuration?

[mc12345678]

That message/issue is a result of whatever code is trying to call the function missing the second parameter. That is more likely where the problem(s) "start". What value is to be used also depends on how the function is used elsewhere in the code and what may be considered the right size to reference.This is one place where the developers toolkit comes in super handy...Although in more recent versions there is a grep tool aspect, you could use the lower left hand corner to populate with the code snippet to be sought. So you could enter: sql_cache_exists then make applicable selections of search "criteria" and verify that all results have two parameters. Where there is only one parameter, the file can be reviewed to see something about it or if perhaps a default value can be applied to the function...