Categorie
featured tutorial wordpress

CloudFlare: una CDN facile (e gratis)

Argomento un po’ complesso per cui preferisco partire con la definizione di CDN:

Le Content Delivery Network (CDN, Rete per la consegna di contenuti) … sono un sistema di computer collegati in rete attraverso Internet che collaborano in maniera trasparente, sotto forma di sistema distribuito, per distribuire contenuti agli utenti finali.

L’obiettivo di una CDN è di instradare una richiesta di contenuto sul nodo che viene individuato come ottimale. Se ottimizzate per le prestazioni, il nodo ottimale è quello che può soddisfare la richiesta nel minor tempo possibile: si può determinare per esempio scegliendo quello geograficamente o topograficamente (nel contesto di rete, minor numero di hops o minor ping) più vicino alla locazione del richiedente, oppure quello con un minor carico di lavoro (in inglese, load average).

Detto in modo più concreto si tratta di un sistema per ottimizzare e risparmiare carico server facendo in modo che alcuni contenuti (es. le immagini e/o i file statici come js e css) vengano erogati da server differenti ottimizzando la distribuzione a livello geografico in modo che sia il server più vicino a noi ad occuparsi del trasferimento.

Mi sono chiesto più volte in quale modo la nostra infrastuttura potesse beneficiare di questo tecnologia ma guardando le specifiche di Akamai e/o Amazon (che sono forse tra le più importanti realtà in questo settore) mi sono reso conto che i prezzi per la gestione di piccoli siti sono abbastanza proibitivi.

Poi, come sempre succede in queste cose, “la figlia del contadino” mi ha parlato di CloudFlare e del suo piano gratuito.

