Levysoft
  • Home
  • Portfolio
  • WordPress Plugin
  • Contattami

Dal 2004 il blog di Antonio Troise

RSS FeedTwitterFacebook
Ago 6 2008

Da iTunes al Nokia Music Store: quando stringere accordi con gli operatori mobili può garantire il successo di un portale di musica digitale

Posted by Antonio Troise
Tweet

Nokia Music Store Se, ad oggi, iTunes, secondo la classifica pubblicata ieri dall’NPD Group, consolida il proprio primato nel mercato musicale americano per tutti i primi sei mesi del 2008 (proprio lo scorso 19 giugno Apple ha annunciato la vendita di cinque miliardi di brani attraverso iTunes Store), è anche vero che nei prossimi mesi vedranno la luce nuovi avversari a sfidare il gigante di Cupertino, anche nel settore degli operatori mobili italiani.

Wind e il TrackID

Tra questi spicca sicuramente Wind che con la sua classifica Summer Collection è in testa alla top ten dei cd, un catalogo di oltre 3 milioni di dischi e il recente lancio del cellulare Sony Ericsson W580im (imode) che include il servizio TrackID, con il quale se non si ricorda il titolo della canzone, la si può registrare per pochi secondi, per ricevere sul telefono il titolo, l’interprete e l’album, per poi decidere se acquistare le canzoni individuate dal telefono.

Nokia Music Store

Ma è noto che l’antagonista di Apple è Nokia che da poco ha aperto il suo Nokia Music Store, un portale accessibile sia da computer che da cellulare, che offre gli album di tutte le major e di molte etichette indipendenti, che permette di acquistare un album a 10 euro oppure di ascoltare i brani senza limiti a fronte di un canone di 10 euro al mese.

Forse, appunto per dare contro alla Apple, Nokia ha adottato il formato Windows Media Audio, per cui le canzoni scaricate non potranno essere ascoltate sugli iPod. Infine, un’altra grande limitazione, atta a favorire la Microsoft, è che il portale di musica attualmente supporta solo Windows XP o Vista ed è visibile solamente con Internet Explorer 6 e superiori.

L’importanza di stringere accordi con gli operatori mobili

Il problema, però, è che se si vuole scaricare una canzone dal proprio cellulare, oltre al costo del brano, si dovrà pagare anche i costi di banda al proprio operatore mobile. Ecco, perché, sono proprio questi ultimi a svolgere un ruolo chiave nella lotta al predominio della musica digitale. Infatti, Nokia, sta provando a stringere accordi con i principali operatori mobili italiani per consentire ai loro utenti di usare il Nokia Music Store senza alcuna spesa extra.

Apple, invece, non ha intenzione di stringere accordi con nessun operatore mobile per il business della musica e, se con l’iPhone è possibile collegarsi direttamente ad una versione light di iTunes, è anche vero che, al momento, è possibile farlo solo se si ha a disposizione una rete Wi-Fi e non attraverso la rete mobile. La domanda ora sorge spontanea: Apple, se vuole difendere il proprio impero di musica portatile, dovrà cedere agli accordi commerciali con gli operatori mobili o, come al solito, difenderà strenuamente le proprie strategia commerciali?

Quel che è certo è che, come confermano anche le ultime statistiche dell’NPD Group, sono in netto calo le vendite dei CD musicali nei negozi tradizionali, a dimostrazione del fatto che il consumatore sta passando gradualmente dal supporto fisico alla musica digitale, e ciò non farà altro che consolidare ulteriormente la posizione di testa della Apple!

Tag:Apple, banda, cellulare, iPhone, iPod, itunes, Mobile, mp3, Musica, nokia, wi-fi, Windows, wma
CONTINUE READING >
0 comments
Lug 7 2008

Automatizzare le operazioni del cPanel da shell unix con i comandi wget, ftp e curl: download automatico del DB Mysql e monitorare la banda disponibile

Posted by Antonio Troise
Tweet

Il vantaggio di possedere un computer con Mac OS X è quello di avere sempre a disposizione, perché inclusa nativamente nel sistema operativo, una shell unix completa, per i più esperti, o Automator, per i meno esperti. Quest’ultimo strumento è una applicazione davvero potente perché consente di creare in maniera visuale, grazie ad un diagramma di flusso (workflow) e trascinando le azioni una dopo l’altra (drag & drop), programmi di automazione davvero complessi e articolati.

Ma dopo aver lavorato anni sui sistemi unix, avere sottomano una potente shell unix, è una tentazione di cui davvero non posso fare a meno. Infatti, con la semplice concatenazione di comandi (pipeline) come grep, sed e awk (altri comandi utili possono anche essere sort, uniq tail, head, cut e wc) in una sola riga, è possibile estrarre (scraping) informazioni da pagine web. Infatti, struttando il fatto che le pagine html sono, anche se in misura minora ad un più ordinato e formattato file xml, strutturate con i TAG, con pochi comandi è possibile fare del sano Web_scraping.

WGET

