Come utilizzare speedtest su un server Linux per controllare, memorizzare e riportare graficamente le velocità di internet

A seguito di una serie di problemi di scarsa connettività a banda larga che stavo riscontrando, ho deciso che volevo monitorare regolarmente la velocità in Mbps che ricevevo dal mio fornitore. Stavo vedendo cifre particolarmente basse quando cercavo di scaricare file la sera, con velocità molto più elevate raggiunte molto presto al mattino.

Ho un server Linux Debian che si trova in un angolo, che è la mia macchina di test e sviluppo per i siti web ospitati su ISPConfig, oltre ad un po’ di codice Let’s Encrypt con cui mi piace sperimentare, quindi ho cercato un software che consentisse il test della larghezza di banda, eseguibile da una riga di comando Linux, che potesse costituire la base di un sistema di script shell automatizzato per produrre i dati grezzi di cui avevo bisogno. Volevo memorizzare i dati in un database SQL per semplificare le query (così avrei potuto facilmente raccogliere più dati ed estrarre solo un sottoinsieme più piccolo per i periodi di tempo di mio interesse) e avere un’interfaccia web che potesse produrre un semplice grafico per visualizzare i dati e aiutare a evidenziare i problemi di connettività.

Il primo risultato della mia ricerca è stato il molto utile articolo di Antonio Valencia su: https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/

Dopo aver seguito le istruzioni per installare speedtest, un rapido test ha mostrato che potevo usarlo per eseguire test contro un ampio set di server internet e anche produrre output in formato CSV, che è abbastanza adatto per essere importato direttamente in una tabella SQL con il minimo sforzo nello sviluppo software.

Per la quantità relativamente piccola di dati che sarebbero stati generati, ho deciso di utilizzare SQLite come archivio back-end e una rapida ricerca delle librerie di grafico basate su javascript open-source disponibili mi ha portato a chart.js, che ha un design semplice e pulito con un’interfaccia dati semplice ma molte possibilità di modificare opzioni avanzate se necessario. Convertire i dati SQL per estrarre solo il sottoinsieme di dati che volevo graficare con output tramite JSON tramite un po’ di codice PHP semplice era la strada da seguire.

Quindi, in generale, avevo bisogno di progettare un sistema che apparisse così:

Un server Linux che esegue speedtest come cronjob - magari 1 all’ora - con l’output di speedtest memorizzato in un database SQLite - tutto controllato da un file di script shell bash. Un’interfaccia web, che è una miscela di HTML, CSS, javascript e PHP per estrarre dati da SQLite e produrre un grafico a barre che mostra le cifre Mbps raggiunte nelle 24 ore precedenti (o in qualsiasi altro periodo che potrei decidere).

Un po’ di esperimenti con l’esecuzione di speedtest una dozzina di volte in modo interattivo mi ha mostrato che c’erano alcuni server disponibili che sembravano fornire risultati in linea con il tipo di velocità che stavo riscontrando. Ho considerato fosse una buona idea testare contro più di un server per avere una migliore comprensione di come le mie cifre Mbps fossero influenzate dalla posizione del server target e dall’ora del giorno in un fuso orario diverso.

Se vuoi seguire e impostare un sistema simile per te stesso, dovrai selezionare uno o più server tra i centinaia disponibili per speedtest che si adattano alla tua posizione.

1 Requisiti

• un server linux - sto usando Debian 9.1 - stretch
• accesso tty al server con login root - uso PuTTY da un laptop Windows
• ISPConfig installato e un sito web configurato con un account FTP - sto usando 3.1.6 con apache impostato come server web (potresti gestire anche solo con un server web, con alcune piccole modifiche alle istruzioni seguenti)
• PHP - sto usando 7.0 ma questo dovrebbe funzionare anche con la maggior parte delle versioni precedenti
• client FTP - uso Filezilla - e PureFTPd in esecuzione sul server
• nano - o il tuo editor visivo preferito

Presumo qui che tu sia a tuo agio con l’accesso a un server Linux, come muoverti tra le directory, la disposizione di dove il tuo server web si aspetta che i file siano e come trasferire file tramite FTP in quelle directory.

Ecco i passaggi dettagliati per consentirti di impostare tutto questo.

2 Installa speedtest

Accedi al tuo server linux come root ed esegui il comando:

# pip install speedtest-cli

