Hazırlanan tablolar PHP ile birden fazla sayfa yükleri arasında sunucu tarafında önbelleğe alınır?

7 Cevap php

JDBC-etkin bir Java uygulaması yaparken ben hazırlanmış deyimleri öğrendim ve benim app ifadeler sunucu tarafında önbelleğe ve bu bir performans fayda verir Hazırlanan bana garanti bir bağlantı havuzu katmanı kullanır.

Ancak, PHP ile okudum her şeyi onlar sadece sayfa yük yaşam için önbelleğe söylüyor. Genellikle aynı sorguda birçok kez tekrarlayın, ancak belirli bir sayfa yük üzerinde birkaç farklı sorgular, koşmak, ancak birden çok sayfa yükleri arasında, onları tekrar yok.

Benim PHP işlemler (yani PHP-FPM kullanıyorsanız, bunun yerine sadece biri yaşamları boyunca yüzlerce sayfa hizmet edecek) kalıcı oldukları gibi yenkimliken kullanımı veritabanı bağlantıları olacak, ben oldukça yumurtlama ve her vurmak için onları öldürme dışında, merak ediyordum .

  1. Mysqli'nin veya PDO ile PHP-FPM'yi kullanarak tek bir sayfa yük daha uzun bağlantıları tutmak mı?
  2. Eğer bu olmuyorsa, ben bunu yapabilirim?
  3. Öyle ya ben 2. yaparsanız, bu sadece bir sayfa yük daha uzun hazırlanan tabloların önbelleğe devam edecek?

Edit:

Sadece netleştirmek için, ben tamamen başka bir canavar sorgu önbellek, hakkında konuşurken, ya da sorgu çıktısını önbelleğe değilim. Ben derlenmiş hazırlanmış deyimi ve yürütme planı sunucu tarafında önbelleğe istiyorum.

7 Cevap

When a request is served php "cleans" the instance and frees resources and other variables. This is done in several steps. Since fastcgi keeps the process alive after a request not all steps are executed and not all memory is freed. There is e.g. EG(persistent_list) which is used by mysql_pconnect(), pg_pconnect(), ... This list isn't emptied between requests as long as the process keeps alive (could be, depending on the actual implementation, but that would defy the purpose of EG(persistent_list)). If you use persistent connections your script might get a "re-used" connection established during a previous request.
To (re-)use a prepared statement directly you need the identifier for that statement (and that connection). When using (php-)postgresql this is simply a (connection-wise) unique string you pass to pg_execute(), so your script has no problem to gain access to the statement previously prepared by another instance (using the same connection).
Using mysqli or PDO-mysql you need a resource/object as statement identifier. That's kind of a problem since neither the mysqli nor the pdo extension seem to offer a way of storing the resource in EG(persist_list) between requests and you can't recreate it either. Unless php-fpm offers such a "service" it's seems impossible to re-use a mysql prepared statement directly.
All you can hope for is MySQL's server-side query cache. In recent versions (see link) it may recognize the statement when using prepared statements. But even then it doesn't re-use the actual prepared statement:

For a prepared statement executed via the binary protocol, comparison with statements in the query cache is based on the text of the statement after expansion of ? parameter markers. The statement is compared only with other cached statements that were executed via the binary protocol. That is, for query cache purposes, statements issued via the binary protocol are distinct from statements issued via the text protocol.

Yanılmıyorsam Yani, şu anda php önceki istek sırasında hazırlanan bir mysql deyimi yeniden kullanamazsınız.

Siz veritabanında happenning ne ile PHP / Java kademedeki neler olduğunu karıştırıyorsun.

