2013-08-26 26 views
12

CentOS 6'da Capistrano ile PHP dağıtımları kurdum ve ilginç bir sorunla karşılaştım. yolu capistrano işleri, böyle klasörleri kurar:Capistrano Symlinks Önbellekleniyor mu?

  • /var/www/myapp.com/
    • bültenleri paylaşılan
    • akım (In/bültenleri son sürümü sembolik bağın)

"Geçerli" bağlantı bağlantısına baktığımda, en son sürüme işaret eder. İlk başta, web uygulamamı açarken her şey iyi çalıştı. Yeni bir sürümü dağıttıktan sonra, geçerli klasörü, yeni sürüme doğru şekilde işaret eder, ancak web uygulaması eski sürümden (Capistrano temizleme işleminde silinmiş olan) dosyaları yüklemeye çalışır. Ayrıca, sanal konak, /var/www/myapp.com/current/Public adresinde işaret edecek şekilde yapılandırılmıştır.

Symlinks herhangi bir şekilde önbelleğe alınmış mı?

(benim çerçeveyi başlatır) başarısız belirli PHP kodu şudur: Şu anda /var/www/app.com/current/Public bulunan index.php içindedir

require_once dirname(dirname(__FILE__)) . '/App/App.php'; 
App\App::run(); 

/index.php.

Benim Apache hata günlükleri gösterir:

PHP Fatal error: require_once(): Failed opening required '/var/www/myapp.com/releases/20130826172237/App/App.php' (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/myapp.com/releases/20130826172237/Public/index.php

Ve akım sembolik link şovları: ikincisi önceki sürümü oldu

Açıkçası 20130826172641

current -> /var/www/zverse/releases/20130826172641

= 20130826172237!.

Bakabileceğim herhangi bir fikir veya alan var mı?

+1

Bir hıçkırık olmuş gibi görünüyor. Yaklaşık 10 dakika bekledim ve tekrar denedim ve işe yaradı. Bir çeşit Apache optimizasyonu olup olmadığını merak ediyorum? –

+0

PHP'nin gerçek yol önbelleğini devre dışı bırakın veya [mod_realdoc] (https://github.com/etsy/mod_realdoc) kullanın ve bu sorun sunucuyu yeniden başlatmaya gerek kalmadan gider. – Mahn

+0

Centos'taki nginx sunucusuyla aynı sorun, 'geçerli' sembolik bağlantı, en yenisine güncellenmeyecek. – Nimbosa

cevap

4

Bunu doğrulamak değil, ancak Apache aşağıdaki/yollarda bazı eski konumu önbelleğe bazı öngörülemeyen davranışları olduğu görülmektedir:

The only thing that would absolutely clear up this issue was to cycle Apache, which we would prefer not to do on every deployment. -- Mike Brittain

Symlink'i güncellemek yerine tüm dizinin taşınmasını önerir.

+2

Bilgi için teşekkürler. Ben hala sık sık sorunla karşılaşıyorum, ama benim Capistrano dağıtım sürecinin bir parçası yapmak sorunu gidermek gibi görünüyor bir "hizmet httpd restart" yapmak. –

+1

'service httpd reload' /' systemctl yeniden yükleme apache2.service' hiçbir kesinti gerektirmez ve aynı etkiye sahiptir. – smcjones

+0

Teşekkürler @smcjones - cevabı düzenlemek/topluluk cevabı yapmak ister misiniz? Şu anda – ptim

4

realpath_cache_size ve realpath_cache_ttl yönergelerini kontrol ettiniz mi? Varsayılan olarak, php> 5.1, sembolik dosyaların gerçek yollarını 120 saniye önbelleğe alır. Bu capistrano dağıtımlarında sorunlara neden olacaktır.Temel sorunlar önbellekleme işlemidir - önbelleğinizi temizleseniz bile, eski php dosyalarınız iki dakika boyunca sunulmaya devam eder, eski verilerle yeniden doldurulur - ve php ile statik dosyalar arasındaki etkileşim. Statik dosyalar doğrudan Apache tarafından sunulmaktadır, bu yüzden hemen güncellenecektir. Php kodu hala dağıtımdan sonra iki dakika için önceki sürümden olacaktır, bu yüzden herhangi bir değişmiş statik dosyaların eski sürümlerini bekler. Bu dosyaların adlarını değiştiren bir önbellek kesme yordamı kullanırsanız, özellikle sorun olur; Bu durumda php kodu, beklediği dosyaları bulamaz. Neyse, iki çözüm vardır. Birincisi, php.ini içerisinde realpath_cache_size değerini 0 olarak ayarlamaktır. (Not: 0 değerine realpath_cache_ttl ayarı değil önbelleği devre dışı bırakmaz.) Veya, etkin kalmasını istiyorsanız, gerçek bağlantı önbelleğini, bağlantı kodunuzu dağıttıktan hemen sonra bir capistrano kancası kullanarak temizlemek için clearstatcache işlevini kullanabilmeniz gerekir. . Bununla birlikte, eğer mod_php kullanıyorsanız, php cli ve apache çalışma zamanları ayrıdır, bu nedenle, clearing the APC cache here için yapılana benzer şekilde, apache tarafından çağrılan bir php betiğini kullanarak bu işlevi çağırmanız gerekir. Bunu test etmedim, çünkü önbelleği devre dışı bırakmaktan önemli bir performans etkisi görmedim.

+0

Realpath önbellek ile APC önbelleğinin doldurulması arasındaki boşluk arasındaki etkileşimle ilgili herhangi bir düşünce var mı? apc_clear_cache() php-fpm havuzunun tüm (paylaşımlı bellek) önbelleğini temizler ancak clearstatcache (true) yalnızca belirli bir php-fpm işleminin realpath önbelleğini temizler. Meşgul bir sistemde çalışan 4 php-fpm işlemim varsa, diğer 3 yine eski verilerden yine de çıkabilir mi? – jrg

+1

@jrg Tam olarak ne sorduğundan emin değilim. APC önbelleği ve gerçek yol önbelleği iki ayrı sorun. Sınıf haritanız için APC kullanıyorsanız veya böyle bir şey varsa, kodun yeni bir revizyonunu tekrarladığınızda geçersiz hale gelirse, dağıttığınızda bunu temizlemeniz gerekir. Realpath önbelleği ayrıdır ve php önbellekleme bağlantılarına başvurur; bu nedenle, clearstatcache komutunu çalıştırmadığınız sürece yeniden dağıtıldıktan sonra dosyaların eski konumlarını kullanır. Gerçekten sadece bir php işlemi için realpath önbelleğini temizlerse (test ettiğim gibi), hepsini temizlemek için bir yönteme ihtiyacınız olacaktır. –

+0

@jrg Web sunucusunu yeniden başlatmadan bunu nasıl yapacağınızdan emin değilsiniz. (Şahsen ben sadece realpath önbelleğini devre dışı bırakmanın fark edilebilir bir şekilde performansı etkilemediğini fark ettim. Yine, bu APC önbelleğinden farklıdır.) Dikkat edilmesi gereken diğer bir şey de, sınıf haritanızı önbelleğe almak için APC veya başka bir önbellek kullanıyor olmanızdır. Herhangi bir php dizinleri, realpath önbelleğini temizledikten hemen sonra bunu temizlemeniz gerekir; aksi halde eski değerlerden yeniden doldurulur. –