Apache yerine nginx kullanırken ayrı bir MySQL sunucusu mantıklı mı

3 Cevap php

Consider a web app in which a call to the app consists of php script running several MySQL queries, some of them memcached. The PHP does not do very complex job. it is mainly serving the mysql data with some formatting.

Geçmişte ayrı kutulara mysql ve app motoru (PHP / Apache) koymak için tavsiye edilebilir için kullanılır.

Ancak, verileri yatay ayrılabilir zaman (örneğin zaman orada hizmetini kullanarak 10 farklı müşteriler ve müşteri başına veri bölmek mümkündür) ve nginx + FastCGI yerine ağır apache kullanılan zaman, bu koymak mantıklı değil aynı kutu üzerinde Nginx Memcache ve MySQL? daha sonra müşteri geldiğinde, benzer kutuları eklemek?

Arka plan: Biz Amazon Ec2 hareket ediyor. MySQL ve uygulama sunucusu için ayrı bir kutu (genellikle değiştirir gibi kod persistant tutmak için uygulama sunucularında gerekli) çift EBS hacimleri anlamına gelir. Şey veritabanı kutusuna olursa da, daha fazla müşteri başarısız olur.

Açıklama: Şu app (EC2 geçmeden önce), tek bir sunucu üzerinde LAMP ile çalışıyor.

3 Cevap

Sen yükü her ne kadar bellek dikkatle ölçmek gerekir - Ben (bu da web sunucusu çalıştırmak için seçtiği kaç süreçleri bağlıdır tüm RAM kullanacak PHP bulunuyor, Apache çok fark yapma vs enginex göremiyorum, ama bu ) bir akort sorunu daha fazla.

Şahsen ben üretimde böyle garip bir sunucu çalıştırmak için çok riskli olduğu gerekçesiyle uzak enginex uzak kalmak istiyorum.

Veritabanları her zaman ram çok ihtiyacım var, ve makul ayar bellek tamponları olabilir tek yolu adanmış sunuculara onları sahip olmaktır. Bu büyük veri var üstleniyor.

Eğer çok küçük veri varsa, aynı kutu üzerinde tutmak olabilir.

Eğer özel kutuları üzerinde çalışan değilseniz Aynı şekilde, memcached neredeyse hiç mantıklı. Memcached vermek MySQL belleği alıp gerçekten Paul ödemek Peter soymaktan. MySQL (Bu IO kaydeder, ancak memcached mümkün olabilir ki, vb sunum mantığı önbelleğe olmayacak gibi daha fazla CPU kullanan sona erebilir) oldukça verimli bir innodb_buffer_pool içinde şeyler önbelleğe alabilir.

Eğer ram dolu adanmış kutuları üzerinde çalışan eğer Memcached sadece mantıklı; Eğer app okuma-iş yükünü hizmet için db sunucularında yeterli hırıltı yoksa o da sadece mantıklı. Dağıtmadan önce bu düşünün.

Uygulama mimarisi zaten ayrı örnekler üzerinde Nginx ve MySQL desteği için tasarlanmış ise, size ayrımı haklı yeterince trafik alıncaya kadar aynı örneği tüm hizmetlerini barındırmak isteyebilirsiniz.

Genel olarak, tam yığını (Nginx + Sizin Uygulama + MySQL) ile yeni özdeş örneklerini oluşturarak kurulum çok daha zor korumak için yapacaktır. Bu yöntemi tercih ederseniz, gerçekten dengelemek amacıyla bazı büyük avantajlar bulmak gerekir, vb yedeklerini alarak uygulama güncellemeleri bırakmadan, veritabanı motorunu yama, veritabanı şemasını güncellenmesi, tüm müşterilerine raporlarını üreten düşünün bütün dezavantajları vardır.

Uygulama (Bu işe neden ben aslında, görmüyorum) farklı sunucularda PHP ve MySQL ile çalışmak mümkün ise, o zaman, o da aynı sunucuda PHP ve MySQL ile çalışacağız.


The real question is : will your servers be able to handle the load of both Apache/nginx/PHP, MySQL, and memcached ?

Ve bu soruyu cevaplamak için tek bir yolu var: Eğer kendi kendi sunucuları yüklü belirlemek için, bir "gerçek", "üretim" konfigürasyonunda test var - ya da ab, {[(gibi bazı aracı kullanmak 1)]}, ya da OpenSTA o yük "taklit" için.

Aynı sunucu üzerinde her şeyi ile çok fazla yük yok ise bu uygulama cheapier bir hosting yaparsa ... Eh, onunla gitmek ;-)

etiketler