Vedi https://www.howtoforge.com/tutorial/check-internet-speed-with-speedtest-cli-on-ubuntu/ e https://pypi.python.org/pypi/speedtest-cli per ulteriori informazioni se hai problemi.

Nota: speedtest e speedtest-cli sono identici nella mia installazione, quindi farò riferimento solo a speedtest nelle seguenti parti.

3 Installa SQLite3

# apt-get install sqlite3

Usa l’equivalente per la tua distribuzione se apt-get non è per te.

4 Crea bandwidth.sh

Inserisci il seguente codice di script bash in un file e salvalo come /usr/local/etc/bandwidth.sh - lo modificheremo un po’ più tardi per renderlo specifico per te.

#!/bin/bash
# esegui speedtests contro 3 server e salva tutti i risultati di output in un file CSV per l'importazione nel db sqlite
#
# eseguito da cronjob una volta all'ora
#
#
function getCSVString () {
    # se speedtest ha fallito (ad esempio, non è riuscito ad accedere a un server) dobbiamo creare un'entrata zero fittizia per questo intervallo di tempo
    
    # ottieni una stringa timestamp nello stesso formato che genera speedtest - e abbiamo bisogno dell'ora UTC
    local RIGHTNOW=$(date --utc +%Y-%m-%dT%H:%M:%SZ)
    
    # contro quale server stiamo testando?
    if [ $1 = "5443" ] 
    then
        echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0"
    fi
    if [ $1 = "1234" ] 
    then
        echo "1234,Uno,Milton Keynes,$RIGHTNOW,168.27,0.0,0.0,0.0"
    fi
    if [ $1 = "1783" ] 
    then
        echo "1783,Comcast,\"San Francisco, CA\",$RIGHTNOW,8420.0,0.0,0.0,0.0"
    fi
    
# caso di test/debug solo
    if [ $1 = "199999999" ]
    then
        echo "99999,Test,Test,$RIGHTNOW,99.99,0.0,0.0,0.0"
    fi
}

function runTest () {
    # esegui speedtest contro il server nominato con output csv salvato in un file tmp
    /usr/local/bin/speedtest --csv --server $1 > /usr/local/etc/speedtest.tmp
    if [ $? -gt 0 ] 
    then
        # speedtest ha fallito, quindi crea un'entrata zero al posto di qualsiasi messaggio di errore
        getCSVString $1 > /usr/local/etc/speedtest.tmp
    fi

    # salva l'output pronto per il prossimo test del server
    cat /usr/local/etc/speedtest.tmp >> /usr/local/etc/speedtest.csv
}

# principale
#######
# esegui speedtest contro 3 server e salva tutti i risultati di output in un file csv
cd /usr/local/etc

# cancella il file csv - deve essere vuoto all'inizio dell'esecuzione
rm -f /usr/local/etc/speedtest.csv

############################################
# caso di test/debug - costringe speedtest a fallire
############################################
# runTest "199999999"
# sleep 5
####### commenta dopo il test ##########
############################################

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

# ora importa i dati csv nel db sqlite
sqlite3 -batch /usr/local/etc/bandwidth.db <<"EOF"
.separator ","
.import /usr/local/etc/speedtest.csv bandwidth
EOF

# aggiungi l'attuale run csv al backup
cat /usr/local/etc/speedtest.csv >> /usr/local/etc/speedtest.bak

Mi scuso per il mio approccio “cintura e bretelle” di utilizzare percorsi completi per i file ovunque anche quando non necessario. È solo il modo in cui mi piace farlo. Sentiti libero di migliorarlo se ti senti a tuo agio con la modifica degli script bash.

Imposta le proprietà del file per rendere questo script eseguibile:

# chmod 0700 bandwidth.sh

5 Crea un database SQLite

Crea il database bandwidth.db SQLite in /usr/local/etc:

#sqlite3 bandwidth.db

e poi, al prompt sqlite>, crea una nuova tabella con il seguente comando (non dimenticare il punto e virgola finale):

sqlite> CREATE TABLE IF NOT EXISTS "bandwidth" ("serverid" INTEGER NOT NULL , "sponsor" VARCHAR NOT NULL , "servername" VARCHAR NOT NULL , "times" DATETIME PRIMARY KEY NOT NULL UNIQUE , "distance" FLOAT NOT NULL , "ping" FLOAT NOT NULL , "download" FLOAT NOT NULL , "upload" FLOAT NOT NULL );