Il comando più potente da riga di comando per scaricare una pagina web o inviare richieste GET o POST, con o senza autenticazione è, come noto, WGET.
Per scaricare un file è possibile usare una sintassi tipo:

Ma la vera potenza di wget risiede nella possibilità di realizzare, con una sola riga di comando, un mirror ad un sito web.
Quindi per scaricare un intero sito in locale basta scrivere:

mentre, per scaricare solo una pagina con tutti i link interni:

Il problema è che sui sistemi MAC OS X, wget non è installato di default e, quindi, per chi non volesse passare per la fase di compilazione (anche se in giro esistono versioni già compilate per Tiger e Leopard) o, comunque, ha semplicemente la necessità di scaricare solo una file o una pagina web, allora è possibile usare una delle due alternative preinstallate su Mac OS X: ftp e curl.

FTP

Il comando FTP può essere usato anche per scaricare file HTTP.
La sintassi è molto semplice:

Come vedremo, in seguito, per i nostri scopi molto spesso il comando FTP è più che sufficiente per la maggior parte delle operazioni comuni.

CURL

CURL è un tool da riga di comando estremamente potente perché permette di scaricare in maniera molto flessibile ed automatizzata un qualsiasi numero di files da internet, secondo i protocolli HTTP o FTP, e di visualizzarli a schermo o di scriverli su disco.
La sintassi semplice, simile a quella dell’FTP, è:

In realtà la sintassi completa è:

Ma la vera flessibilità del comando nasce dalla possibilità di usare nella sintassi dell’URL le parentesi quadre per indicare una serie di URLs incrementali.
Per esempio una sintassi tipo:

creerà in modo automatico tutti gli URLs compresi nell’intervallo numerico specificato, e scaricherà in successione i file corrispondenti. Ai files sull’HD verrà assegnato il nome specificato dopo la flag -o, usando l’indice #1 per creare nomi univoci, incrementati allo stesso modo della sorgente.
In poche parole la singola riga di cui sopra equivarrà ad aver digitato in successione tutti i comandi:

Attenzione: il flag -O dell’ultimo esempio differisce dal flag con la o minuscola usato in precedenza, in quanto per nominare il file sul disco rigido usa lo stesso nome del file remoto.