Ho deciso quindi di provare l’integrazione su questa pagine limitando però l’uso alle immagini e ai file javascript e css.
Questo, in breve, quello che ho fatto.

  1. Comprato un nuovo dominio “mavidacdn.in” su whois.com (in offerti in questi giorni a 3.88 dollari).
  2. Ho girato i name server sui server di Cloudflare
  3. Impostato un nuovo sottominio maurizio.mavida.com in modo che punti sul mio ip
  4. Configurato Apache per indirizzare correttamente. (sia maurizio.mavida.com che static puntano adesso allo stesso sito)
  5. Scritto un microplugin per fare in modo che l’indirizzo delle immagini pubblicare su queste pagine punti sul sottodominio CDN.
  6. Modificato nella pagina nelle impostazioni dei media il “Percorso URL completa ai file” con il sottodominio configurato su CloudFlare (http://maurizio.mavida.com/wp-content/uploads)

In questo modo CloudFlare oltre a fare da CDN svolge anche un lavoro come Reverse Proxy facendo cache dei contenuti. Quando viene chiesta un’immagine, o un file javascript/css CloudFlare verifica se è già nella sua cache e solo nel caso non lo sia la chiede al mio server. I benefici nel mio caso sono molto limitati in quanto il traffico generato è relativamente piccolo ma in situazioni più complesse una soluzione come questa potrebbe ridurre notevolemente il traffico.

Questo è il risparmio di banda (e di richieste) ottenuto in 5 giorni di utilizzo:

Adesso qualche dettaglio tecnico:
Qui sotto potete vedere il modo in cui vado ad effettuare la sostituzione dei link alle immagini che viene usata su filtri: ‘the_content’, ‘post_thumbnail_html’ e ‘widget_text’.


function CloudFlareImageReplace ( $content ) {

$pattern="/(" .$this->blog_url . ")(\/wp-content\/)(.*)(png|gif|jpg)/";
$replacement = $this->cf_cdnurl. "$2$3$4";

return preg_replace($pattern, $replacement,$content );

}

Mentre questa quella per js e css che viene attiva dal filtro su “script_loader_src”.

function CloudFlareScriptReplace ( $src ) {

$pattern="/(" . $this->blog_url . ")(\/wp-content\/)(.*)(js|css)/";
$replacement = $this->CloudFlareUrl . "$2$3$4";

// remove Query Strings From Static Resources
$src_parts = explode('?', $src);
return preg_replace($pattern, $replacement, $src_parts[0] );

}

Su GitHub potete trovare il sorgente versione completa (ancora in versione beta) ma se volte installarlo potete usare quella che ho pubblicato sul codex: http://wordpress.org/extend/plugins/cloudflare-url-replacement/.

Anche in quato caso sono graditi consigli e suggerimenti.


image credits: Derek Heisler

Categorie
featured wordpress

Estendere il server XML-RPC di WordPress

Leggere, scrivere e/o modificare i contenuti su WordPress non sempre può essere fatto da un’interfaccia di amministrazione (sia questa web, mobile o app). Ci possono essere esigenze in cui è necessario automatizzare alcuni processi appoggiandosi a strumenti esterni.

WordPress ci viene incontro con “una cosa” nota come XML-RPC.

 

In pratica si tratta di un componente che ci permette di dialogare secondo un protocollo standard attraverso internet. In questo modo un sito e/o applicazione esterna potrebbe pilotare la nostra installazione facendogli fare qualsiasi cosa.

In realtà “qualsiasi cosa” non è ancora prevista ma dalla nuova versione 3.4 ne saranno aggiunte parecchie. Ricordatevi solo di abilitarlo che di default è disattivato.

Il titolo di questo articolo però è “Estendere il server XML-RPC” non “Usare il server XML-RPC” quindi iniziamo a vedere cosa ci dice il codex: XML-RPC Extending

Like the rest of WordPress, the XML-RPC API contains numerous hooks to customize or extend its behavior.

Nel caso volessimo estendere il servizio XML-RPC attraverso un plugin in grado di restituire gli ultimi post non dovremo quindi fare altro che aggiugnere una roba come questa:

// aggiungo il fitro
add_filter( 'xmlrpc_methods', 'mycustom_methods');

// dichiaro i nuovi metodi
function mycustom_methods( $methods ) {
    $methods['getlastposts'] = 'get_LastPosts';
    return $methods;   
}

/*
 * restisuisco gli ultimi n. post in formato serializzato
 */
function get_LastPosts( $params ) {

  $args =  $params[0]
  $defaults = array(
	'numberposts' => 5, 
	'post_type' => 'post', 	
        'post_status'     => 'publish' 		
	);

  $args = wp_parse_args( $args, $defaults );			
  $posts = get_posts( $args );

  // restituisco l'oggetto serializzato
  return serialize($posts); 
}

Questo invece un esempio di come poter usare il vostro “nuovo” metodo usando il client offerto dalla libreria Zend

 $client = new Zend_XmlRpc_Client('http://tuosito.com/xmlrpc.php');
 $response = $client->call('getlastposts');
 $posts = deserialize($response)

 //con passaggio di parametri
 $client = new Zend_XmlRpc_Client('http://tuosito.com/xmlrpc.php');

 $args = array(
	'numberposts' => 3, 
	'post_type' => 'page'
	);

 $response = $client->call('getlastposts' , array( $args));
 $posts = deserialize($response)

Le cose nella pratica non sono così semplici e potrebbe servire un sistema di autenticazione.
Poi dato che spesso parlo di performance male non farebbe un piccolo sistema di cache.

Ecco quindi una nuova versione di “get_LastPosts” che accetta come parametri $blog_id, $username, $password e poi array con gli argomenti necessari a getposts.

function get_LastPosts( $params ) {

  $blog_id  =  $params[0]
  $username =  $params[1]
  $password =  $params[2]

  $args     =  $params[3]

  $defaults = array(
	'numberposts' => 5, 
	'post_type' => 'post', 	
        'post_status'     => 'publish' 		
	);

  $args = wp_parse_args( $args, $defaults );			
  extract( $args, EXTR_SKIP );

  if ( !$user = $this->login($username, $password) ) {
     // user o password non validi 
     return false;

  } else {

  // creo una chiave univoca per la cache
  $cache_key = "_xmlrpc_" . $username. md5( $numberposts . $post_type);

  $posts = get_transient( $cache_key );

  if (false === $posts) {
     $posts = get_posts( $args );
     set_transient( $cache_key , $posts, 60*60*4 );
  }

  // restituisco l'oggetto serializzato, compresso, ed in base64
  // per ripristinarlo: unserialize(gzuncompress(base64_decode($posts))); 
  return base64_encode(gzcompress(serialize($posts))); 
 }

}

Bene, adesso potete fare un po’ di prove e se nel fare copia e incolla ho sbagliato qualche cosa ditemlo che lo correggo.

Categorie
featured sviluppo tutorial wordpress

WordPress e qualità: sistemi di cache manuali

Per parlare di qualità, tra le tante cose, si devono definire requisiti ed obiettivi e poi trovare degli indicatori per poterli misurare.
Io sto cercando di intrudurre una serie di linee quida nel mio modo di sviluppare ad una di queste si riferisce alla velocità ed al numero di query con cui vengono generate le pagine.

 

Gli indicatori che mi danno la misura e mi permettono di capire se sto rispettando i miei requisiti sono di tre tipi:

  1. Lato browser: YSlow, Page Speed ma anche il pannello “Net ” di Firebug. Con questi verifico i tempi di caricamento dei singoli componenti della pagina ed eventuali colli di bottiglia nel caricamento di js.
  2. Lato server: XHProf . Si tratta di un profiler gerarchico per verificare i tempi di esecuzione di ogni singola funzione.
  3. Lato WordPress: Debug Query e Debug Object. Tramite questi plugin ho sotto controllo il numero di query ed un dettaglio dei singoli oggetti interni a WordPress.

E’ ovvio che uno dei primi livelli di ottimizzazione sia l’intruduzione dei sistemi di cache.
Un uso appropriato può farci risparmiare diverse query e parecchi ciclo di CPU ma dato che in molti hanno già parlato dei plugin che possono aiutarci nella gestione “semiautomatica” della cache vado oltre e vi segnalo solo un articolo fatto da qualcuno che si è anche preoccupato di andare un po’ più a fondo preparando qualche test.

Categorie
featured google analytics

Usare trackPageview asicrono su due account

Uno sei suggerimenti che mi sono portato a casa dal corso di Google Analytics Avanzato è relativo alla gestione del tracciamento delle pagine su account multipli.

Lo scenario in cui può servire una cosa del genere è quando risulta necessario rendere disponibile ad un account esterno i dati provenienti di un sottoinsieme di pagine senza gonfiare le statistiche dell’account principale con delle “pagine virtuali” (vedi _trackPageview)

Anche se sulla documentazione ufficiale c’è scritto tutto preferisco appuntarmelo su queste pagine…

Questo è il codice da usare per tracciare la stessa pagina su due account diversi:


_gaq.push(
['_setAccount', 'UA-XXXXX-1'],
['_trackPageview'],
['b._setAccount', 'UA-XXXXX-2'],
['b._trackPageview']
);

Se poi siamo in una situazione in cui su questi account vengono tracciati più domini di primo livello ([‘_setDomainName’, ‘none’]) e magari ci sono di mezzo anche variabili custom lo script diventa una roba del genere:

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-25']);
_gaq.push(['_setDomainName', 'none']);
_gaq.push(['_setAllowLinker', true]);
_gaq.push(['_setAllowHash', false]);
_gaq.push(['_setCustomVar',1,'customers', 'CustomerName',3]);
_gaq.push(['_trackPageview']);

/* inzio tracciamento su account cliente */
_gaq.push(['ca._setAccount', 'UA-XXXXX-34']);
_gaq.push(['ca._setDomainName', 'none']);
_gaq.push(['ca._setAllowLinker', true]);
_gaq.push(['ca._setAllowHash', false]);
_gaq.push(['ca._trackPageview']);

(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();

In questo modo ottengo delle statistiche pulite sull’account principale e dove serve traccio la visite sulle pagine anche sul quello esterno.
Morale della storia: ogni account ha le sue statistiche e tutti vivono felici e contenti…