sqlite> .quit

Questo crea una tabella chiamata bandwidth con campi che mappano direttamente sul formato di output CSV di speedtest.

6 Ottieni un elenco di server

Avrai bisogno di un elenco dei server che speedtest utilizza.

# speedtest --list > servers.txt

Ora controlla servers.txt per gli ID numerici del server o dei server contro cui vuoi eseguire i tuoi test.

# nano servers.txt

Il file apparirà simile a questo:

Recuperando la configurazione di speedtest.net...
 5833) Hub Network Services Ltd (Newport, Wales) [57.50 km]
 5938) Spectrum Internet (Cardiff, Gran Bretagna) [65.89 km]
 5443) Fasthosts Internet (Gloucester, Gran Bretagna) [74.31 km]
 6504) Secure Web Services Ltd (Shrewsbury, Gran Bretagna) [78.64 km]
 7265) Unitron Systems & Development Ltd (Telford, Gran Bretagna) [87.11 km]
 8225) Exascale Limited (Wolverhampton, Gran Bretagna) [96.08 km]
 3110) zero.net.uk Ltd (Studley, Gran Bretagna) [96.12 km]
12401) Dragon WiFi LTD (Haverfordwest, Regno Unito) [120.78 km]
 1153) Warwicknet Ltd. (Coventry, Gran Bretagna) [125.18 km]
 1685) Vodafone UK (Newbury, Gran Bretagna) [153.25 km]
 4384) Iomart (Leicester, Gran Bretagna) [157.40 km]
 1234) Uno (Milton Keynes, Gran Bretagna) [170.71 km]
 3504) TNP Ltd. (Manchester, Gran Bretagna) [170.93 km]
11747) Vispa (Manchester, Regno Unito) [170.93 km]

Gli ID dei server sono sul lato sinistro. La cifra alla fine di ogni riga è la stima che speedtest ha fatto della distanza, in chilometri, tra la tua posizione e quella del server, anche se non sono sicuro che sia molto accurata e può cambiare da esecuzione a esecuzione. I server di test saranno elencati in ordine di questa distanza, iniziando dal più vicino. Testare contro i server vicino alla parte superiore di questo elenco dovrebbe, in teoria, darti i ping più rapidi e le migliori velocità di download e upload rispetto ai server più in basso nell’elenco che sono molto più lontani.

7 Seleziona gli ID dei server e modifica bandwidth.sh

Ora sarebbe il momento di eseguire speedtest manualmente contro una selezione dei diversi ID dei server disponibili e vedere che tipo di risultati ottieni. Ho scelto un paio di server vicini a me nel Regno Unito e uno in California per il confronto. Il formato del comando da utilizzare è:

# speedtest --server 1234

L’output che vedrai sarà simile a:

Recuperando la configurazione di speedtest.net...
Testando da xxxxxxx (n.n.n.n)...
Recuperando l'elenco dei server speedtest.net...
Selezionando il miglior server in base al ping...
Ospitato da Uno (Milton Keynes) [187.87 km]: 33.243 ms
Testando la velocità di download................................................................................
Download: 1.60 Mbit/s
Testando la velocità di upload...............................................................................................
Upload: 0.55 Mbit/s

Una volta selezionati i server che desideri utilizzare, inserisci gli ID numerici dei server (ho usato 3 server ma puoi variare questo se lo desideri) nelle righe pertinenti in bandwidth.sh

runTest "5443"
sleep 10

runTest "1234"
sleep 10

runTest "1783"
sleep 1

Dovrai anche modificare il codice nella routine di errore che crea un’entrata fittizia se speedtest dovesse fallire in un particolare run.

    # contro quale server stiamo testando?
    if [ $1 = "5443" ] 
    then
        echo "5443,Fasthosts Internet,Gloucester,$RIGHTNOW,73.09,0.0,0.0,0.0"
    fi
    if [ $1 = "1234" ] 
    then
        echo "1234,Uno,Milton Keynes,$RIGHTNOW,168.27,0.0,0.0,0.0"
    fi
    if [ $1 = "1783" ] 
    then
        echo "1783,Comcast,\"San Francisco, CA\",$RIGHTNOW,8420.0,0.0,0.0,0.0"
    fi