Evet, hazır deyimleri (genellikle) kullanarak yürütme planı veritabanının kendisi (NOT PHP / Java kademe) tarafından önbelleğe anlamına gelir. Ancak bu her zaman iyi performans sonuçları takip etmez - ve bu bir açıklama birkaç yüz sayfa alacaktı. Ancak ben size (depolama motorları IIRC hiçbiri histogramlar uygulamak) tartışma biraz daha basit hale DBMS olarak MySQL kullanıyorsanız başka bir yerde söylediğim ne anlaması. Tipik MySQL herhangi bir disk I / O olmadan bir plan oluşturmak edebilmek için bir şema hakkında yeterli bilgileri önbelleğe mümkün olacak Inlined değerlerini kullanarak bu tur gezileri üzerine ortadan kaldırır iken OTOH, hazırlanmış deyimleri kullanarak her sorgu için DBMS üç yuvarlak gezilerinde en az ortalama (bugünkü deyimi, mevcut params, sonuç almak). Histogram indeksler yokluğunda, değişkenlerin değerleri iyi duruma göre en uygun tespit planına ilgisi yoktur.

Eğer tek veya kalıcı ya da havuza bağlantıları ile PHP, veya PHP-FPM veya Java kullanarak olduğu gerçeği hazırlanan-ifadeleri / DBMS tarafından yeniden kullanılır önbelleğe olup olmadığını ilgisi yoktur.

HTH

C.

PHP uygulama veritabanı bağlantı havuzu kullanır ve veritabanı önbelleklerini ifadeleri hazırlanmış ise, o zaman evet, önbelleğe alma sayfaları arasında devam edecek. Hazır deyim önbelleğe istemci kitaplığı tarafından yapılırsa, o zaman bu daha belirsiz olduğunu.

Bağlantı havuzu kullanmak için onları anlatmak için nasıl görmek için PHP-FPM ve / veya PDO için dokümanlar bakmak gerekir. Bunu yapmak için hem de bir seçenek olmalıdır.

MySQL bağlantı kurulum ve devrelerde aslında çok hızlı ve çok PHP sistemler, çünkü bu bağlantı havuzu kullanmayın farkında olmalıdır. Her iki şekilde de, ayrıca sunucu ayarları, özellikle wait_timeout parametrede zaman yatırım gerekir. PHP ayrıca sayfaları başladığında ihtiyacınız olan her şeyi oluşturmak fikri etrafında tasarlanmış ve tüm zaman sayfa bittikten uzağa gider. Çoğu PHP kodu ve kütüphaneler bu durumda olduğunu varsayalım. Bu Java altında göre oldukça farklı bir paradigma.

Tek gerçek cevap it depends.

Bu MySQL gelince hazırlanan tablolar titiz hayvanlardır. Bir hazır deyim önbelleğe alınmış olup olmadığını belirleyen faktörlerin çok sayıda vardır.

Lütfen sürüm ise genel bir fikir < 5.1.17, hazır deyim never sorgu önbellek önbelleğe ve> = 5.1.17 kullanıyorsanız, it depends olduğunu.

MySQL 5.1 kılavuzda aşağıdaki sayfaya bakın lütfen:

http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.html

Eğer p ekleyerek kalıcı bir bağlantı oluşturmak için mysqli zorlayabilirsiniz: hostname, başı olarak: http://www.php.net/manual/en/mysqli.persistconns.php

Tartışıldığı Ancak, hazırlanan tablolar her zaman burada, sayfa yükler arasında kapalı: http://dev.mysql.com/doc/refman/5.0/en/apis-php-mysqli.persistconns.html

Üzgünüm, bildiğim kadarıyla yapılamaz. Hazırlanan tablolar, tek bir sayfa yük içindir.

Hazırlanan ifadeleri sonucu önbelleğe alma ile ilgisi var.

Sonuç önbelleğe alma db sunucu konfigürasyonu ile kontrol veya memcached ve benzeri yoluyla zorlanamaz.

Özellikle PHP http://www.php.net/manual/en/book.memcached.php, sen memcached içine bakmak öneririz

PHP çoğu sorguları ne de sorgu sonuçlarını önbelleğe almaz. MySQL bakılmaksızın önbelleğe bu tür gerçekleştirmek edecek ya da sorgu yayımlayarak ne konu veya bağlantı.

Birden fazla sayfa yükleri veya birden çok sunucu arasında sunucu tarafında önbelleğe alma istiyorsanız, o zaman MySQL sorgu önbelleğe alma ve sunucu tarafında önbelleğe alma (APC, dosya tabanlı önbelleğe alma, memcached, vb) kullanın.