Uzun Süreli Yönetici Sayfası İstekleri Diğer İstekleri Engelleme

Magento'nun arka ucunda oturum açmış ve uzun süren bir görev (büyük kataloglarda küresel arama, uzun süre çalışan veri akışı vb.) Gerçekleştirirsem, web tarayıcım diğer tarayıcı sayfalarını yalnızca bu tarayıcıya yüklemeyi reddedecektir . Bu neden oluyor ve geçici çözümler için bilinen herhangi bir bilim var mı?

Yani, eğer ben

1. Magento'nun gösterge tablosu sayfasında oturum açın

2. Herhangi bir Magento yönetici sayfasıyla ikinci bir sekme açma

3. İlk sekmede uzun süredir devam eden bir genel arama yapın ( sleep(30)başında bir çağrı ile simüle edilir globalSearchAction)

4. İkinci sekmeyi yeniden yüklemeyi deneyin

Beklenen Davranış: İkinci sekme hemen sayfa içeriğiyle yüklenir

Gerçek Davranış: İkinci sekme yalnızca uzun süredir devam eden global arama tamamlandığında yüklenir

Özellikle bunun neden olduğunu bilen var mı? (Benim tahminim Magento yönetici konsolu istekleri Magento'nun önyükleme yapması gereken bazı kaynakları kilitler, ancak bunun ne olduğunu bilmiyorum)

Bir düzeltme / geçici çözüm bilen var mı?

Soruna PHP oturum işleyicisi tarafından yerleştirilen bir kilit neden olur. Bu yüzden Magento açıkça bir şeyleri kilitlemek ve yönetici isteklerini engellemeye çalışmak değil, dosya tabanlı oturum depolamasının neredeyse bir yan etkisi.

Bir yazma kilidi çağırdığında kilit serbest kalıncaya kadar bloğun ikinci bir isteğe neden ilk (uzun soluklu) isteğe göre açılır oturum veri dosyası yerleştirilir olan session_startbölgesindekiMage_Core_Model_Session_Abstract_Varien::start

Bu% 100 tekrarlanabilir. Yaptığınız aynı yöntemi kullandım sleep(30), üstüne birMage_Adminhtml_IndexController::globalSearchAction

Dikkate değer bir db oturum depolama kullanıyorsanız bu çoğaltılamaz olduğunu. Kök nedenini bulduktan sonra, db oturum depolamasına bir sanal alan ayarladım ve artık sorunu yeniden oluşturamadım. Yani Magento db oturum işleyicileri oturum yazma kilitlemek için satır düzeyinde kilitleme kullanmıyor gibi görünüyor. Bu ilginç buluyorum, çünkü uygulama açıkça aynı oturuma yazma birden çok iş parçacıkları için muhasebe değil çünkü oturum veri kaybı potansiyeli vardır. Okuyucular için Not: Bunu denemek ve çözmek için üretimde asla db oturum depolamasını kullanmazdım, sadece MySql veritabanınızı aşırı yüklemek için iyidir.

Redis gibi bellek tabanlı oturum depolama sistemlerini kullanarak davranışı yeniden oluşturmayı denemedim, ama tahminim oturum deposundaki kayıtların kilitlenmesinin muhtemelen bu göz ardı edildi.

Bunu önlemek session_write_closeiçin uzun süren bir işe başlamadan önce kilidi açmak için kullanmak gibi teknikler vardır . Ancak bu, yeni kapattığınız için oturuma yazmanızı da engeller. Bu nedenle, Magento'daki genel kurulda kolayca uygulanması muhtemel değildir, ancak potansiyel olarak belirli rotalara / kontrolörlere uygulanabilir.

Bu kök nedeni olarak sabitlemek için benim teknik Xdebug profiler etkinleştirmek ve "cachegrind" dosyasını sınamak oldu. İkinci istek tamamlandıktan sonra, çıktı dosyasını (~ 25 MB günlük) MacCallGrind'e yükledim ve kapsayıcı sürenin 28 saniye veya daha fazla olduğu çağrıların yolunu izleyerek deldim . Bu sonuçta beni session_start~ 28 saniye süren aramaya götürdü ve araştırma yapmak için bana harika bir nokta verdi.

DÜZENLEME: ilgilenenler için, ben oldum bir ekran görüntüsü yayınlanmıştır Twitter'da MacCallGrind bakıldığında "cachegrind" dosyasının.