Zrádné počty zobrazení příspěvku

K napsání tohoto příspěvku mě inspiroval blogpost “Admin-ajax.php zpomaluje stránky”, který správně uvádí proč byl daný web pomalý a jak byl problém, aspoň částečně, odstraněn. Proč je problém odstraněn jen částečně rozvádím ke konci tohoto příspěvku.

Vývojář se čas od času setká s poždavkem na zobrazování počtu zobrazení příspěvku na frontentu. Ovšem taková feature je celkem zrádná. V čem je problém?

Na otázku kam s daty si většinou vývojář celkem rychle odpoví, že přeci logicky patří do post_meta.

Tím velmi jednoduše získá místo, kam své údaje může ukládat. Pokud navíc nechce skladovat žádné další údaje o tom, kdo kdy odkud a jak se na web podíval, bude se jednat jen o číslo a takové číslo moc místa v databázi nezabírá. Jednoduché.

První nástřel fungování může vypadat takto:

//Uložíme shlédnutí do databáze
add_action( 'wp_head', function() {
    if ( is_single() ) {
        //získáme uložená data
        $pageviews = get_post_meta( get_the_ID(), 'myawesome_pageview', true );
        //zvětšíme o jedno
        $pageviews = intval( $pageviews ) + 1;
        //znovu uložíme
        update_post_meta( get_the_ID(), 'myawesome_pageview', $pageviews );
    }
}, 10, 0 );

//funkce pro zobrazování počtu shlédnutí
add_filter( 'the_content', function( $content ) {
    if ( ! is_single() ) {
        return $content;
    }
    $content .=  "\nZobrazeno: " . get_post_meta( get_the_ID(), 'myawesome_pageview', true ) 'x';
}, 10, 0 );

Těhle pár řádků kódu dělá přesně to, co vývojář řekl. Ukládá a zobrazuje počty načtení příspěvku.

Jak na page level cache

Pokud ovšem web, na kterém je takový kód přítomný, používá nějaký cachovací plugin, nebude nepřihlášenému uživateli (tedy většině) kód fungovat, jelikož se akce wp_head nespustí, nic se neuloží a zobrazovat se bude stále stejný počet zobrazení uložený spolu s celou stránkou ve statickém HTML.

Ovšem i tento problém lze celkem jednoduše vyřešit pomocí AJAXu:

<?php
add_action( 'wp_ajax_add_pageview', 'myawesome_pageview_add_pageview' );
add_action( 'wp_ajax_nopriv_add_pageview', 'myawesome_pageview_add_pageview' );

//Uložíme shlédnutí do databáze
function myawesome_pageview_add_pageview() {
    $post_id = $_REQUEST['post_id'];
    //získáme uložená data
    $pageviews = get_post_meta( $post_id, 'myawesome_pageview', true );
    //zvětšíme o jedno
    $pageviews = intval( $pageviews ) + 1;
    //znovu uložíme
    update_post_meta( $post_id, 'myawesome_pageview', $pageviews );
    die( $pageviews );
}

//funkce pro zobrazování počtu shlédnutí
function myawesome_pageview( $post_id = null ) {
    if ( false === empty( $post_id ) && true === is_singular() ) {
        $post_id = get_the_ID();
    } else {
        return;
    }
    echo '<div id="myawesome_pageviews">'.get_post_meta( $post_id, 'myawesome_pageview', true ).'</div>';
}

add_action( 'wp_head', function(){
    if ( ! is_singular() )
        return;
    $ajax_nonce = wp_create_nonce( "my-special-string" );
?>
<script type="text/javascript">
jQuery(document).ready(function($){
	var data = {
		action: 'add_pageview',
		security: '<?php echo $ajax_nonce; ?>',
		post_id: '<?php echo get_post_ID(); ?>'
	};
	$.post( '<?php echo admin_url( "admin-ajax.php" ); ?>' , data, function(response) {
		$( "#myawesome_pageviews" ).html( response );
	});
});
</script>
<?php
} );

Tohle řešení bude fungovat i s libovolným cachovacím pluginem. Ovšem nastane jiný problém. A to s výkonem. Ten sice existoval již předtím, nicméně zůstal skryt cachovacím pluginem.

Co se nyní děje při požadavku na wp-admin/admin-ajax.php