I numeri dopo $RIGHTNOW in questo caso (ad esempio 73.09) sono le distanze in chilometri dalla tua posizione al server in questione. Non utilizzo questi valori da nessuna parte, quindi sono solo un segnaposto e potrebbero essere qualsiasi valore numerico.

Nota con quell’esempio 1783 che dobbiamo mettere le virgolette sulla posizione e scappare per farle entrare nel file CSV che stiamo creando. Le virgolette sono richieste qui perché questa posizione ha un comma al suo interno. Senza le virgolette scappate, la virgola verrebbe trattata come delimitatore di campo CSV, il che causerebbe un problema con l’importazione in SQLite. Se il server che selezioni ha un testo di posizione simile con una virgola al suo interno, allora dovrai usare le virgolette scappate.

8 Imposta un cronjob

Imposta un cronjob per eseguire una volta all’ora (o quanto spesso vuoi, entro limiti ragionevoli) per eseguire /usr/local/etc/bandwidth.sh. Se stai eseguendo ISPConfig, puoi usarlo per pianificare un cronjob.

In alternativa, alla riga di comando linux puoi inserire:

# crontab -e

Dovresti vedere qualcosa di simile a questo (ricorda che sei loggato come ‘root’):

* * * * * /usr/local/ispconfig/server/server.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
* * * * * /usr/local/ispconfig/server/cron.sh 2>&1 | while read line; do echo `/bin/date` "$line" >> /var/log/ispconfig/cron.log; done
1 * * * * /usr/local/etc/bandwidth.sh 2>&1

Se non stai eseguendo ISPConfig, allora questo potrebbe essere inizialmente vuoto. Aggiungi quell’ultima riga esattamente come mostrato sopra - lo spazio è importante - per eseguire lo script shell a partire dalle 00:01 e poi ripetere ogni ora, ogni giorno. Puoi scegliere orari diversi, ovviamente. (La prima volta che esegui questo, crontab ti chiederà quale editor vuoi usare - io seleziono nano.)

9 Imposta PHP open_basedir

Aggiungi /usr/local/etc all’entry PHP open_basedir per il sito web. In ISPConfig questo si trova nella scheda Opzioni per il sito web.

Questo consente al codice bandwidth.php di poter accedere al database SQLite, che abbiamo appena creato, in quella directory.

Avremmo potuto saltare questo se avessimo deciso di creare il database in una directory già impostata come accessibile, come /var/www/clients/client1/web1/web/, ma sarebbe stata una scelta scadente dal punto di vista della sicurezza.

10 Crea bandwidth.php

Devi copiare questo codice in un file chiamato bandwidth.php sul tuo server nella directory base dei documenti web. Se stai usando ISPConfig, questo sarà qualcosa come /var/www/clients/client1/web1/web/

 
 
 






Velocità di download - ultime 24 ore

Modifica questo file per utilizzare l’ID del server su cui vuoi riportare. Sto usando il server 1234 nel mio esempio qui, poiché ho scoperto che, dopo aver esplorato alcuni giorni di dati, questo server produceva cifre Mbps più allineate con le velocità che sentivo di ricevere. L’ID del server è nella clausola WHERE della dichiarazione SQL SELECT:

SELECT serverid, strftime("%H:%M", times) || " " || strftime("%d/%m/%Y", times) AS timestamp, sponsor, servername,   
download   
FROM bandwidth   
WHERE serverid = 1234   
ORDER BY times   
LIMIT 24 OFFSET (SELECT COUNT(*)/3 FROM bandwidth)-24;

Cosa sta facendo esattamente questa dichiarazione SQL? Se non sei familiare con SQL, allora diamo un’occhiata a ciascuna parte.

a. SELECT è il comando per leggere record da una tabella di database SQL ed è seguito dai campi da leggere e altre opzioni.

b. strftime(“%H:%M”, times) || “ “ || strftime(“%d/%m/%Y”, times) AS timestamp

è per riformattare la stringa datetime che speedtest ha creato nel suo output CSV in qualcosa di un po’ più user-friendly. Voglio date formattate nel Regno Unito, quindi questo prenderà una stringa come “2017-08-31T12:02:51.898186Z” e la trasformerà in “12:02 31/08/2017”. È più semplice fare questa riformattazione direttamente nella dichiarazione SQL piuttosto che doverla elaborare in seguito. Le ore qui saranno in UTC/GMT, il che va bene per me, ma potresti voler cambiare questo; ad esempio, se vuoi date formattate negli Stati Uniti, allora cambia quella seconda parte in strftime(“%m/%d/%Y”, times).

