Tôi đang sử dụng memcacheđể lưu trữ phiên và trên các trang danh mục tôi đã nhận thấy trong các giao dịch di tích mới, nơi bắt đầu phiên varien có thể mất hơn 30 giây.
Nó có thể có liên quan đến việc khóa phiên, nhưng tôi nghĩ đây không thực sự là vấn đề khi sử dụng memcache.
Bất cứ ai từng đối mặt với điều này hoặc có ý tưởng những gì có thể gây ra điều này.
Câu trả lời:
Tôi cũng đã thấy điều này khá nhiều trên Di tích mới.
Từ những gì tôi đã thấy có một vài nguyên nhân khác nhau, tôi không hiểu đầy đủ về vấn đề này nhưng đó là điều mà tôi đã xem xét gần đây. Đây là những phát hiện của tôi.
Mọi hành động của bộ điều khiển trong Magento đều sử dụng phiên, cho dù nó có cần hay không. Phiên được háo hức ngay lập tức trong Mage_Core_Controll_Varien_Action :: preDispatch
Nếu bạn đã bật khóa phiên, điều này có nghĩa là trong thời gian yêu cầu, phiên của bạn bị khóa cho đến khi yêu cầu hoàn tất. Tôi chưa tìm thấy đoạn mã nào phát hành khóa phiên, nhưng tôi khá chắc chắn rằng nó ở đâu đó.
Cuối cùng, điều này có nghĩa là nếu bạn thực hiện nhiều yêu cầu đồng thời với các hành động của bộ điều khiển Magento từ một vị trí bằng cùng một phiên, bạn sẽ phải chờ một số yêu cầu đó hoàn thành và mở khóa phiên để tiếp tục. Tôi thường thấy đây là một giao dịch chậm trên di tích mới bị kẹt Mage_Core_Model_Session_Abstract_Varien::starttrong khoảng 30 giây (tôi nghĩ rằng thời gian chờ khóa phiên của tôi).
Báo cáo này về Di tích mới có nhiều nhược điểm như tôi thấy
Tôi đã thấy một vài nguyên nhân phổ biến cho việc này, không phải là một danh sách dứt khoát bằng mọi cách
Các trình thu thập thông tin như Baidu và Yandex là một người hơi thô lỗ và làm hỏng trang web. Họ đang được chạy từ một địa điểm thực hiện nhiều yêu cầu, sử dụng cùng một phiên và vấp ngã cơ chế khóa phiên, do đó hiển thị các giao dịch chậm trong Di tích mới.
Với các trang web đa dạng, dữ liệu cụ thể của khách hàng phải được tải cẩn thận, một số trang web quản lý việc này bằng cách sử dụng các cuộc gọi ajax đến phụ trợ Magento để lấy dữ liệu cần thiết. Tôi cũng đã thấy một số trang web sử dụng các cuộc gọi ajax đến phụ trợ để có được thông tin cụ thể về sản phẩm, chẳng hạn như số tiền còn lại trong kho khi một mặt hàng được bán.
Nếu một trang kích hoạt nhiều cuộc gọi ajax đến phụ trợ khi tải trang, nó có khả năng kích hoạt cơ chế khóa phiên. Càng nhiều cuộc gọi ajax trở lại phụ trợ Magento, bạn càng có nhiều khả năng gặp phải tình trạng khóa.
Giống như trên thực sự, ngoại trừ thay vì sử dụng các cuộc gọi ajax, nó sử dụng Edge Side Bao gồm dường như là các cuộc gọi mới đến phụ trợ.
Tôi chưa hành động điều này vì vậy nó vẫn hoàn toàn là lý thuyết, nhưng đó là điều tôi sẽ làm trong vài tháng tới.
Tôi đã đưa ra vấn đề này trong hội nghị Mage Titans UK 2016 và Fabrizio Branca chỉ cho tôi hướng tới mô-đun sau: https://github.com/AOEpeople/Aoe_BlackHoleSession .
Dựa trên biểu thức chính quy, mô-đun sẽ ngăn Bots tạo các phiên thực, điều này sẽ có lợi ích là không có khóa phiên nào bị tấn công và tài nguyên phiên của bạn sẽ không bị đánh bại bởi các bot thô lỗ. Bots không còn gây ô nhiễm bài đọc Di tích mới của bạn.
Đối với các cuộc gọi ajax / ESI để lấy dữ liệu khách hàng ở đó trên các trang được lưu trong bộ nhớ cache, không có gì bạn có thể làm mà tôi có thể thấy. Bạn cần truy cập vào phiên để lấy dữ liệu cụ thể của khách hàng.
Tuy nhiên , đối với các lệnh gọi ajax / ESI để lấy dữ liệu cụ thể của danh mục (chẳng hạn như kho có giới hạn), tôi không thấy bất kỳ nhu cầu nào về phiên tồn tại theo yêu cầu đó cả. Kế hoạch của tôi trong tương lai là dùng thử một phần mở rộng cho Aoe_BlackHoleSessionmô-đun để tôi có thể tắt các yêu cầu đối với một URL cụ thể là không có phiên.
Tôi ít quen thuộc với các nội bộ của ESI, thật đáng buồn là tôi không có quá nhiều để nhận xét ở đó.
Trong hội nghị, Fabrizio Branca cho biết ông có thể vô hiệu hóa khóa phiên hoàn toàn mà không có bất kỳ ảnh hưởng xấu nào, hãy tự chịu rủi ro.