WordPress, k tomu aby mohl fungovat, musí načíst jádro, pluginy, šablony, options z databáze a další data. To neplatí jen a pouze o necachovaném pageview, ale také o AJAX requestech, které se v podobně POST requestu určitě necachují.

Takže každé načtení stránky na daném webu produkuje nyní dva requesty. Jeden cachovaný a druhý přímo mířící na origin – tedy váš server, kde se WordPress načítá s veškerou parádou. Takový AJAX request nebude blokovat načtení stránky, uživatel se dostane k obsahu teoreticky celkem rychle a na ten počet zobrazení v hlavičce článku si holt počká. Ale server bude přetížen.

Tohle je ta část problému, jejíž řešení je uvedeno v článku odkazovaném v úvodu. Nicméně to není vše.

Nekončící zápisy do databáze

Už zmiňované necachované requesty na server jsou špatné, ale je to ještě horší. Daný AJAX request nejen, že načítá data z databáze, on také data zapisuje. To znamená, že co načtení stránky, to zápis do databáze. V malých objemech to sever nejspíš ustojí, ale v případě nějakého spiku v návštěvnosti se ukáže, kdo používá MyISAM a kdo InnoDB jako úložiště dat pro MySQL.

Zatímco stále ještě nejpoužívanější MyISAM zamyká při zápisu celé tabulky, InnoDB zamyká jen řádky. InnoDB pomůže hlavně v tom, že administrátor či editoři nebudou mít problémy s vytvářením novým příspěvků, kvůli tomu, že by tabulka wp_post_meta byla zamknutá kvůli všem těch zápisům z pageviews pluginu. Ale problém to stejně neřeší.

Když jsem nakousl MySQL, tak cítím, že je vhodné také zmínit pro nefunguje cache, kterou má MySQL zabudovanou. MySQL cachuje dotazy a v případě identického dotazu dokáže vrátit data bez toho, aniž by dotaz vykonala. Ovšem MySQL tuto cache maže vždy, když dojde ke změně v relevantních tabulkách. Takže i jednoduché čtení z databáze se nám začne prodražovat.

Nepomůže změnit cahovací plugin

Věřím, že řada provozovatelů webu na WordPressu se začne poohlížet po lepším cachovacím pluginu. Neznám podrobně všechny page level cachovací pluginy, ale dokážu si představit že mažou cache pro stránku v případě updatu relevantní post_meta. Aspoň tak tomu je u různých object cache pluginů, které znám lépe.

Uživatel se dost možná dočte o něčem, čemu se říká object cache a zkusí nějaký ten redis či memcache nasadit. Ovšem kýženého výsledku se opět nedosáhne. Jednoduše proto, že object cache pro daný post, který obsahuje nejen údaje z tabulky wp_posts, ale také z tabulky wp_post_meta, se bude s každým zápisem do databáze mazat, tedy vždy, když někdo spustí daný AJAX request – tedy navštíví danou stránku. Takže vlastně pořád. To je opět stejný problém, jako s MySQL cachí.

Opět se vracím k problému a řešení popsaném ve zmiňovaném blogpostu. Ten správně odstranil AJAX request, ovšem plugin/šablona použitá na webu není tak “elegantní”, pokud se o eleganci ještě vůbec dá hovořit, a neprovádí čtení i zápis v rámci jednoho requestu, nýbrž ve dvou. “Zapisovací” request je v době psaní tohoto článku stále ještě aktivní a vesele zapisuje do databáze, znovu a znovu.

Správné řešení?

Jediné, co můžeme provést je celý takovýto návrh smést ze stolu.

Statistiky jako pageviews patří na systémy, které jsou na nápor dat připraveny. A můžeme si vybírat. Jmenujme aspoň Google Analytics, Piwik či Jetpack a jeho modul Stats.

Pluginy na zobrazování počtu shlédnutí daného příspěvku poté budou muset využít API zmíněných nástrojů a získat tak kýžená data. Jaké pluginy to jsou a jak obecně na to je nad rámec tohoto článku, jehož cílem je především poučit o tom, proč se s page/post views pluginy většinou spálíte a proč.

PS: Původně jsem nechtěl žádný plugin jmenovat a veškerý kód jsem napsal jen ilustračně (aniž bych jej testoval), nicméně když jsem zjistil, že plugin WP-PostViews má více jak 200000 stažení a jeho kód je velmi podobný tomu, co jsem zde nastínil, nedalo mi to. Schválně se na kód pluginu podívejte.