c. serverid, timestamp, sponsor, servername, download sono i campi che vogliamo leggere dalla tabella SQL e creare nel nostro oggetto JSON.

d. FROM bandwidth è il nome della tabella SQL da cui stiamo leggendo.

e. WHERE serverid = 1234 imposta il sottoinsieme della tabella da leggere - cambia questo per corrispondere all’ID del server che hai usato, e potresti voler leggere i dati per più di un server - ma questo complicherà il grafico.

f. ORDER BY times imposta l’ordine di output - vogliamo che sia ordinato in base al timestamp che speedtest ha impostato per ciascun run.

g. LIMIT 24 limita l’output a 24 record, poiché vogliamo solo mostrare 24 ore di dati e perché il nostro cronjob è impostato per eseguire una volta all’ora. Se eseguissi due volte all’ora, dovresti impostare questo su 48 per ottenere 24 ore di dati.

h. OFFSET (SELECT COUNT()/3 FROM bandwidth)-24; vogliamo gli ultimi 24 record dalla tabella poiché sono le voci più recenti di cui siamo interessati, quindi dobbiamo specificare un OFFSET per allinearlo con il LIMIT. Senza questo, otterremmo sempre i primi 24 record nella tabella piuttosto che i 24 più recenti. Per ottenere il giusto offset, contiamo tutti i record nella tabella con (SELECT COUNT()) quindi dividiamo questo per 3 (poiché stiamo eseguendo speedtest 3 volte all’ora, una per ciascuno dei 3 diversi server) e poi sottraiamo 24 da questo totale per ottenere la giusta posizione OFFSET in modo che LIMIT 24 ottenga i record che vogliamo.

Se hai modificato lo script bash per eseguire qualcosa di diverso da 3 diversi test del server all’ora, allora regola quella parte /3 di conseguenza. Se stai testando solo contro un server, allora la divisione non è necessaria affatto.

Potresti anche voler regolare le dimensioni complessive del grafico, dove ho preso la strada più semplice di codificare un formato adatto per il mio schermo - è impostato in questa riga:

11 Ottieni una copia locale dei file

Preferisco avere versioni locali di qualsiasi file css e js di libreria (ma non dei font di Google) necessari in una pagina web e se sei della stessa opinione, allora dovrai ottenere una copia sul tuo server di Chart.bundle.min.js e posizionarla nella directory /var/www/clients/client1/web1/web/scripts sul tuo server (o in quale sia la directory base giusta per te).

Puoi scaricare il file da: https://cdnjs.cloudflare.com/ajax/libs/Chartajs/2.6.0/Chart.bundle.min.js

Se non vuoi usare una copia locale, modifica bandwidth.php per puntare invece alla versione CDN pubblica. Cambia semplicemente questa riga:

in questa:

12 Abilita PHP in ISPConfig

Non dimenticare di abilitare PHP nelle impostazioni del tuo sito web, se non è già stato impostato.

13 Carica bandwidth.php nel browser

Abbiamo finalmente finito. Una volta che lo script shell bandwidth.sh ha avuto tempo di eseguire alcune volte per generare alcuni dati (o potresti eseguirlo manualmente più volte all’inizio), punta il tuo browser al sito web del tuo server Linux, carica bandwidth.php e dovresti vedere qualcosa di simile:

E sì, la mia banda larga è davvero così scadente!

Infine, ecco alcuni punti extra che vale la pena trattare:

14 Output del grafico a barre

Dobbiamo notare che le cifre di download e upload memorizzate nella tabella SQL sono in bps piuttosto che in Mbps (insieme a un numero sconcertante di cifre decimali - numeri come 1533681.5922415722). Questo è semplicemente il modo in cui speedtest produce i dati quando viene eseguito in modalità CSV. Per mostrare la cifra Mbps, piuttosto che bps, sull’asse y dell’output del grafico a barre ci sono un paio di righe incluse nel codice Javascript in bandwidth.php per eseguire la conversione:

    mbps = Math.round(bandwidth_data[i].download/1000).toFixed(3)/1000; 
    bvalue = mbps.toLocaleString(undefined, { minimumFractionDigits: 3 });

