I have created a new category on my store after creating this website taking 15-20 seconds to load, but before that it's taking only 5-6 seconds
Please re-index all the index and if it is still slow you can try by using flat tables for catalog.
Also make sure you have not added anything wrong in category details like special characters in desc etc.
Related
I am working on an e-commerce application on which we are predicting around 2 millions products.
We are using Solr for searching, suggestions and filtering.
But for showing the product card data(which has detail like name, image, price, discount and rating) on the Product Listing page(PLP), we are going to Database after fetching the product ids from the Solr.
For E.g:
User went on the our e-commerce application and there on the search box typed "I phone 13 pro".
While user was typing we are showing suggestions to him/her after fetching it from the solr, no db involved yet.
After that user either click or hit enter then we are showing the Product listing page where we first reaching to the solr and fetching the product ids(say 24 per page we are showing) matching the entered text and then we are going to the DB with these ids and fetching the product objects and passing it to the UI with the necessary detail(using DTO object).
Now my question here is:
As I mentioned above we are hitting DB for the Product Listing Page(PLP) for fetching 24 product per page, here I am thinking it may slow down the page when our catalog and user started increasing?
Note:- we are also using Hibernate h2 level caching to stop hitting DB again and again for the same product but cache has limit up to 0.5 million.
Why we are hitting to DB instead of fetching everything from the Solr as we have all product data info which we wanted to show above on the PLP page?
Ans- As we are now keeping important fields of the product object in the Solr not all fields, So we are thinking may be in future we wanted to show something which we don't have in the Solr then we have to Re-index the full catalog to add new field into it and it may be very time-consuming.
I am in a favour of using Solr for showing PLP page instead of going to DB.Of course keeping Re-indexing in mind but not sure it is the best approach or not?
Please provide your suggestion or thoughts on this.
Thanks in advance.
The company i work for running Magento 1.7.0.2 with a Cart2quote extension.
They are getting frustrated because when they add a list of products to an order in admin the products dont stay in the order that they were inputted.
Example By SKU:
Order inputted-
D707
E018
P883
P882
Order when finished inputting-
D707
P882
P883
E018
I have only used 4 as an example, although more often than not it can be in excess of 50+ products.
Could this be due to an extension confilct with cart2quote or is there some other soloution?
Sometimes, buy pressing "Updates items and qtys" it does put them in a reverse order (first product is last) and they can live with that.
But as it is now, its making it frustrating for them to double check they have inputted the correct items.
Im sorry to waffle on, but any comments would be appreciated.
Many Thanks in advance.
Dale.
I'm not familiar with this extension, but check created time, updated time, id, etc when sorting.
I work on an educational website in which we show dynamic filters. What does this mean? We now have several course categories that will increase in number in the following weeks.
Right now categories are a string field in each course. I'm planning to model this and create a Categories table. Having done this, it would be pretty easy to load the filters based on the categories we have on the database. However, I see the problem that each time the website is loaded, the query will be made.
I thought of caching these categories but I'm guessing is not the best solution.
Any idea on how can I avoid these queries each time but get this information from the database?
I've been dealing with this problem with around 10k+ products in two store views in magento 1.7.
The URL indexing process took around 30 hours to change its state to ready. Also i found multiple entries of the same product being made in the core_url_rewrite table and the number of rows now reached upto 6500k.
This is causing deadlocks. I tried clearing the locks but that didn't help. Is there a workaround solution for this problem as this is magento core functionality?
There's some good general advice on the Magento Stack Exchange site covering common indexing problems.
It's also common for larger store to create a rewrite/code-pool-override for the following method
#File: app/code/core/Mage/Catalog/Model/Resource/Url.php
protected function _getProducts($productIds, $storeId, $entityId, &$lastEntityId)
{
//...
}
This method queries for the products that need a URL reindex. By default, this includes all simple and configurable products. However, if you're not displaying simple products individually, you can tweak this query to not include those products. That can greatly reduce the number of URLs Magento needs to generate.
I have some queries for Magento Indexing Process:
First of all, why Magento does not perform the indexing process programmatically, after each Product or any of its Attribute(s) are newly added / modified? Why Admin(s) require to do the indexing, when the indexing processes are very much important & can be done programmatically?
In each indexing process, are all the products indexed (including those which have been indexed already), when the "Reindex Data" link is clicked, or only the non-indexed products are indexed?
If I want to view / debug the time taken for each indexing process, then what & how will I need to do?
Three part answer, so this should be worth triple points, right? :)
1) Probably because indexing tends to be a computationally intensive task, so rather than slow the site whenever a product is saved (usually during business hours), an Administrator can choose a low-load period, or schedule via cron for the indexing to occur at a typically low-load time.
2) All products are re-indexed. If you look in Mage_CatalogIndex_Model_Indexer::plainReindex(), you will see that it performs a clear to delete all index data before getting all active products to index.
$this->_getResource()->clear(
$attributeCodes,
$priceAttributeCodes,
count($priceAttributeCodes)>0,
count($priceAttributeCodes)>0,
count($priceAttributeCodes)>0,
$products,
$stores
);
<snip/>
$collection = $this->_getProductCollection($store, $products);
$collection->addAttributeToFilter(
'status',
array('in'=>Mage::getModel('catalog/product_status')->getSaleableStatusIds())
);
$this->_walkCollection($collection, $store, $attributeCodes);
where the _walkCollection method creates the index for each product.
3) You could turn on the Profiler. There are some great blog posts on how to use that. You could wrap the key code in Mage_CatalogIndex_Model_Indexer with Varien_Profiler::start('Indexer') etc to check the time taken.
To expand a bit on Jonathan's answer, it would be silly to run entire indexes every time a product is saved. Magento's indexing process for things like category products involves truncating tables and running the index queries again. If you were to save 20 different products, and the indexes were regenerated for each of those, you'd have wasted major time. Since the system can't guess when you mean to save 20 products in a row, you are instead expected to run your indexes yourself.