Symfony2 uygulaması VirtualBox'ta çok yavaş

Question

Nginx/php5-fpm/MySQL yığınında daha büyük boyutlu bir PHP uygulaması geliştirmek için VirtualBox'ta sanal bir kopyasını sanal kutuda çalıştırıyorum. Geliştirme, ana işletim sisteminde (Windows 7 x64) gerçekleşir, kod konuk işletim sistemindeki paylaşılan bir klasör olarak kurulur.

Performans çok kötü. yerli vbox dosya sistemi için webgrind çıkışları şunlardır ve samba cifs ile monte:

filemtime, file_exists ve is_readable çalıştırmak için birkaç saniye sürebilir Her iki durumda da. CPU yükü çok yüksek, hafıza kullanımı normal görünüyor.

Bu üç işlevden herhangi birinin çıktısı, önbellekte önbelleğe alınmadı mı? Neden bu kadar uzun sürüyorlar?

Elde edebileceğim herhangi bir yardımı gerçekten takdir ediyorum!

Düzelt: Netleştirmek gerekirse, üretim performansı iyidir. Bizim (uygun, sanal olmayan) evreleme sunucusunda PHP kodu üretim ayarlarında ~ 60ms max ve dev modunda 100-200 ms arasında bir yerde yürütülür.

VirtualBox, neden & prod modunda neden 100x daha yavaş olduğunu bulmak için yardıma ihtiyacım var.

Sadece kontrol ettim, üretim ayarları ~ 5sec yürütme verim. Hala kullanışsız, artı geliştirmek için garip.

Answer 1

nfs dosya paylaşımını kullanın. Samba ve vbox dosya paylaşımı çok yavaş olabilir.

Profillemeniz, dosya sistemi işlemlerinin darboğaz olduğunu gösterir.

Daha fazla bilgi edinmek için bu blog yazısı http://clock.co.uk/tech-blogs/virtualbox-404-shared-folder-update oku

Answer 2

Yakın bir zamanda benzer bir soruya cevap verdim. Önceki cevabımı here bulabilirsiniz.

Küçük bir özgeçmişini yapacağım. Uygulamanızın performansını yalnızca app_dev.php ön denetleyiciye dayanarak ölçmemelisiniz. Bu denetleyici yalnızca geliştirme amacıyla kullanılmak üzere oluşturulmuştur. Geliştirme sırasında, yapılandırma dosyaları, dal şablonları, varlıklar vb. Pek çok değişiklik yaparsınız. Symfony, değişiklik yapmak için yüzlerce dosyayı kontrol eder ve gerekirse daha önceden önbelleğe alınmış bir çok şeyi yeniden yükler. Böylece, filemtime, ve is_readable numaralı telefonlara yapılan çağrı sayısı çok yüksektir. Tüm bu çağrılar üretim modunda atlanır çünkü Symfony önbellekteki her şeyin güncel olmasını bekler. Böylece, hemen hemen her şey üretim modunda önbelleğe alınır ve dosyanın değiştirilmiş olup olmadığına bakılmaksızın Symfony kontrol edilmeden hemen önce kullanılır. Bu, büyük bir performans artışı sağlar, çünkü geliştirme sırasında tek bir dosyayı yeniden yüklemek, onu ayrıştırmak için çok zaman alabilir, bağımlılıkları kontrol edebilir, bu dosyalara bağlı olarak herşeyi yeniden başlatır.

Uygulamanızın karşılaştırmasını yapıyorsanız, üretim modunda olduğundan emin olun. En azından, tüm donanım kurulumlarını üretimde beklediğiniz gibi yapamazsanız, aşağıdaki adımları uygulayın. Önbellek üretim modu için temizleyin ve app_dev.php yerine app.php kullanın. Ayrıca, belgelerindeki symfony.com adresinde bulunan performance'daki bölümü kontrol edin. Burada konsol, üretim ortamınızda önbelleğinizi temizleyip ısınmaya çağırır. Ben cache:clear de önbellek ısınma düşünüyorum ama% 100 emin değilim çünkü, ben her iki arama yapmak için tercih: Bu yardımcı olur

php app/console cache:clear --env=prod --no-debug 
php app/console cache:warmup --env=prod --no-debug 

Umut.

Selamlar, Matt söylediklerine ek olarak Matt

Answer 3

Sana dal uzantısını derlemek ve php modülü olarak kullanmayı öneriyoruz. Şablonları daha hızlı üretecek. Ancak yine de en önemlisi uygulamanızı prod ortamında yürüten, ancak uygulamada veya testte bulunmayan herhangi bir karşılaştırma yapmaktır. Xdebug modülünü üretime yüklemediğinizden emin olun, çünkü aynı zamanda testlerinizi de yavaşlatacaktır.

Tam ayarlarınızı bilmiyorum, ancak uygulamanın mümkün olduğunca az istekte bulunmasını sağlamak için AppCache yerine uygun ters proxy (aka Vernik) yüklerseniz daha iyi sonuçlara sahip olursunuz.

Answer 4

Sadece bu kravat:

ben misafir OS üzerinde samba paylaşım kurmak Sonunda, ikinci bir ağ adaptörüne bağlı (host-only, like in this guide) ve ana işletim sistemindeki bir ağ sürücüsü olarak bunu monte etti.

Biraz rahatsız edici, ancak yürütme süreleri, devasa modda 5-13 sn'den 100-500 ms'ye kadar.

Answer 5

Aynı sorunu giderdikten sonra, SM'de ve ana makinede kodun senkronize halde kalmasını sağlayan bir rsync cron ayarlayarak düzeltin./

Blogged about my solution in detail if you are interested