2016-04-06 33 views
0

Sunucumdaki müşterilerimden biri için bir OpenCart sistemi kurdum (Sunucu Debian Wheezy, Nginx, PHP ve MariaDB ile birlikte). Her şey bir şey hariç, iyi çalışıyor. Bir müşteri kayıt yapmaya çalıştığında, kayıt, 3 dakika civarında bir yerde büyük miktarda zaman alır. Sorunu izledim ve e-postaları müşteriye ve yöneticiye gönderirken büyük olasılıkla askıda kalıyor.Opencart kaydı çok uzun sürüyor

Sunucudaki e-postaları SSMTP ile hallediyorum, bu da kendi e-posta sunucumu kullanıyor. Joomla gibi diğer web uygulamaları da iyi çalışıyor ve herhangi bir gecikme olmaksızın e-posta anında gönderiliyor (sistemde mail komutuyla aynı). Opencart "posta" olarak ayarlandı (SMTP'yi doğrudan opencart'a girmeyi denedim, fakat çalışmadı).

Temel olarak OpenCarts'ın iç işleyişi hakkında hiçbir şey bilmediğimden, daha deneyimli bir kişi bana bu problemle yardımcı olabilir mi?

Şimdiden teşekkürler!

DÜZENLEME:

Ben başarıyla sorunun temel nedenini belirlemek mümkün olmuştur. PHP'nin veya OpenCart'ın hiç bir önemi yoktu, ama aslında bir sistem işi. Php.ini içindeki sendmail yolunun ayarları yorumlanmıştır, bu da PHP'nin kendi başına bulmaya çalıştığı anlamına gelir. Bazı nedenlerden dolayı OpenCart durumunda sSMTP için gitti. SSMTP eşzamanlı olduğundan, bitmesini beklemek uzun zaman aldı. Diğer yandan Joomla, Heirloom mailx'in sunucumda bazı eski bağımlılıklardan (neden hiçbir fikrim yok) unutulduğunu ve mail komutunun hemen çıkmasını sağladı, bu nedenle gecikme yok.

Saatlerce hata ayıklama ve deneme hatasından sonra yaptığım çözümüm, ssmtp ve mailx'i bir araya getirmek ve postayı harici sunucuya geçirmek için postfix kullanmaktı. Şimdi her şey beklendiği gibi çalışıyor.

cevap

0

Birazdan genelleştireceğim - karmaşık PHP sistemlerinde performans sorunlarının nedenleri.

aşağıdaki adımları izleyin:

  1. Xdebug PHP uzantısı
  2. yapılandır Xdebug en profiler (profiler_enable veya profiler_enable_trigger, profiler_output_path vb yükleyin) Bir tarayıcı içinde yavaş ve profiler_enable o ayarlı değilse, profil her istek için oluşturulacak ayarlanır ve profiler_enable_trigger sadece URL'ye XDEBUG_PROFILE parametre eklemek ayarlanırsa (yüklemek sayfaya
  3. gidin) dizine
  4. gidin size profiler_output_path yapılandırmış ve (işlev çağrısı çoğu zaman aldı this answer)
  5. kontrol ediniz, bazı GUI aracında profil çıktı dosyasını açın (bir işlev çağrısı sadece 5 ms alabilir Ancak, tek seferde 1000 kez çağrılırsa, 5 - Toplamda ds Bütün bu GUI aracında bilgileri)

Notlar görmelisiniz:

  • hiç gerek yoktu Xdebug bir üretim sunucusunda etkin (it)
  • yürütme yavaşlatır
  • Başvurunuz profiler_enable etkinleştirmeseniz, başkası tarafından erişilen ziyade profiler_enable_trigger, böylece istekleri profilleme
(profilci çıktı dosyası oldukça büyük olabilir) tetikleyebilir kontrol edebilirsiniz edilebilirse
+0

Cevabınız için teşekkürler, ama maalesef bana yardım etmiyor. Çevreyi geliştirme makinesinde çoğaltmayı denedim, ancak sorun mevcut değil (büyük olasılıkla dev sunucunun e-posta gönderemediği için). Sorunun olduğu sunucu, diğer birçok uygulama içeren bir üretimdir, bu yüzden orada xdebug yükleyemiyorum. – user2823584

+0

@ user2823584 Bir üretim makinesi olsa da, yine de yükleyebilir ve profiler ve "profiler_enable_trigger" dışındaki her şeyi devre dışı bırakabilirsiniz. Diğer uygulamaların performansını etkilememelidir. –

+0

@ user2823584 Cevabımı kabul ettiğiniz için teşekkür ederiz, umarım sorununuzu çözmenize yardımcı olur. Ama bu sadece bir rehberlik, eğer sorunu çözecek ve bunun yerine kabul edilmiş bir cevap olarak işaretleyecekseniz, sorunun kökeni ve çözümü hakkında detayları gönderebilmeniz iyi olacaktır. ;)). –

İlgili konular