La successione di URLs incrementali non deve essere necessariamente numerica, ma anche alfabetica, ad esempio [a-z]. Inoltre in uno stesso comando si possono combinare più indici incrementali (notate come nel nominare il file è possibile usare anche i due indici #1 e #2)

Monitorare la banda del proprio sito da riga di comando

Dati gli ultimi problemi di esaurimento della banda che hanno afflitto il mio sito, era evidente che una delle prime necessità che avevo era quello di monitorare costantemente la banda usata. Il problema è che, per farlo, dovevo ogni volta accedere al cPanel, il Pannello di Amministrazione del mio sito, dove, in un menu laterale, era possibile visualizzare la banda usata.

cPanel Bandwidth

Allora ho deciso di crearmi un semplice script che, scaricasse la pagina html del mio cPanel, andasse a selezionare, con il comando grep, la riga che conteneva la frase “Monthly Bandwidth Transfer” e attraverso due comandi awk (i file separator usati in Awk sono relativi alla mia pagina cPanel e potrebbero variare a seconda delle diverse versioni e configurazioni del pannello di controllo), estrarre la banda usata:

Come potete notare, per semplicità ho incluso, direttamente nella URL, lo username e la password per accedere al Pannello di Amministrazione. Questo è possibile solo perché il metodo di autenticazione del cPanel si basa su htpasswd ma ricordiamo che non è un metodo sicuro perché, oltre a lasciare memorizzati informazioni personali, nella barra degli indirizzi del proprio browser o nella history del terminale usato, si lasciano tracce anche nei vari proxy in cui si passa e nei log del webserver, oltre, come comunque avviene l’autenticazione classica se non passa per SSL, con un semplice sniffer.

Ci tengo a precisare che quello sopra illustrato è solo uno dei tanti modi per risolvere il problema: questo, in particolare, è il primo che mi è venuto a mente, forte delle decine di script shell realizzati negli anni. Ovviamente è possibile anche renderlo più complesso ed efficiente, parametrizzando username, password e url e, magari, notificando con una mail o con un messaggio a video (magari anche con Growl), quando la banda è prossima all’esaurimento. Il tutto ovviamente potrebbe anche essere inserito nel crontab di sistema in modo da girare ogni ora.

Per esempio, un metodo non ortodosso, sarebbe quello di visualizzare l’output non a video ma direttamente in TextEdit usando il comando open con le pipeline. Per farlo, ho riunito i tre comandi sopra elencati in un file bash di nome: monitora_banda.bash.
Quindi lanciando:

avremo questo risultato:

Output Textedit

Più in generale questo è il risultato del comando ‘open’ presente su Mac OS X.
Altri esempi, potrebbero essere:

Ma le possibilità, come vedete, sono infinite. Ma lo scopo di questo articolo era solo di illustrare alcuni metodi per automatizzare da riga di comando delle procedure. Il resto è lasciato all’inventiva di ciascuno di voi.

Download automatico del backup del DB Mysql

Il mio hosting non supporta il backup automatico del DB di Mysql perché non gestisce correttamente le schedulazioni di comandi da riga di comando. E’ per questo che ho realizzato un semplice script da inserire nel crontab, per scaricare quotidianamente il backup del proprio database.
Infatti, sempre nel cPanel, è presente una sezione “Backups” che permette di scaricare, manualmente e con un link statico, un full backup del sito, oppure un backup parziale del solo database Mysql o della sola home directory (il concetto esposto rimarrà comunque analogo per qualsiasi soluzione adottiate).
E’ evidente che, a questo punto, con un semplice comando, è possibile scaricare da terminale i backup:

Basterà quindi inserirlo (con il comando crontab -e) nel crontab (se non siete esperti potrete usare il Easy Crontab Creation Tool) in modo da fargli scaricare il backup del DB, per esempio, ogni giorno alle ore 11:30 del mattino:

Attenzione: come ogni comando da terminale, FTP (ma lo stesso vale se usate WGET o CURL) andrà ad operare nella directory corrente di lavoro, quindi se volete archiviare i file scaricati in una directory apposita, spostatevici preventivamente con il comando cd nome_directory.
Inoltre, dovete tenere presente che tutti i downloads andranno a scrivere lo stesso file e, quindi, ogni giorno ci si ritroverà con solo l’ultimo file scaricato. Se avete intenzione di tenere traccia di tutti i backup scaricati, dovrete rinominare il file, per esempio, aggiungendoci un suffisso come la data di download (realizzabile o con il comando curl o con uno script bash).

Tag:automator, awk, backup, banda, bandwidth, bash, cpanel, curl, database, download, ftp, grep, html, ksh, Mac os x, Mysql, password, sed, shell, unix, url, wget
CONTINUE READING >
5 comments
Lug 4 2008

Rapidshare: addio ai captcha per gli utenti Free! Ora è possibile scaricare fino a 200 MB alla volta senza più lunghi tempi di attesa

Posted by Antonio Troise
Tweet

Dopo avere introdotto captcha sempre più complicati da risolvere, che, oltre a contenere lettere distorte, avevano anche dei simboli come cani, gatti o auto, chi non aveva un account Premium a pagamento non era molto soddisfatto delle scelte di Rapidshare per combattere il download automatico dei file, perché rendeva il servizio davvero poco usabile. D’altra parte sembrava che, ogni azione volta a rendere difficile il lavoro di questi software in grado di leggere e interpretare i captcha, aveva come unico risultato di complicare la vita e la vista degli utenti Free che desideravano scaricare un file.

Inoltre, un altro elemento frustrante per gli utenti Free, è sempre stato il ticket time, ovvero il tempo di attesa tra un download e l’altro, che è sempre proporzionale a quanto si è scaricato fino a quel momento, e può a arrivare sino ad un massimo di 104 minuti di attesa.

Il primo passo: le Happy Hours

E’ per questo che, forse per testare un servizio a più ampio spettro, Rapidshare il 17 Aprile 2008 introdusse le Happy Hours, ovvero alcune ore nell’arco della giornata in cui anche gli utenti Free potevano scaricare liberamente godendo di una parte dei privilegi degli utenti Premium.
Se inizialmente, questa possibilità, sembrava quasi essere una sorta di pubblicità delle potenzialità di un account Premium, alla luce dei fatti odierni, è ipotizzabile che le Happy Hours siano state una fase di test intermedia per arrivare alla eliminazione completa dei captcha.

Il secondo passo: addio Captcha e lunghi tempi di attesa

Ed è infatti è quello che è successo il 2 Luglio 2008, quando con un comunicato ufficiale Rapidshare ha dato l’addio ai captcha!
D’ora in poi, quindi, anche gli utenti Free potranno caricare e scaricare file (sino a 200 MB, mentre prima il limite era di 100 MB) senza compilare alcun form ma semplicemente cliccando su un link e senza alcun eccessivo tempo di attesa tra un donwload e l’altro (infatti rimane ancora un tempo di attesa refrattario perlopiù fisso che va tra i 25 e i 45 secondi ma che non dovrebbe essere proporzionale a quanto si è scaricato sino a quel momento).

Per proteggere, però, Rapidshare da congestioni di traffico causati dai software di download automatico che, a questo punto, senza captcha avrebbero davvero la vita semplificata, Rapidshare ha posto un limite sulla velocità di download, valido ovviamente solo per gli utenti non paganti, di 500 kb/sec, e un limite pari ad 1 sul numero di download contemporanei (ovvero si potrà scaricare un solo file alla volta).

Rapidshare No Captcha
Gli account Premium

Per i Premium User, invece, ora è possibile scaricare sino a 10 GB al giorno e se non si usa tutta la banda messa a disposizione, questa si accumulerà per i giorni successivi sino ad arrivare ad un massimo di 50 GB: per esempio, se per 5 giorni non si scarica nulla, il 6° giorno si potrà scaricare fino a 50 GB in una sola giornata!

Ma non sono solo questi i vantaggi di un account Premium di Rapidshare: velocità di download illimitata (io sono arrivato sino a 2000 KB/sec), download istantaneo appena si clicca su un link rapidshare (mentre un utente free deve comunque passare per la pagina di Rapidshare e scegliere di scaricare come Free User), numero illimitato di download paralleli (mentre i free user possono scaricare solo un file alla volta) e supporto al Resume di un download e ai Download Accelerator.

La fine di Rapidshare?

Intelligentemente, credo, Rapidshare ha smesso di fare la guerra e ha giocato la carta di dare tutto a tutti, ma con delle ristrettezze, per i Free User, imposte lato server e, quindi, più difficili da scavalcare come per i captcha. Molti credono che così facendo Rapidshare soccomberà sotto il peso eccessivo dei suoi download, e che la sua fine sia davvero prossima. Sta di fatto che attualmente il sito Rapidshare.com è in posizione numero 12 tra i siti più popolari secondo la classifica di Alexa e credo che forse questa astuta mossa contribuirà a farlo restare in vetta ancora a lungo.
Staremo a vedere!

Tag:alexa, banda, captcha, download, happy hours, rapidshare, traffico, velocità
CONTINUE READING >
5 comments
Lug 2 2008

Come risparmiare banda: ridurre le email dei commenti e i backup via FTP, usare le AJAX Library API di Google con il plugin per WordPress e disattivare Google Translator che non porta traffico utile ad Adsense

Posted by Antonio Troise
Tweet

Più volte mi sono dovuto imbattere in ottimizzazioni certosine per ridurre i consumi di banda mensile sul mio sito: riducendo le dimensioni dei file javascript, attivando la compressione HTTP e, a volte, anche spostando le immagini su un altro server. Ma non ho mai dovuto affrontare incrementi di banda di oltre 10/20 GB in un solo mese.
Infatti, lo scorso Giugno, con mia grande sorpresa a soli 20 giorni dall’inizio del mese, il mio sito aveva già esaurito la banda di 40 GB messa a disposizione dal Blooweb, arrivando, a fine mese, ad oltre 50 GB di banda totale. Grazie alla gentilezza dello staff del mio hosting, mi hanno ripristinato temporaneamente il servizio in attesa che capissi da cosa fosse dipeso questo improvviso aumento di banda.

Sicuramente nell’ultimo mese avevo ricevuto un incredibile aumento di visitatori e questo aveva sicuramente influenzato le statistiche: oltre 30.000 visitatori unici in più (103.000 solo a Giugno) rispetto alla media dei mesi scorsi con un incremento di banda sproporzionato di oltre 16 GB in più (giungendo a 39.52 GB a fine mese di solo traffico HTTP).

La banda è la somma del traffico HTTP, FTP, SMTP e POP

Quello che mi aveva colto impreparato, però, era che il traffico HTTP (evidenziato da tool statistici com Awstats) non era l’unico elemento che veniva conteggiato nella soglia di banda messa a disposizione da un hosting (ed evidenziato nella homepage del mio cPanel): infatti, oltre al traffico HTTP, veniva conteggiato anche quello FTP, SMTP e POP. Normalmente, però, questi valori sono sempre trascurabili rispetto alla banda generata dal traffico delle pagine web. Questo, però, fino a questo mese, visto che il 20 Giugno, a fronte di un traffico HTTP di soli 28.76 GB, il sistema misurava una banda totale che superava i 40 GB! Ovvero, stavo consumando oltre 10 GB tra traffico FTP, SMTP e POP! Una cosa davvero incredibile rispetto alla media dei mesi precedenti.

Troppi commenti con false email generano traffico SMTP

Analizzando con calma la situazione ho scoperto che la funzione di segnalazione dei commenti (del plugin per WordPress Subscribe To Comments) inviava quotidianamente molti messaggi che non venivano mai recapitati correttamente (nell’ordine di alcune centinaia al giorno), probabilmente perché molti utenti che lasciavano commenti sul mio blog non inserivano email reali. Ciò creava un indubbio traffico SMTP anche se credo non della portata di 10 GB mensili, visto che i messaggi recapitati erano solo ASCII.
Comunque, onde evitare problemi, ho provveduto ad eliminare tutte le email che si erano registrati su un solo articolo del mio sito (oltre il 95% delle mail memorizzate), supponendo che chi scrive un commento con una email fittizia sia un visitatore di passaggio e quindi non un commentatore abituale. In tal modo non ho dovuto disattivare completamente questa funzione.

Fare spesso via FTP i backup di siti molto grandi riduce la banda mensile

Un altro problema che ho messo in luce è che, se è vero che nel conteggio del traffico totale mensile, era prevista anche la banda FTP usata, allora ogniqualvolta eseguivo un backup del mio sito, questo erodeva la quota mensile. Ora siccome dal cPanel è possibile eseguire un backup di tutta la mia home directory e non solo della directory in cui risiedono le mie pagine web, ogni volta che faccio il backup del sito, scarico ben 639 MB (a fronte di un peso effettivo del mio blog di poco più di 200 MB). Se in un mese, come è accaduto a Giugno, eseguo 4-5 backup, consumo oltre 3 GB di banda mensile.
Per risolvere questo problema ho deciso di scaricare solo il contenuto effettivo del mio sito e, laddove possibile, sempre verso fine mese, in modo da tenere sotto controllo il consumo di banda.

Il problema ricorrente delle dimensioni dei file Javascript e le AJAX Library API di Google

Se questi ultimi 2 punti sono stati volti a risparmiare quel fattore di banda invisibile e difficilmente monitorabile, ho deciso anche di intervenire, ancora una volta, su quella HTTP. Devo dire che, mano a mano che avanza lo stato di ottimizzazione del sito, affrontare il problema della banda, è un lavoro davvero certosino e occorre considerare diverse variabili prima trascurate e, non da ultimo, alcuni elementi nuovi (come l’installazione di nuovi plugin) che sono intercorsi dall’ultima analisi.

Tra questi troviamo anche un vecchio problema: i file javascript. Infatti, nonostante la precedente volta li abbia compressi più che mai, nel solo mese di Giugno, i soli file JS occupavano ben 8.96 GB di banda mensile!

Per risolvere parzialmente questo problema, ho pensato, quindi, di poter sfruttare le AJAX Library API di Google. In pratica, Google, recentemente ha messo a disposizione di tutti le maggiori librerie javascript e ajax compresse, linkabili direttamente dai loro server: jQuery, Prototype, script.aculo.us, Mootools e Dojo!

Centralizzando la distribuzione dei framework javascript e sfruttando le infrastrutture della rete di Google è possibile ottenere innumerevoli vantaggi: caching (utilizzando il medesimo URL per i file, c’è la probabilità che il browser dell’utente abbia già scaricato la libreria precedentemente), compressione Gzip/Minify, e file ospitati sui server veloci di Google e quindi riduzione del traffico generato dal proprio sito.

E’ possibile richiamare gli script all’interno delle proprie pagine utilizzando la classica sintassi:

oppure con il metodo google.load(), che di fatto è molto più potente e performante, perché permette di indicare anche la versione desiderata della libreria:

Nel caso di script.aculo.us dovremo caricare anche prototype:

Infatti, per garantire la compatibilità delle applicazioni, Google offre anche una serie di versioni diverse per ogni libreria Javascript e permette di specificare quella desiderata. Il versioning è, però, anche intelligente. Infatti, se si specifica una versione parziale della libreria (p.es 1.8), Google ci farà scaricare l’ultima release stabile di quella revision (p.es. 1.8.4), mentre se si specifica solo la versione “1” allora lui scaricherà l’ultima disponibile, ovvero, la “1.9.1”.

Plugin per WordPress per le Google AJAX Libraries API

Se non volete mettere mano al codice della funzione wp_head() di WordPress per eliminare il riferimento al file prototype residente sul server ed inserire il link a quello residente sul server di Google, esiste un comodissimo plugin: Google AJAX Libraries API Plugin. Una volta attivato non farà altro che sostituire (con un add_filter()) il riferimento a tutti i framework gestiti con la versione ospitata sui server di Google.

L’unico svantaggio è che non usa la versatile funzione google.load() (che permette di puntare dinamicamente alla ultima release stabile) bensì il classico link diretto al file javascript. Ciò vi costringerà a tenere sotto controllo la versione di Prototype usata da WordPress e aggiornare di conseguenza il plugin (che ancora non è inserito nella Repository Ufficiale dei Plugin per WordPress) oppure modificarlo a mano.
Inoltre, non punta neanche alla versione compressa del file javascript, il che comunque non rallenta minimamente il caricamento della pagina.

Infatti, come è possibile vedere, eseguendo i test con i Pingdom Tools, usando la versione non compressa di Google abbiamo un peso di 123,2 KB (che comunque non influenza la banda del proprio sito) e un tempo di caricamento di 0.5 secondi

Google AJAX Libraries API

mentre usando la versione ospitata sul mio server, a fronte di un peso complessivo di 46,6 KB abbiamo un tempo di caricamento di oltre 1,2 secondi!

Prototype self hostes

Disabilitazione di alcuni plugin

Inoltre, tra i file più letti ho trovato tutta una serie di plugin per i commenti:

  • quoter.php (plugin: Quoter)
  • ajax-comment-preview-js.php (plugin: AJAX Comment Preview)
  • lmbbox-comment-quicktags.php (plugin: LMB^Box Comment Quicktags)

Ho deciso, quindi, in via del tutto sperimentale, di disattivarli (visto che comunque non sono essenziali per l’inserimento di un commento), per capire che influenza avevano sulla banda totale e sulla velocità del sito (monitorabile facilmente con i Pingdom Tools).

Disattivare Google Translator che non porta traffico utile ad Adsense

Al termine di queste mie analisi ho scoperto che un plugin che avevo installato stava producendo un aumento di banda non indifferente in maniera totalmente indiretta e difficilmente monitorabile: sto parlando del plugin per WordPress Global Translator, un tool per la traduzione automatica delle pagine nelle principali lingue sfruttando le API di Google Translator.

Infatti, da quando a fine Maggio lo avevo installato, il traffico proveniente dagli Stati Uniti è quasi raddoppiato, passando da 15.08 GB a ben 28.06 GB! Considerando che il mio sito è scritto in italiano, è facilmente intuibile che quel plugin aveva avuto il pregio di allargare la mia fetta di visitatori ad un pubblico che solitamente non mi leggeva.

Ma allora mi sono chiesto: il traffico in più proveniente dagli Stati Uniti era traffico utile e valido e poteva essere vantaggioso per il mio sito oppure era solo uno spreco inutile di banda? Il fatto che la traduzione automatica di Google non potrà mai rispecchiare fedelmente il testo scritto nella propria madre lingua, può portare gente realmente interessata a quello che dico o solo a visitatori passivi che incappano per errore nelle mie pagine? Devo dire che, per certe keyword specifiche, il mio sito risultava primo anche in lingua inglese, e ciò conferma il fatto che Google ha svolto un ottimo lavoro di indicizzazione delle mie pagine. Ma la mia esperienza con le pagine tradotte in automatico non è delle migliori, perché spesso non si riesce a cogliere il senso più profondo delle frasi ma solo una descrizione sommaria. E purtroppo non è questo quello che desidero dare ad un lettore!

Inoltre, per i più veniali, un altro indubbio svantaggio è che, a fronte di un raddoppio di banda usata e di pagine viste, ciò non portava ad alcun incremento degli introiti di Google Adsense che si attestavano sempre sugli stessi valori dei mesi precedenti. Questo capita perché, come ho potuto constatare, anche se la pagina risulta tradotta in inglese (o in qualsiasi altra lingua), i banner Adsense risultano sempre visibili in italiano, vanificando quindi il loro scopo perché nessun inglese cliccherà mai su una pubblicità scritta in un’altra lingua.

Quindi, a ragione, ho provvedduto a disabilitare la traduzione automatica del sito, sperando che, quando Google avrà tolto dal suo indice le pagine scritte in un altra lingua al di fuori dell’italiano, la quota mensili di banda consumata si possa attestare su valori ragionevoli.

Il problema della banda dei server italiani

Il problema dei server che risiedono in Italia è che la banda viene ceduta quasi a peso d’oro: un upgrade di soli 5 GB di traffico mensile mi viene a costare bene 42.00 € in più; considerando che, in teoria, avrei bisogno di almeno altri 20 GB di banda, il costo di gestione del mio sito lieviterebbe di oltre 120.00 €!
Capite bene perché, ogni 2-3 mesi, sono costretto ad ottimizzare al massimo le prestazioni del mio sito riducendo inutili sprechi! Spero che questa mia testimonianza possa essere utile a qualcuno che, come me, combatte quotidianamente con il traffico mensile.
Se poi avete qualche altra idea o suggerimento sono sempre disponibile ad ascoltarvi.

Tag:adsense, Ajax, api, backup, banda, bandwidth, blooweb, compressione, ftp, Google, google translator, Javascript, Php, Plugin, prototype, Wordpress
CONTINUE READING >
17 comments
Apr 8 2008

Nuove modalità per risparmiare banda con WordPress 2.5: addio alla compressione Gzip direttamente da WordPress e comprimere del 60% il file prototype.js v1.6.0

Posted by Antonio Troise
Tweet

Tempo fa scrissi un paio di guide su come risparmiare banda sul proprio sito comprimendo tutte le pagine con Gzip e riducendo le dimensioni del file javascript prototype. Le operazioni che, però, avevo descritto in quei tutorial non sono più del tutto valide in WordPress 2.5. Ecco, in particolare, cosa è cambiato e come agire di conseguenze.

Addio alla compressione Gzip da WordPress

Su WordPress 2.3, per attivare la compressione delle pagine web, era sufficiente andare nel Pannello di Controllo di WordPress e, nella sezione Opzioni/Lettura (Options/Reading per la versione in lingua inglese), spuntare la voce “WordPress deve comprimere gli articoli (gzip) se il browser lo richiede“. Questo permetteva, in tutta semplicità, di comprimere in formato Gzip (attivando la compressione HTTP) prima di inviarlo al browser, in modo da alleggerire la dimensione della pagina (risparmiando quasi il 70% di dimensioni in una pagina di puro testo) e diminuirne il tempo trasferimento facendo lavorare un po’ di più il computer dei vostri lettori.

Ora, con WordPress 2.5, tutto questo non è più possibile. Sono andato a vedere in tutti i menu e sottomenu dell’Area di Amministrazione di WordPress, ma della voce per la compressione del contenuto delle pagine web tramite gzip, non ve ne era più traccia. Ho trovato la conferma anche qui: pare che in In WordPress 2.5 questa opzione non sia più presente!

Pare che la spiegazione, data da Ryan Boren, sia quella che era nata nel Team di Sviluppo di WordPress, l’esigenza di voler spostare la decisione della compressione delle pagine web al server stesso; infatti, oramai, qualsiasi webserver è in grado di gestire la compressione del contenuto, e la maggioranza dei piani di hosting prevede questa funzione, sia abilitata per default, sia opzionale (come nel caso di cPanel). Evidentemente questo dovrebbe avere ovvi vantaggi prestazionali, anche se non ho ben chiaro quanto possa essere.

Riattivare la compressione gzip da php

Se, però, il vostro webserver è tra i pochi che non supporta la compressione gzip (sul mio per esempio no ho trovato la funzione), potete verificare, come suggerisce Elliott C. Back, se almeno il vostro interprete php offre le funzioni di controllo dell’output, e attivarle tramite .htaccess con queste due righe di comando:

Altrimenti, dovrete modificare il vostro file index.php nel seguente modo:

Attenzione, però: se attivate la compressione via php, dovrete modificare il file tiny_mce_config.php (in wp-includes) come suggerito da Andrew Ozz nella lista wp-testers, e disabilitare la compressione in questo file, altrimenti l’editor visuale verrà compresso due volte!

Riattivare la compressione gzip con un plugin per WordPress

Se, però, come immagino, non volete mettere mano ai file php e non potete comunque attivare la compressione sul vostro webserver, potete allora installare il plugin realizzato da Sergej Müller. Si chiama Compress for WordPress 2.5, ed è un plugin che agisce pressoché allo stesso modo descritto nel capitolo precedente senza, però, richiedere alcuna modifica manuale. Purtroppo è in tedesco ma è abbastanza chiaro quello che fa: è sufficiente attivarlo e lui comprimerà e vostre pagine web da php.

Wordpress Content-Encoding Gzip
Come verificare che il plugin Compress for WordPress 2.5 svolga il suo lavoro

Di solito mi fido delle descrizioni che gli autori danno dei propri plugin, ma siccome, in questo caso, ci troviamo di fronte ad un plugin che non rilascia alcun feedback su quello che fa e risulta essere del tutto trasparente a tutti tranne che al browser, ho deciso di verificare se Compress for WordPress 2.5 funzionava correttamente, anche perché non volevo segnalare qualcosa di cui non ero neanche io certo sul suo funzionamento!

Per farlo ho installato una comoda estensione per Firefox, Live HTTP Headers 0.13.1, che permette di catturare e analizzare l’headers delle pagine HTTP che il browser visualizza. Infatti, l‘informazione che ci dice se la pagina è stata compressa, è contenuta in una variabile: Content-Encoding.

Se, quindi, attivo il plugin Compress for WordPress 2.5, e ricarico l’homepage del mio sito, vedrò che la maschera di Live HTTP Headers (raggiungibile da Firefox dal menu Strumenti/Live HTTP Headers) mostra il parametro suddetto settato come:

Content-Encoding: gzip

Se, invece, disabilito il plugin, il parametro di Content-Encoding non viene neanche passato e, l’unica cosa che è possibile trovare (e che si trova anche nel caso) precedente, è il parametro “Accept-Encoding: gzip,deflate” che sta ad indicare che il nostro browser è in grado di gestire i contenuti compressi.

Quindi, in soli due minuti, abbiamo verificato che il plugin svolgesse correttamente il suo lavoro!

Compressione del 150% del file prototype.js 1.6.0

Per quanto riguarda, invece, la compressione del voluminoso framework Prototype (un file JavaScript che ha loscopo di facilitare lo sviluppo di applicazioni web dinamiche di tipo Ajax) in uso su WordPress, non è cambiato molto se non la versione da utilizzare. Infatti, rispetto a WordPress 2.3, che usava la versione 1.5.1.1, la nuova release di WordPress 2.5 usa la versione 1.6.0.
Potete controllarlo voi stessi: basterà leggere la prima riga del file wp-includes/js/prototype.js

Quindi, se non volete comprimere voi stessi il file javascript (che di per sé è grande 121 KB), con un dei tanti tool online che ho descritto in precedenza, dovete fare riferimento all’ottimo lavoro svolto da John-David Dalton che ha compresso per noi tutte le versioni di Prototype.

Quello che dovrete fare voi, quindi, è scaricare il file protopack_v2.19b.zip dal sito Prototype: Core (nel vecchio tutorial era il protopacked_v2.17.zip), scompattarlo e vi troverete una ricca collezione di framework Prototype/Scriptaculous.
In particolare questo package contiene le release 1.4, 1.5, 1.5.1.2 e 1.6.0.2 di Prototype e la release 1.7.1_beta3, 1.8.1 di Scriptaculous. Se sul vostro sito usate anche Scriptaculous allora potete far riferimento direttamente al file Protoculous (esistono le versioni 1.5.1.2 + 1.7.1_beta3 e 1.6.0.2 + 1.8.1), che altro non è che la combinazione in un unico file di Prototype and Scriptaculous.

In generale, però, nel nostro caso sarà sufficiente scegliere la versione compressa del file prototype.js. Quindi, una volta scaricato e scompattato il pacchetto zip protopack_v2.19b.zip, aprite la cartella “files” e vi troverete 3 cartelle: qui aprite la cartella “compressed“, quindi la cartella “prototype” e, infine, entrate nella directory “v1.6.0.2“ (non è esattamente la stessa versione rilasciata con WordPress 2.5, ma i cambiamenti sono davvero minimi e comunque compatibili con una release inferiore).
Qui, vi troverete, dinanzi a due differenti versioni compresse dello stesso file Prototype.js:

prototype-1.6.0.2-packer.js : compresso con Dean Edward’s Packer 3 \w con le opzioni “Base62 encode” e “Shrink variables”
prototype-1.6.0.2-shrinkvars.js : compresso con Dean Edward’s Packer 3 \w con la sola opzione “Shrink variables”.

La differenza, sostanzialmente, sta nelle dimensioni: il prototype-1.6.0.2-packer.js è grande 48 KB (la versione 1.5.1.1 compresso, che si usava con WordPress 2.3, invece, era grande solo 40 KB) mentre prototype-1.6.0.2-shrinkvars.js arriva fino a 76 KB.
Io, per il mio sito, ho usato prototype-1.6.0.2-packer.js (risparmiando oltre il 60% di spazio) che ho, ovviamente, rinominato in prototype.js e, quindi, salvato nel percorso “wp-includes/js” sostituendo il precedente file (magari fatene un backup per sicurezza).

Tag:Ajax, banda, bandwidth, browser, compressione, cpanel, gzip, Javascript, Php, prototype, Web 2.0, Wordpress, wordpress 2.5
CONTINUE READING >
12 comments
Giu 6 2007

Calcolo della banda per lo streaming video e StreamCalculator

Posted by Antonio Troise
Tweet

Straming Video Quando si deve mettere online un filmato residente sul proprio server in modalità streaming video, ovvero con riproduzione in tempo (quasi) reale senza avere la necessità di scaricarli per intero sul proprio PC, è necessario, per avere una stima dei costi e dell’impatto sulla rete, effettuare una analisi sulla quantità di banda occupata dallo streaming video e sullo spazio di storage da dedicare sul server.

Per calcolare le dimensioni di un file video sul server, occorre tenere presente che in generale le dimensioni sono ricavate dal prodotto della lunghezza in secondi del filmato per il bitrate in kbit/s.

storage size = length (in seconds) · bitrate (in kbit/s)

Per un file di un’ora e con un bitrate classico di 300 kbit/s (che corrispondono ad un filmato delle dimensioni di 320×240 pixels) avremo un’occupazione su disco di :

3.600 s · 300 kbit/s = 1,080 Gb

Se questo filmato sarà visto da 1.000 utenti, nel caso di trasmissione Unicast (concettualmente corrisponde ad una connessione punto-punto o peer-to-peer), basterà semplicemente moltiplicare il valore di bitrate per il numero di utenti, ovvero per 1.000: in tal caso avremo una banda dedicata allo streaming video pari a 300 Mb/s.
Nel caso, invece, che la trasmissione usi il protocollo Multicast (un singolo punto che trasmette un solo flusso di dati verso più punti riceventi), la banda sarà esattamente pari al bitrate del video, ovvero 300 Kbit/s.
Infatti, il Multicast, ottimizza l’uso della rete, rispetto ai metodi unicast (molti flussi di dati, uno per ciascun punto che vuole riceverlo) e broadcast (un singolo flusso di dati per tutti i riceventi, anche se non vogliono riceverlo).

Questo è il metodo pià semplice per calcolare la banda da dedicare per lo streaming video. Se, però, si vuole effettuare una stima che prenda in considerazione più parametri, come il tipo di flusso video (Windows Media, Real Media, Quicktime, MPEG-4, Flash), lo streaming rate e quante trasmissioni LIVE e VOD simultanee sono permesse, vi consiglio l’uso di una calcolatrice online di banda per lo streaming video: StreamCalculator

Attribution Image CC: ‘larskflem presents 3G IV‘

Tag:banda, multicast, p2p, streaming, unicast, Video
CONTINUE READING >
3 comments
SeguiPrezzi - Risparmia con Amazon.it

Categorie

Commenti Recenti

  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Fioredicollina on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Antonio Troise on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Emanuele on UltraEdit: per i programmatori esigenti il miglior editor di testo per Windows, Mac OS e Linux
  • Luca on iDatabase: la valida alternativa di Bento per macOS e iOS per i database personali

Meta

  • Accedi
  • Entries RSS
  • Comments RSS
  • WordPress.org

Friends Link

  • GamerTagMatch
  • SeguiPrezzi.it – Risparmia con Amazon.it
  • Trendy Nail

Seguimi su:

  • facebook
  • twitter
  • rss
Creative Commons License
Levysoft by Antonio Troise is licensed under a Creative Commons Attribuzione-Non commerciale 2.5 Italia License.
© Copyright 2004 - 2014 - Levysoft by Antonio Troise