RAM kullanımından tasarruf etmek için içeriği post değişkeninden hariç tutmanın bir yolu var mı?


9

Yani, WP RAM kullanım sorunu gibi görünüyor ve bir çözüm arıyorum.

Sitemde gerçekten bu sorunu yaşadığım tek yer doldurmaya çalıştığım bir Site Haritası sayfasıdır, ancak bu sorunun çözümü evrensel olarak uygulanabilir ve tüm sitedeki RAM kullanımından tasarruf edebilir.

Esasen, sahip olduğum bu Site Haritası sayfası, tüm postsve pagessitemdeki bir listedir . Bu sayfada erişmem gereken $ post değişkeninin tek öğeleri başlık ve kalıcı bağlantıdır. Ne yazık ki, kullandığım sorgu $ post değişkenlerinin her birindeki tüm bilgileri içeren tüm gönderileri döndürür.

Aşağıda, bu Site Haritası sayfasında custom-post-type, "ekler" ve "tüm ekler" terimlerinin özel sınıflandırmasına sahip "ürünler" adlı tek bir sorgu için kullandığım bir sorgu örneği verilmiştir. Site Haritası sayfamda bu tür birden çok sorgu var, ancak açıklayıcı amaçlar için yalnızca bu tek sorgunun kodunu dahil ediyorum.

 $varArray= array(
      'post_type' => 'products',
      'post_status' => 'publish',
      'supplements' => 'all-supplements',
      'posts_per_page' => -1,
      'orderby' => 'title',
      'order' => 'ASC'
 );
 $myProducts= new WP_Query($varArray);

$ Post değişkeninde kaydedilen bilgilerin büyük çoğunluğu (sitem için ve bu eğilimin genel kullanım için görüldüğünü tahmin ediyorum) "içerik" içinde bulunur Site Harita sayfam için tipik RAM kullanımı ~ 140MB (Hata Ayıklama Çubuğu tarafından rapor edilir), ancak sitemdeki diğer tipik sayfaların kullanımı 50-60 MB'dir. Büyük fark. Dün Site Haritası sayfası çalışmayı durdurdu (WSOD) ve düzeltmek için WP'nin kullanabileceği maksimum RAM miktarını arttırmak zorunda kaldım. Bu nedenle, tek bir sayfa nedeniyle gerekli sistem kaynaklarını artırıyorum.

Böylece soruma geliyorum.

İlgili getirmenin ediyorum ben eksik olduğunu Wordpress içinde bir patika / opsiyon yer var mı posts/ pagesnormal sorgusu gibi ama değil alınan mesajların içeriği olsun?

Ya da alternatif olarak, tüm $ post değişken sapmasını almak yerine belirli bir sorgudaki (Title / Permaklink / Slug / etc ...) belirli öğeleri almamın daha kolay bir yolu var mı?

Bana öyle geliyor ki birçok WP uygulaması için, bir gönderinin / sayfanın "içeriğinin" tipik olarak gerekli olacağı tek yer o sayfada pageveya postaçıkçası (burada istisnalar vardır) ve gönderiler için tam içeriğe erişimin olması / diğer sayfalarda sorgu ile alınan sayfalar basitçe aşırıya kaçıyor. Kayıt listesi sayfaları için tam içeriği yüklemekten kaçınmanın bir yolu varsa, önemli miktarda RAM kullanımı kaydedilebilir.

Herhangi bir yardım mutluluk duyacağız.

Yanıtlar:


8

Bellek kullanımını azaltmak için yayın verilerini doğrudan sorgulayarak ve filteryayınlama nesnelerini samplegeçmeden önce bir hile deneyebilirsiniz get_permalink().

Arkasındaki ayrıntılı akıl yürütme için get_permalink bellek kullanımı sorununa bakın .


Bu çözüm harika çalıştı. Biraz garipleştikten sonra. :) Özel taksonomi / terimi sorguya nasıl ekleyeceğimi bulmak zorunda kaldım, ama bu çok yardımcı oldu. Site Haritası sayfası artık 70MB RAM kullanıyor (Hata Ayıklama Çubuğuna göre). Harika işaretçi için teşekkürler.
Programcı Dan

