Magento Enterprise Lưu sản phẩm chậm (/ w và / wo Solr Integration)


7

Vấn đề:

Tiết kiệm sản phẩm đã trở nên chậm hơn trong 12 tháng qua

Lý lịch:

  • Magento Enterprise 1.14.1 (Vấn đề cũng có trong 1.13.0.2)
  • ~ 15.000 Sản phẩm, ~ 700 Danh mục, 2 Cửa hàng
  • Solr 3.6

Cuộc điều tra:

Sau khi lưu sản phẩm chậm trở thành một vấn đề, chúng tôi điều tra nhật ký truy vấn chậm, tìm thấy cùng một truy vấn xuất hiện: "UPDATE `catalogsearch_query` SET `is_processed`=0"xuất hiện trong khoảng 2-3 giây, chạy tương tự trên cục bộ, điều này đã tăng lên 7-10 giây.

Lý do cho truy vấn chậm này là trang web đang tìm kiếm rất nhiều và họ có hơn 400.000 hàng trong bảng catalogsearch_query đang được cập nhật với 0 không phải là một lượng dữ liệu khổng lồ để lưu trữ trong bảng MySQL nhưng là một số lượng lớn để cập nhật về một sự kiện thường xuyên như vậy.

Để làm cho vấn đề tồi tệ hơn sau khi xdebugging quy trình Magento đang nhấn phương thức Mage_CatalogSearch_Model_Resource_Fulltext :: resetSearchResults () 5 lần trong mỗi sản phẩm, hãy lưu lại mặt sau của danh mục sự kiện_product_save_commit_after gọi cho Enterprise_CatalogSearch_

Vì vậy, 5 lần * 3 giây cho kết quả sau 15 giây được thêm vào mỗi sản phẩm. 5 lần có vẻ quá mức cần thiết và có vẻ như một sự giám sát rằng resetSearchResults () được gọi rất nhiều lần vào cuối quá trình được kích hoạt bởi người quan sát này.

Nghiên cứu sâu hơn dường như có rất ít sử dụng cho is_processedlĩnh vực này trong cơ sở dữ liệu khi tích hợp Solr.

  1. Có ai gặp phải vấn đề này?
  2. Những hành động bạn đã làm?
  3. Bất kỳ đề nghị để tiếp cận?

Suy nghĩ ban đầu của tôi là cơ cấu lại quy trình để loại bỏ truy vấn trên catalogsearch_query sau khi điều tra đầy đủ tác động của nó.


Bạn đã thử xây dựng lại chỉ mục trên bảng db chưa? Hầu hết thời gian các chỉ số trên bảng là lý do.
andy1786

Không có chỉ mục cho catalogsearch_query, thực sự sẽ không cần nó với cách sử dụng dữ liệu. Vấn đề là không hiệu quả hơn với cấu trúc mã lõi Magento bộ dữ liệu lớn hơn.
john-jh

Câu trả lời:


5

Tôi đang gặp vấn đề này trong khi nâng cấp từ EE 1.13.0.2 lên 1.14.1.0 ngay bây giờ. Chúng tôi trải nghiệm điều này khi cập nhật hàng loạt các thuộc tính sản phẩm và cổ phiếu trong cronjobs. Trong 1.13, các công việc lần lượt mất ~ 3 giây và ~ 90 giây. Trong 1.14, nó giống như hơn 10 phút và tôi không muốn biết bao lâu.

Có một bản vá EE PATCH_SUPEE-4945_EE_1.14.0.1_v2.shliên quan đến việc tiết kiệm sản phẩm chậm. Bạn có thể yêu cầu nó từ hỗ trợ.

Một mẹo khác tôi tìm thấy là chỉ cập nhật các hàng chưa được đặt thành 0 (tất nhiên chỉ tạm thời thay đổi tệp lõi để kiểm tra xem nó có ảnh hưởng gì đến bạn không):

