I have a issue in my Magento Backoffice.
If i try to browser Catalog-> Manage products it takes up to 15seconds to open the page (20 results per page). Also if I try to move from page 1 to page 2 of the results it takes the same time.
If i open all other section menu of backoffice it takes maximum 0.5 sec.
Please note i have 160.000 sku in Magento
I am on a dedicated server with 24 Gb RAM and 250 SSD RAID 1
I have FastCgi Ngnix APC Memcached installed
It's this log delay maybe related to same table issue?
How can a 20 page result take all this time to open?
Things looks better now,
here what i did:
I discovered core_url_rewrite table was over 5 gb !!!
and Flat catalog and Flat categry in Magento backoffice where setted on "No".
I did a trucante of core_url_rewrite and enabled Flat Catalog and Poduct in magento backoffice.
I then did a full reindex.
Now timing is decreased from 15 sec to 4-6 seconds.
Hope it can help someone
Related
Currently, our Magento 2.3.4 speed is so slow.
With the homepage, it takes 5 secs to load with 200 MySQL queries running.
But with the category, it takes 20 secs and nearly 3000 queries.
Can you please let me know how to log the MySQL queries on the category page load?
I have developed custom API with Magento(1.9 community edition) SOAP API V2 to fetch orders. The problem is APIs are taking more than 25 seconds to respond.
There are couple of API calls involved.
/login to get API key
/customOrdersApi to get orders
Both calls are taking too long to respond. CPU utilization is also maxed out during calls.
CPU-apache2
An interesting behavior I found while monitoring Magento cache (var/cache), it created a WSDL file every time and deleted it after an end of execution. That WSDL cache file's id was in upper case mage---345_WSDL_CONFIG_GLOBAL. There was already cached WSDL file in lower case mage---345_wsdl_config_global but Magento didn't pick it. After that I dug deep in Magento core files and found in code/Mage/core/Model/Cache.php, function _id($id) was turning ids in to upper case. I commented that out and Magento started to pick cached lower cased WSDL file. Response time decreased drastically and both calls started to take less than 3 seconds.
FYI Magento Core API WSDL cache is already set to true.
Has anyone experienced this behavior of Magento? Is there an efficient way to improve the speed of Magento SOAP API?
Thanks
I am had and still having the same issue. The only thing I found so far:
Looking at the MySQL Database with the SQL command show processlist; I saw, that it tries to update the sales_flat_quote table on every request. If the table is huge it takes a lot of time.
If found this query
DELETE FROM sales_flat_quote WHERE updated_at < DATE_SUB(Now(),INTERVAL 60 DAY) to only keep the last 60 days.
MagentoExchange - How to handle huge sales_flat_quote tables
If I set it to 5 days the time my API call takes has reduced by 50%.
when the new products get uploaded they are not visible on the front end. They told me we need to re-index every time. However re-index gets stuck.Please look into this issue for me and let me know if we can have it reindex automatically.
Reindex mode is Update on save and currently showing processing in index management
If it shows as processing then it's probably running. It may take a long time depending on how many products you have. The core url rewrite index is the most intensive. The reason you need to index is most likely because you have enabled the Use Catalog Flat Tables options under system configuration which is good for performance and speed of the site. Downside is you need to re-index these flat tables when you add new items. You can have the indexes run automatically by configuring cron to call magentos index process.
e.g.
* * * * * /usr/bin/php /var/www/magentosite/cron.php
5 0 * * * /usr/bin/php /var/www/magentosite/shell/indexer.php --reindex all
If it is stuck and you are sure it's not running, then you can change the status of the index process back to pending manually in the database by editing the table index_process. Re-run it manually from the admin and see if it fails. The index most likely causing your products not to show up is Flat Catalog Product Indexes so run this one first.
Yes, When you insert new product so re-indexing is require and also disable you magento cache.
and also flush your magento cache.
We have 4000 products with 4 stores and around 80 categories. We are running a dedicated DB server having SSD and followed the white paper of optimizing DB as well as App Server. Each product also have 12 custom options. Now Indexing is very slow. Any suggestions. Would it make any difference to reduce number of categories in the store etc.
Regards,
Steve
Indexing is dramatically slowed when multi store setups are used. On one of our servers 3000 products on a single store setup takes approx 60 seconds to index everything. But 3000 products on a multi store setup (7 stores) can take up to 10 minutes. We have it set up to manual index only. You could set the indexing to run on a cron which might help you. (Throwing more resources at the server will obviously help too).
Reduce Catalog price rules if in use
Reduce all attributes not required for Search Index - the default Magento install includes attributes like "Tax Status" in the Search Index and then this is multiplied 4x for your multi stores
Same can be said for URL rewrites - 4x increase
12 custom options per product ? Could common attributes be used instead ?
Run indexing from SSH rather than from the Magento admin
In the web root in the shell/ folder you will find indexer.php
php indexer.php --help will give you some options
You can then time each of the nine indexes to see which is taking the most time which may help narrow the problem down
By running from command line you can increase the php memory limit just for that one process which may improve results
I set up a cron job to re-index the site in off peak times and in Magento admin, change to Manual Update only
I am using Magento 1.5.0.1 with 600,000 products. Indexing is a major issue, especially catalog_product_price index.
1/ Towards the end of the indexing process a query is run DELETE FROM catalog_product_index_price . This has the effect of removing every item from our site so that the site displays 'There are no products matching the selection.' for all categories, the home page, search results.
2/ The process to insert from catalog_product_index_price_idx into catalog_product_index_price takes 10 minutes so we have a 10 minute window with no products on the site. I am absolutely certain this is a bug, there is no way someone intended for indexing to remove all products for a period of time - even if it was only 10 seconds this is not right for an ecommerce website
3/ For some reason the process of DELETE FROM catalog_product_index_price sometimes leaves a few products in the table therefore when the process of inserting from catalog_product_index_price_idx into catalog_product_index_price runs the indexer throws up an integrity constraint issue because of duplicate entries. This ends the indexing process and leaves the site with no products on. We run indexing in the early hours of the morning so sometimes we have a number of hours with no products on site if the index fails.
Does anyone know of a fix to these issues or a better way to update prices on the site that does not require us to index?
Firstly well done for running Magento with 600k products, that is the most I have heard of.
The best way to work around this I think would be to override the indexing process so that instead of truncating and rebuilding the price index, it replaces line by line. It is likely that this would take longer over all but would resolve the issue of it having this window with no products.
One thing you could try is to replace DELETE FROM with TRUNCATE TABLE which might be more reliable for your "still some items in the table" issue.
Ultimately though I think you are going to be building a bespoke optimised indexer.