Utilizzare toLocaleString dovrebbe inserire la punteggiatura decimale corretta (un “.” o “,”) come impostato dalle impostazioni locali del tuo browser, ma questo dipende dall’implementazione ed è un po’ incoerente. Se vedi . invece di , e ti infastidisce, allora Globalize è il modo per risolvere questo. Vedi ‘18 Ulteriori passaggi e idee’ qui sotto.

Sono necessarie alcune righe in più per sovrascrivere il trattamento predefinito del codice hover degli zeri finali, poiché chart.js normalmente visualizzerà “2.000” come solo “2”, il che non è ciò che voglio, specialmente dopo aver fatto il lavoro di assicurarmi che siano lì in primo luogo:

    // sovrascriviamo il tooltip predefinito che elimina gli zeri finali anche se li abbiamo già messi lì
    tooltips: {
        callbacks: {
            label: function(tooltipItem, data) {
                var value = data.datasets[0].data[tooltipItem.index];
                var label = 'download: ';
                var retvalue = value.toLocaleString(undefined, { minimumFractionDigits: 3 });
                return label + ' ' + retvalue + ' Mbps';
            }
        }
    },

Questo è un bel esempio di come puoi ‘approfondire’ in chart.js e cambiare il modo in cui fa le cose.

Inoltre, ho impostato le opzioni del grafico per stampare il timestamp sull’asse x per ogni barra:

    xAxes: [{
        ticks: {
            autoSkip: false,
            maxTicksLimit: 24
        }
    }],

L’opzione predefinita (con autoSkip impostato su true) ha comportato un paio di spazi vuoti strani nelle etichette. Dovrai cambiare maxTicksLimit se vuoi visualizzare qualcosa di diverso da 24 voci.

Se desideri ulteriore aiuto nel modificare alcune delle opzioni di chart.js o non riesci a ottenere ciò che desideri, allora controlla le pagine specifiche di chart.js su Stack Overflow - ci sono molte informazioni utili lì - https://stackoverflow.com/questions/tagged/chart.js - Usa semplicemente la casella di ricerca per restringere ciò che stai cercando. Sfortunatamente, la documentazione di chart.js è carente in alcuni degli esempi più avanzati che sarebbero certamente di grande aiuto per iniziare a utilizzare questo fantastico pezzo di codice open-source.

15 Gestione degli errori

Durante i miei test iniziali, ho notato un paio di volte che speedtest riportava “Impossibile recuperare l’elenco dei server speedtest” nel file CSV. Presumibilmente, questo rifletteva i momenti in cui la mia connessione a banda larga era così scadente che speedtest non riusciva a connettersi al server di test. Questo testo non è ovviamente in un formato che vogliamo importare nel database SQLite, quindi avevo bisogno di una soluzione a questo che eliminasse sia questo testo indesiderato dal file CSV sia includesse un’entrata zero nel database per il particolare intervallo di tempo, poiché altrimenti qualsiasi voce mancante nella tabella SQL sarebbe semplicemente invisibile e getterebbe fuori allineamento che volevo avere di 24 voci al giorno quando creavo il grafico.

Vedrai in bandwidth.sh che lo script testa il codice di uscita impostato da speedtest utilizzando la variabile script $? e se è maggiore di zero, questo indica che speedtest ha fallito. Questo attiverà la funzione per creare un’entrata CSV fittizia - che viene poi utilizzata per sovrascrivere il file CSV per quel run.

Ci sono un paio di righe nello script bash che sono commentate ma che testeranno questa routine di errore per generare un’entrata zero fittizia se esegui lo script dopo aver decommentato quelle righe.

############################################
# caso di test/debug - costringe speedtest a fallire
############################################
# runTest "199999999"
# sleep 5
####### commenta dopo il test ##########
############################################

Questo utilizza un ID server ‘sciocco’ che speedtest non gradisce, costringendolo a restituire un codice di uscita non zero. Lo script dovrebbe quindi creare un’entrata fittizia che può sedere felicemente nella tabella SQL e essere ignorata o potresti eliminarla.

Un altro modo per costringere speedtest a fallire, per questo scopo di test, sarebbe rimuovere la connessione di rete del server. Non dimenticare che puoi eseguire lo script bandwidth.sh manualmente in qualsiasi momento, non devi aspettare che il cronjob lo avvii, anche se dovresti evitare di eseguirlo manualmente se un cronjob è imminente. Avere due script in esecuzione simultaneamente potrebbe probabilmente rovinare i file CSV e quindi la tabella SQL.