diff --git a/app/code/core/Enterprise/CatalogSearch/Model/Index/Action/Fulltext/Refresh.php b/app/code/core/Enterprise/CatalogSearch/Model/Index/Action/Fulltext/Refresh.php
index c6273a1..95e6d4c 100644
--- a/app/code/core/Enterprise/CatalogSearch/Model/Index/Action/Fulltext/Refresh.php
+++ b/app/code/core/Enterprise/CatalogSearch/Model/Index/Action/Fulltext/Refresh.php
@@ -668,7 +668,7 @@ class Enterprise_CatalogSearch_Model_Index_Action_Fulltext_Refresh
     protected function _resetSearchResults()
     {
         $adapter = $this->_getWriteAdapter();
-        $adapter->update($this->_getTable('catalogsearch/search_query'), array('is_processed' => 0));
+        $adapter->update($this->_getTable('catalogsearch/search_query'), array('is_processed' => 0), array('is_processed != 0'));
         $adapter->delete($this->_getTable('catalogsearch/result'));

         $this->_app->dispatchEvent('enterprise_catalogsearch_reset_search_result', array());
diff --git a/app/code/core/Mage/CatalogSearch/Model/Resource/Fulltext.php b/app/code/core/Mage/CatalogSearch/Model/Resource/Fulltext.php
index ee8b1c3..1d89146 100755
--- a/app/code/core/Mage/CatalogSearch/Model/Resource/Fulltext.php
+++ b/app/code/core/Mage/CatalogSearch/Model/Resource/Fulltext.php
@@ -299,7 +299,7 @@ class Mage_CatalogSearch_Model_Resource_Fulltext extends Mage_Core_Model_Resourc
     public function resetSearchResults()
     {
         $adapter = $this->_getWriteAdapter();
-        $adapter->update($this->getTable('catalogsearch/search_query'), array('is_processed' => 0));
+        $adapter->update($this->getTable('catalogsearch/search_query'), array('is_processed' => 0), array('is_processed != 0'));
         $adapter->delete($this->getTable('catalogsearch/result'));

         Mage::dispatchEvent('catalogsearch_reset_search_result');

Và cuối cùng, có một khuyến nghị để thêm một chỉ mục vào is_processedcột:

ALTER TABLE `database`.`catalogsearch_query` ADD INDEX `IDX_CATALOGSEARCH_QUERY_IS_PROCESSED` (`is_processed`) COMMENT '';

Tôi đã thử tất cả trong số họ và trong khi họ mang đến những cải tiến hiệu suất nhỏ, không ai trong số họ đưa tôi đến gần hiệu suất của EE 1.13.

Một sửa chữa dễ dàng (trên bề mặt) sẽ là thêm lại

if (!$this->_isFulltextOn()) {
    return $this;
}

vào đầu execute()cho các lớp này:

  • Enterprise_CatalogSearch_Model_Index_Action_Fulltext_Refresh
  • Enterprise_CatalogSearch_Model_Index_Action_Fulltext_Refresh_Cheachog
  • Enterprise_CatalogSearch_Model_Index_Action_Fulltext_Refresh_Row

Nếu tôi làm điều đó, đoạn mã sau không được thực thi vì Solr được cấu hình để sử dụng. Vì nhóm nòng cốt đã từ chối phương pháp này trong 1.14, điều đó thật xấu xí và tôi sẽ cố gắng tránh xa nó bằng mọi giá.

Tôi chỉ điều tra việc này từ hôm qua nên tôi hy vọng tôi có thể theo dõi với một giải pháp thích hợp.

Cập nhật ngày 09.02.2015

Tôi phát hiện ra bằng cách tạo kết xuất hồ sơ xdebug mà giao tiếp giữa Magento và Solr chiếm phần lớn thời gian System > Configuration > Advanced > Index Management > Index Options > Catalog Search Indexđược đặt thành Update on Save. Đặt Chỉ mục Tìm kiếm Danh mục để Update when scheduledcải thiện đáng kể tốc độ.

Cập nhật 03.03.2015

Trong khi đó, bộ phận hỗ trợ Doanh nghiệp giải thích lý do $this->_isFulltextOn()không được chấp nhận:

Chúng tôi đã xóa $ this -> _ isFulltextOn () khỏi phương thức thực thi vì chúng tôi đã tái cấu trúc bộ chỉ mục mysql_fulltext hiện tại để đóng gói công việc lập chỉ mục thực tế và điều chỉnh Danh mục SOLR Index để sử dụng mô hình lập chỉ mục dựa trên Mview mới.

Mô-đun Enterprise_CatalogSearch đã triển khai mô hình bộ chỉ mục mới, sử dụng thay đổi để tái hiện một phần. Hiện tại khi SOLR được sử dụng làm công cụ tìm kiếm danh mục, bộ chỉ mục catalogsearch_fulltext quay lại sử dụng mô hình bộ chỉ mục cũ. Chúng tôi sử dụng mô hình bộ chỉ mục mới trong mô-đun Enterprise_CatalogSearch khi SOLR được đặt làm công cụ tìm kiếm danh mục.

Do đó, nếu người bán muốn bỏ qua chỉ mục toàn văn bản trong khi lưu sản phẩm, vui lòng yêu cầu anh ấy / cô ấy thay đổi chế độ chỉ mục để cập nhật theo lịch trình.

Vì vậy, giải pháp chính thức khá nhiều là thay đổi Chế độ Index thành Update when scheduled. Chúng tôi đang sử dụng nó trong một vài tuần mà không có vấn đề gì. Nếu cron của bạn chạy mỗi phút, bạn sẽ chỉ gặp một chút chậm trễ cho đến khi tìm kiếm được cập nhật.


Tôi đang trong quá trình điều tra để đặt chỉ mục tìm kiếm được cập nhật theo lịch chứ không phải cập nhật khi lưu. Nhận sản phẩm dưới 1 giây tiết kiệm tại thời điểm giảm từ 15-30 giây. Đây không phải là bản sửa lỗi cho quy trình nhưng phương pháp chỉ mục thay thế sẽ dẫn đến lịch biểu chỉ mục gia tăng xử lý các thay đổi thay vì yêu cầu của người dùng. Chỉ cần điều tra nếu người lập chỉ mục theo lịch trình bị vấn đề tương tự.
john-jh

-2

Ngoài ra, kiểm tra xem bảng nhật ký của bạn có sạch sẽ và không bị đầy hơi. Điều này thường có thể chiếm 95% kích thước cơ sở dữ liệu và suy giảm hiệu suất nếu không được duy trì chính xác.

Chạy lệnh này trên bảng điều khiển SSH từ bên trong trang web gốc của bạn:

Trạng thái shell-log / php.php

và để làm sạch một cách an toàn

php -f shell / log.php sạch


Nó hoàn toàn không liên quan đến các tệp nhật ký. Tôi đã thực hiện từng phần của quy trình với xdebug và đó hoàn toàn là truy vấn được đề cập ở trên chạy 5 lần và mất 3 giây trở lên mỗi lần do nó cập nhật mỗi hàng trong bảng catalogsearch_query (hơn 400.000 hàng).
john-jh

Tôi không đồng ý vì kích thước của cơ sở dữ liệu tổng thể của bạn có thể ảnh hưởng đến tất cả các truy vấn không liên quan đến kích thước. Nếu như tôi đã thấy trước khi các bảng log_ * chiếm 80% kích thước cơ sở dữ liệu thì đó là bộ nhớ innodb_buffer_pool bị lãng phí. Vì tìm kiếm Magento mặc định luôn đặt mức độ liên quan thành 0 theo truy vấn bạn đang thấy đang chạy nên bạn có thể muốn xem lại thay đổi tùy chọn này: Hệ thống → Cấu hình → Danh mục → Tìm kiếm danh mục → Loại tìm kiếm Câu trả lời liên quan cho cùng một câu hỏi: stackoverflow.com/questions / 9117162 / Hoài
Stuart

Cơ sở dữ liệu dưới 6GB (nhỏ) các bản ghi được dọn sạch sau 30 ngày bởi cron. Chúng tôi đang sử dụng Solr chứ không phải MySQL Fulltext nên vấn đề trong bài đăng được liên kết không hoàn toàn ở đó. Giống như tôi đã nói trước hơn 400.000 hàng trong catalogsearch_query, tất cả được cập nhật 5 lần cho mỗi lần lưu sản phẩm sẽ chậm và từ những gì tôi có thể giải quyết vào lúc này là không cần thiết. Nó không đặt mức độ liên quan thành 0, nó đặt giá trị is_ Xử lý thành 0
john-jh

-3

Chúng tôi luôn thấy rằng khi bạn phải bắt đầu thay đổi chức năng cốt lõi, nó sẽ mở ra một loạt các vấn đề. Bây giờ có khả năng cao là chức năng tùy chỉnh hoặc tiện ích mở rộng gây ra sự cố, rõ ràng đơn giản nhất là tắt tất cả những thứ đó và sau đó thử, tốt nhất là trên một bản sao trang web. Chúng tôi đã tìm thấy trong quá khứ một cắt ngắn và reindex có thể giúp đỡ, một lần nữa với một bản sao lưu. Chúng tôi chạy trên các thiết lập khác nhau có thể phòng ngừa và do đó không chạy vào các vấn đề này, nhưng điều đó sẽ không được áp dụng trong trường hợp của bạn.


Nó không phải là do chức năng của bên thứ 3. Nếu bạn đọc lại vấn đề, có một sự cố hoàn toàn về những gì đang xảy ra, làm thế nào và tại sao, tất cả đều là cốt lõi.
john-jh

Không chính xác, trên quan điểm kinh doanh đã làm việc trên các trang web với Solr, hơn 100.000 sản phẩm, 15 cửa hàng và không bao giờ là vấn đề. Bây giờ có thể là do máy chủ không đủ, hoặc một phần mở rộng hoặc chức năng tùy chỉnh nhưng lõi hoạt động hoàn toàn tốt với các cài đặt lớn hơn nhiều. Cốt lõi không phải là vấn đề, bây giờ nó có thể là trang web của bạn và cách nó tương tác với lõi nhưng đó là một cái gì đó khác biệt.
Acornia

Có bao nhiêu hàng trong bảng catalogsearch_query? Core Magento EE gọi "UPDATE catalogsearch_querySET is_processed= 0" 5 lần cho mỗi lần lưu sản phẩm, nghĩa là phải cập nhật ~ 400.000 5 lần. Đó là 2.000.000 cập nhật hàng cho mỗi sản phẩm tiết kiệm. 400.000 cập nhật trong 2 giây Tôi sẽ không đến lớp chậm.
john-jh
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.