Bir Rails 3.1.0uygulamasında performans sorunları yaşıyorum , şimdi AR ile sorgularımda kubbe değişiklikleri yaptım ve bu yüzden görünümler hala işlemek için çok zaman alıyor, birçok kısmi görünümleri, döngüler vb. görünümlerin içinde ve diğer bölümlerin içinde dinamik olarak oluşturulur.
Yani çok sayıda partiye sahip olmak kötü bir uygulama mı?
Görüntüleme oluşturma süresini iyileştirmek için kısmi sayısını azaltmalı mıyım?
Teşekkürler
Yanıtlar:
Aynı içeriği oluşturduğunuzda , birçok kısmi ile tek bir görünüm arasında önemli bir oluşturma performansı farkı olmadığını biliyorum .
Açıkçası, bazı durumlarda yalnızca bazı kısımları ve diğer durumlarda diğerlerini, belirli bir görünümün oluşturma hacmini etkili bir şekilde azaltmanız, biraz hız kazanabilmenizdir.
Öte yandan, her zaman varlıklarını haklı çıkarmak için en az 2 farklı yerden kullanılması gereken kısmi soyutlamaları düşündüm. Kısmi kullanmanın diğer nedeni, aynı görünümü oluşturmak, ancak sahip olduğunuz bazı iş mantığına göre farklı kısmi yükler oluşturmaktır.
GÜNCELLEME:
İşleme hızı hakkında bir ölçüm veya bazı somut sayılar sunamıyorum. Bir görünümde kısmi kullanırsanız, bunu oluşturmak için render yöntemini çağırırsınız, böylece ikinci bir yöntem çağrısı olur. Cevabımda söylediğim gibi, bu neredeyse hiçbir şey değil ama işleri çok az hızlandırmaya yardımcı olabilir.
Ancak, bir projenin performans problemini, kısmi kaldırarak çözdüğünü hiç duymadım. Partials, görünümlere bir yeniden kullanım mekanizması sunmanın iyi bir yoludur ve programcılar açısından bu kapsamda kullanılmaları gerekir. Görüşlerde ortak kavramlar için soyutlamalar olmalıdırlar.
Kısmiların aşırı kullanıldığı bir proje üzerinde çalıştım. Rails değil, aynı MVC ilkeleri. Hayal edebileceğiniz her şey için küçük parçalar kullanmak, düzinelerce kullanmaya başladığınızda onları bulmayı zorlaştırır. Değiştirilecek bir girdiyi nerede ararsınız? Görünümde mi? Kısmi olarak mı? Hangi kısmi, bu görüş için 4 kısmi var? ...
Bazı sert yeniden düzenlemelerden sonra, bir görünümün her güncellemesinde, gereksiz kısmi kaldırdık. Tamamen yok olmadılar, ancak geriye kalanlar proje için iyi tanımlanmış soyutlaştırmalardır. Bir formda veya başka bir görünümde birkaç görünümde tekrarlanan iyi anlaşılmış öğeleri (bazı nesneler için bir ağaç veya belirli bir liste türü gibi) temsil ederler. Bunun için kısmi bir ağaç görüp görmediğimi biliyorum. Belirli bir liste türünü gördüğümde bunun kısmi olduğunu biliyorum. Onları avlamam.
Kod okunabilirliği, bir yazılım kodu tabanı için yapılabilecek en önemli şeydir.
Code readability, hepsi bu.
Her iki yanıta da katılmıyorum. Ben bir kopyasını ve kısmi üst görünümde kısmi olarak mevcut konuma kod yapıştırılmış ve 500 yinelemeleri ile, bu görünümü oluşturmak için zaman ayırmak büyük bir 600ms alır. <% = render xyz%> bence çok kırılmış.
Örnek, görünümü oluşturmak için toplam süre:
Before:
5759.8ms
5804.2ms
5973.6ms
After:
5268.7ms
5201.6ms
5222.4ms
Diff = 5846 - 5231 = 615 ms
Düzenlenen
_Model kısmi içindeki tüm _partials unDRYing sona erdi ve ~ 2000ms aşağı indi, bu noktada _model kısmi dizine taşımaya çalıştım ancak bu renderleme süreleri üzerinde herhangi bir etkisi yoktu, bu yüzden iç içe render çağrıları ile sanırım yapar.
Bir ray adam değil, ama Kısmi Görüşler büyük olasılıkla kendi başına sorun değildir. Aksine, biraz SELECT N + 1 yapıyormuşsunuz gibi geliyor. İşleri bir hamur haline getirmediğinizden emin olmak için DB sunucusunun bakış açısından bakın.
Şu anda ortalama 745ms süren yavaş bir eylemin olduğu bir Rails 4.2 uygulaması üzerinde çalışıyor.
Kodu kısmi olarak kaldırdığımda ve ana şablona yerleştirdiğimde, zamanın ortalaması 25 ms'den az.
Kısmi hale getirmek için yapılan çağrı sayısı sadece 29'du.
Hiçbir n + 1 probleminiz olmasa ve tüm veritabanını ön plana çıkarsa bile (özyinelemeli bir CTE ile), iç içe kısmi hala çok yavaştır. Haml ve Erb bana yavaş bakıyorlar. Rails 5.1.4 Her kısmi, artı çok daha kötü (muhtemelen çöp toplama karşılık gelen) için kısmi milisaniye birkaç milisaniye görüyorum.
Bu isteklerden biri çalışırken kısmi yeniden adlandırırsanız, hemen dosyanın nasıl bulunamadığı hakkında bir hata alıyorum fark ettim. Görünüşe göre Rails, kısmi kapalı diski okuyor, yeniden tarıyor ve her yineleme için değerlendiriyor. Şaşılacak bir şey yok!
Yuvalanmış kısmi parçalarda görülen yavaşlığın büyük kısmı sadece gelişim sırasında olur. Test etmek için üretime geçin.