4

Bunu dizinize eklemeyi deneyebilirsiniz:

'nopaging' => true,
'no_found_rows' => true,
'update_post_meta_cache' => false,
'update_post_term_cache' => false

Oldukça açıklayıcı görünüyor, ancak aslında tüm gönderi değişkenlerini ve sadece ihtiyacınız olan şeyleri sorgulamıyorsunuz.


2

Programcı Dan, mah adam!

Global SELECTolanı kullanarak özel sorgulara başlayalım $wpdb. Codex, Özel Seçim Sorgusu Kullanarak Yayınları Görüntüleme konusunda harika bir girişe sahiptir . Eğer faydalanırsanız setup_postdata(), standart Wordpress döngüsünde oturuyormuşsunuz gibi sonuçlar arasında geçiş yapabilirsiniz:

global $wpdb;

$sitemap_query = "
    SELECT $wpdb->posts.ID, $wpdb->posts.post_title, $wpdb->posts.guid
    FROM $wpdb->posts
    WHERE $wpdb->posts.post_status = 'publish' 
    AND $wpdb->posts.post_type IN ('post','supplement','another_post_type')
    ORDER BY $wpdb->posts.post_type, $wpdb->posts.post_title DESC
    ";

$sitemap_nodes = $wpdb->get_results($sitemap_query, OBJECT);

if( $sitemap_nodes ):
    global $post;
    foreach ( $sitemap_nodes as $post ):
        setup_postdata( $post );
        ?>

<!-- //Use standard Wordpress template tags for SELECT'd data within The Loop here -->
    <?php the_title() ?>
    <?php the_permalink() ?>

        <?php
    endforeach;
endif;

Bu sorgu yalnızca yazıların kimliklerini, başlıklarını ve GUID'lerini (bir gönderinin kalıcı bağlantısını belirlemek için kullanılır) ve diğer her şeyi kesinlikle yok sayar. Daha post_typesonra sonuçları o zamana kadar sıralar post_title, ancak yazı türlerinizi ayırmak için birden fazla sorgu kullanmak isteyebilirsiniz (teorik olarak küçük bir performans isabinde).

İhtiyacınız olan sonuçları almak için kullanımı atlamak setup_postdata()ve basitçe döngü yapmak $sitemap_nodesveya sorgu ile uğraşmak isteyebilirsiniz.

Arama yapar setup_postdata()ve hata ayıklama modunu etkinleştirirseniz, aramalar büyük olasılıkla (kasıtlı olarak) eksik bilgilerle ilgili sol ve sağ bildirimler yayınlar. @Özel sorgunuzun düzgün çalıştığını onayladıktan sonra, işlev çağrısından önce bunları bastırmak için a atmak isteyebilirsiniz .

Ama bu başlasın! Sorgulamanız gereken alanları bulmak için aşağıdaki veritabanı şemasına ( Codex üzerindeki Veritabanı Açıklaması sayfasından) başvurabilirsiniz :

Wordpress Veritabanı Şeması

DÜZENLE:

Bellek açısından en verimli çözüm, özel bir SELECTsorguyu @ Rarst'ın korumasıyla birleştiren çözümdür :)


1

WP_Query şöyle bir "dönüş alanları" parametresine sahiptir:

$args = array(
 'fields' => 'ids'
);
$query = new WP_Query( $args );

Bu şekilde kullanıldığında, WP_Query tüm posta nesnesini değil, yalnızca posta kimliklerini döndürür. Sonra sadece kullanabilirsiniz get_permalink(), get_the_title()sonrası kimliğine dayalı içeriği almak için, ve diğer çeşitli WordPress fonksiyonları.


1
Yazının kimliğini kabul eden işlevlerin genellikle get_post()tam veri almak için hemen üzerinde çalıştığını ve bu nedenle yalnızca kimlik alma amacını tamamen ortadan kaldırdığını unutmayın.
Nadir

1
Bunu bildiğim iyi oldu! Zeki olduğum izlenimindeydim.
Dalton
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.