Se succede il peggio, allora c’è un file CSV di backup mantenuto come /usr/local/etc/speedtest.bak che dovrebbe contenere tutto l’output CSV da speedtest dalla prima esecuzione dello script bash in poi. Questo potrebbe essere modificato per rimuovere eventuali voci indesiderate, la tabella SQL cancellata e quindi l’intero set di voci CSV reimportato in SQLite.

16 Fusi orari

Speedtest riporta l’ora in UTC (fondamentalmente questo è lo stesso del Greenwich Mean Time o GMT). Utilizzare UTC significa che tutti gli orari memorizzati nella tabella SQL sono coerenti e l’ora legale non avrà alcun impatto indesiderato.

Ma questo significa che la routine di gestione degli errori in bandwidth.sh deve creare un timestamp per l’entrata fittizia per riflettere questo. Questo è piuttosto semplice - abbiamo appena incluso il flag –utc:

local RIGHTNOW=$(date --utc +%Y-%m-%dT%H:%M:%SZ)

Se desideri che le etichette dell’asse x del grafico mostrino orari diversi da UTC/GMT, allora il posto migliore per apportare tale modifica sarebbe nella dichiarazione SQL SELECT, ad esempio:

strftime("%H:%M", time(times, 'localtime')) || " " || strftime("%d/%m/%Y", times) AS timestamp

Questo utilizzerà le impostazioni del fuso orario del tuo server Linux per regolare gli orari mostrati sul grafico. Oppure potresti approfondire per capire come Globalize potrebbe farlo nel front-end.

Vedi https://www.timeanddate.com/time/gmt-utc-time.html e http://www.tutorialspoint.com/sqlite/sqlite_date_time.htm per ulteriori informazioni.

17 Ulteriori passaggi e idee

Speedtest non deve essere la fonte dei tuoi dati grezzi - potrebbero provenire da qualsiasi parte e riguardare qualsiasi cosa, non solo la velocità di internet. Il principio è lo stesso - un processo server back-end che può ottenere i dati grezzi in un formato utile e poi importarli in SQLite da uno script bash con un front-end che estrae il sottoinsieme di dati che desideri e poi li grafica.

Uno script bash più complesso potrebbe scrivere dati direttamente in una tabella SQL (utilizzando il comando SQL INSERT) se il formato CSV non è un’opzione. Quando progetti la tabella SQL, pensa a come potresti voler estrarre i dati in seguito.

Quando apporti modifiche, tieni presente il contesto del codice che stai modificando; cioè, abbiamo dichiarazioni SQL all’interno di uno script PHP all’interno di Javascript all’interno di HTML. Ricorda il livello in cui ti trovi e codifica di conseguenza. Può essere facile perdere il filo e finire per scrivere codice PHP in quello che dovrebbe essere Javascript! Posso garantire che questo non funzionerà.

Ecco alcune idee per ulteriori esplorazioni:

• toLocaleString non è implementato in modo coerente tra i browser. Usa Globalize e gestisci tutti i formati di numeri, date e fusi orari con esso.
• Controlla httpstat (c’è una versione bash) che consente di raccogliere diversi tipi di dati sulla connessione internet. Memorizza questo in una (separata) tabella SQL e grafica l’output.
• Migliora il front-end di bandwidth.php per dare all’utente la scelta di diverse opzioni: 24, 48, 72 ore; seleziona una data specifica, includi dati di upload e download, tempi di ping.
• Converti l’HTML per utilizzare codice Bootstrap reattivo in modo che funzioni bene su diversi dispositivi o dimensioni dello schermo.
• Esplora alcune delle altre opzioni di chart.js; magari un grafico combinato a linee e barre; cambia i colori e le dimensioni delle barre.
• sostituisci SQLite con MySQL e aggiungi maggiore sicurezza con accesso in lettura da PHP tramite utente/password.
• Costruisci un sistema simile ma utilizzando node.js.

18 Link

• speedtest: https://github.com/sivel/speedtest-cli
• SQLite3: https://sqlite.org/
• chart.js: http://www.chartjs.org/
• Globalize: https://github.com/globalizejs/globalize
• httpstat: https://github.com/b4b4r07/httpstat
• Bootstrap: http://getbootstrap.com/
• PHP: http://www.php.net/
• ISPConfig: http://www.ispconfig.org/
• Debian: http://www.debian.org/