Düz dosyalar? Nooooooo ...

İyi bir DB motoru (MySQL, SQLite, vb) kullanın. Ardından, maksimum performans için, cache içeriğe memcached kullanın.

Aklında bir kaç şey tutun:

1. MySQL sorgu önbelleği vardır. Eğer repeteadly aynı sorgular veren, bir önbelleğe alma katmanı eklemeden çok fazla bir performans elde edebilirsiniz.
2. MySQL yine de gerçekten hızlı. Yüklemek-test ettik o yeterince hızlı değildir göstermek için?

Bakıcılarına aklı için, düz dosyaları kullanmak etmeyiniz.

Sadece mümkün olduğunca hızlı, paylaşılan veri var, ve daha sonra, RAM içinde tüm tutabilir arıyorsanız memcached mükemmel bir çözümdür.

Veri kalıcılığını istiyorsanız, o zaman MySQL gibi bir DBMS kullanmak.

Eğer küçük bir veri, çoğunlukla statik miktarda paylaşan Genellikle, DB, ancak, daha iyi, düz dosyaları ile yapıyor performans avantajları (ve basitlik) olabilir.

Önemsiz veri paylaşımı başka bir şey ve ben ancak bir DB almak istiyorum.

1- Where the flat file can be usefull: Flat file can be faster than a database, but in very specific applications. They are faster if the data is read from start to finish without any search or write. If the data dont fit in memory and need to be read fully to get the job done, It 'can' be faster than a database. Also if there is lot more write than read, flat file also shine, most default databases setups will need to make the read queries wait for the write to finish in order maintain indexes and foreign keys. Making the write queries usually slower than simple reads.

TD/LR vesion: Use flat files for jobs based system(Aka, simple logs parsing), not for web searches queries.

2- Flat files pit falls: If your going with a flat file, you will need to synchronize your scripts when the file change using custom lock mechanism. Which can lead to slowdown, corruption up to dead lock if you have a bug.

3- Ram based Database ? Most databases have in memory cache for query results, search indexes, making them very hard to beat with a flat file. Because they cache in memory, making it run entirely from memory is most of the time ineffective and dangerous. Better to properly tune the database configuration.

RAM kullanarak performansını optimize etmek isteyen varsa, ben ilk php scrips, html sayfaları, ve bir koç sürücüden küçük görüntüler çalışan bakmak olacaktır. Cache mekanizması ham olması ve sigara statik verileri değiştirmek için sistematik sabit sürücü vurmak için daha muhtemel olduğu.

Daha iyi sonuç tabanlı SAN dizi ram kadar bir geri düzlem bağlantıları ile bir yük dengeleyici, kümeleme ile ulaşmak olabilir. Ama bu bambaşka bir konu.

5 - Birden çok komut aynı anda aynı DB bağlanabilir?

Yes, its called connection pooling. In php (client side) its the function to open a connection its mysql-pconnect(http://php.net/manual/en/function.mysql-pconnect.php). You can configure the maximum open connection in php.ini I think. Similar setting on mysql server side define the maximum of concurrent client connections in /etc/mysql/my.cnf.

Sen cpu PARRALLEL processessing yararlanmak ve birbirlerine bitiş sorgu beklemek php komut dosyası önlemek için bunu yapmanız gerekir. Bu büyük ölçüde, ağır yük altında performansını artırmak.

Normal web müşterileri için Apache yapılandırmasında bir bağlantı havuzu / iş parçacığı havuzu da bulunmaktadır. Httpd.conf bakın.

Sorry for the wall of text, was bored. Louis.

Birden sunucularında çalıştırıyorsanız (eğer olası değildir ve ölçeklenebilir olmayabilir tutarlı, paylaşılan dosya sistemi, var sürece), bir dosya sistemi tabanlı bir yaklaşım kesmeyecek.

Bu nedenle web sunucuları arasında veri paylaşımını sağlamak için yine bir sunucu tabanlı veritabanı gerekir. Eğer performans veya kullanılabilirliği hakkında ya da ciddi iseniz, uygulama birden çok web sunucuları destekleyecek.

Ben düz dosyalar (ve erişim kontrolü için bir yol) üzerinde kilitleri ile uğraşmak yerine bazı mekanizması yoksa MySQL DB daha iyi bir seçim olacağını söyleyebilirim. Bu durumda DB katman (Belirli DBMS) bu konuda endişelenmeyin icar, bir yönlendirme katmanı olarak davranmaktadır.

OP bir web sunucusu belirtmek değildir (ve PHP aslında bir komut ile çalıştırabilirsiniz) beri sonra önbelleğe alma teknolojileri burada sonra konum ne emin değilim. OP dönüşümü uçan veri çeşit yapmak isteyen olabilir et tahrik değildir. Kim bilir.

Sisteminiz bir PHP önbelleğini (önbelleklerini APC gibi, bellekte PHP kodu derlenmiş olduğu) varsa, PHP kodu olarak, bir PHP dosyasına veri koyarak deneyin. Eğer veri yazmak zorunda kalırsanız, bazı güvenlik sorunları vardır.

I need a simple way for multiple running PHP scripts to share data.

APC, ve memcached hem bağlama göre iyi seçeneklerdir. shared memory da bir seçenek olabilir.

Should I create a MySQL DB with a RAM storage engine, and share data via that (can multiple scripts connect to the same DB simultaneously?)

Bu da iyi bir seçenek, ama muhtemelen APC veya memcached kadar hızlı olmayacaktır.

Or would flat files with one piece of data per line be better?

Bu verileri salt okunur, bu bir olasılık - ama yukarıdaki seçeneklerden birini daha yavaş olabilir. Veri büyükse özellikle. Aksine özel ayrıştırma kod yazma yerine, ancak, sadece bir PHP dizi bina düşünün, ve () dosyası içerir.

Bu aynı anda birkaç yazarlar tarafından erişilebilir bir veri deposu ise, elbette düz bir dosya kullanmak değil! Birden süreçlerinden düz bir dosyaya yazma yolsuzluk dosyası yol açması muhtemeldir. Siz dosyayı kilitlemek, ancak kilit çekişme sorunları ve uzun kilit bekleme süreleri risk.

Eşzamanlı yazıyor Taşıma mysql ve memcached gibi uygulamalar var nedenidir.