Autore: bosh (Pagina 30 di 49)
Uno dei problemi noti della prima serie della BMW Z4 (E85) è l’otturazione dei canali di scolo della capotte. Percui seguendo la guida in allegato ( Manutenzione Cappotte E85 pulizia scarichi (ENG) ) ho provveduto a far pulizia. La guida è abbastanza chiara anche se ho trovato difficoltà nel rimuovere i PIN, l’autore della guida li ha rotti e sostituiti … io con cun pò di pazienza e molto svitol sono riuscito a rimuoverli senza romperli.
Inoltre il tappo in gomma è abbastanza difficile da vedere, bisogna mettere effettivamente la testa sotto la macchina se no non si vede, percui è opportuno avere i cunei o almeno un crick idraulico affidabile. Da evitare i crick meccanici.
I canali comunque erano ragionevolmente puliti… solo qualche sassolino. Evidentemente l’hard top e il garage aiutano.
Un controllo dopo 9 anni era comunque opportuno farlo.
PHP ha questo fastidioso problema che è stato concepito come se la RAM e la compilazione fossero il peccato originale.
Ne consegue che, con l’approccio di base, quando chiedete una pagina il povero webserver lancia PHP indicandogli la pagina richiesta, questo si legge lo script, processa tutti i file da includere, in modo ricorsivo, e quando ha finalmente lo script completo, lo trasforma in codice eseguibile (a.k.a. lo compila just in time) e come ultima cosa lo esegue. La cosa è immensamente inefficiente se deve essere fatta ogni volta che viene richiamata una pagina. Sarebbe bello delegare ad altri il linking e la compilazione per lasciare al sever solo l’esecuzione ma questo è molto complesso da fare con PHP (anche se qualcuno lo ha fatto) percui ho scelto l’approccio più tradizionale della cache.
Ci sono due moduli che possono venirci in aiuto APCu e OPCache.
Il concetto di base è di non rieleggere (e possibilmente non ricompilare) file messi in cache.
OPCache in particolar modo memorizzare il bytecode risultante dalla compilazione delle pagine in memoria e quindi raggiunge l’obbiettivo dell’efficienza. Su un server di produzione con aggiornamenti poco frequenti si possono calibrare le impostazioni per ricompilare il meno possibile.
La mia configurazione di OPCache assomiglia a questa :
zend_extension=/usr/lib64/php/modules/opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=120
opcache.blacklist_filename=/etc/php.d/opcache*.blacklist
In particolar modo la frequenza di rivalidazione a 2 minuti mi è sembrata ragionevole ma può essere ulteriormente aumentata. Il valore è in secondi, più sale e più aumentano gli hit della cache, ma aumenta anche il tempo che passa tra quando una modifica viene caricata sul server quando effettivamente diventa visibile.
OPCache è incluso di default a partire da PHP 5.5, ma nella mia installazione ho ancora PHP 5.4 quindi è necessario installarlo separatamente.
Come risultato ho un Time to first byte per wordpress di 0,4s e download dell’html in 0.6s. In hosting (dove immagino ci siano persone che pensano molto come ottimizzare i server in quanto ottimizzazione uguale minor costi) 0,45s e 0,8s
Con phpBB il Time to first byte scende addirittura a 0,13s e html completo in 0,52s .
Installiamo un pò di tool di base
yum install net-tools
yum install ftp
yum install wget
wget è particolarmente comodo per clonare un intero archivio ftp, ad esempio dall’hosting precedente. La sintassi è questa :
wget -r –user=”user@login” –password=”password” ftp://server.com/
Alla fine l’installazione di test di questo blog si può vedere qui.
Ora il problema principale sarebbe abbassare il tempo del primo byte fornito, che al momento si assesta sui 1,5-1,7 secondi nonostante il carico del server sia nullo.
La valutazione delle performa può essere fatta su WebPagetest.
Una guida interessante si puo trovare a questo link anche se non sembra utile per abbassare il tempo del primo byte. Apache Bench si trova nel paccheto httpd-tools.
Il problema dei test proposti è però l’eccessivo parallelismo. Impostare a 1000 apache bench con 32 processi php-fpm in ascolto mi sembra assurdo e infatti falliscono tutti (per altro senza che apache bench se ne accorga). Di mio ho impostato minimo 5, massimo 24. E con 24 richieste parallele la velocità è effettivamente molto compromessa.
Esercizi di programmazione con commenti e suggerimenti social. Interessante… Ma pare nessun supporto per java http://educationware.net/exercism-io-become-a-better-programmer/
La piattaforma che ho scelto è nginx per le risorse statiche e come reverse prowxy, php-fpm o tomcat 8 per le app, mariadb per la persistenza.
Ma la prima cosa da far funzionare è la persistenza, in quanto le app è facile mantenerle sull’hosting attuale fino alla scadenza ma la persistenza deve essere spostata per prima.
Ma per la persistenza serve una piattaforma di gestione … il che significa l’odiato/amato phpMyAdmin e quindi un server php funzionante. Quindi facciamo le cose in ordine … questa è la guida da cui ho tratto ispirazione -> LINK. Poi forse la traduco con le personalizzazioni che ho fatto, o forse no.
Ora probabilmente php deve essere configurato per gestire l’upload di file un pò piu grossi della configurazione standard a meno che i vostri database siano microscopici.
Quindi su php.ini
post_max_size = 50M
upload_max_filesize = 50M
In caso di DB molto grossi può essere utile comprimere in zip il dump e alzare il limite della ram assegnata a php e il timeout. Ad esempio
php.ini :
max_input_time = -1
memory_limit = 128M
(Sarebbe bene riportare questi parametri a valori piu cautelativi una volta terminata l’importazione, sopratutto per il max_input_time)
Scarichiamo phpMyAdmin e installiamolo su un virtual host fatto apposta. Noip.com offre la possibilita di creare un pò di domini di terzo livello gratuitamente e può essere utile per il nostro scopo.
In alternativa se proprio phpMyAdmin non digerisce il dump c’è sempre l’importazione da linea di comando. L’istruzione è questa :
mysql -u <username> -p -h localhost <database_name> < dumpfile.sql
Per ogni database si dovrebbe essere un utente diverso, momentaneamente abilitato alla connessione da qualsiasi host con privilegi sui soli dati (SELECT/INSERT/UPDATE/DELETE) per il solo database che deve usare. Non cadete nella tentazione di assegnare ad un utente con accesso remoto tutti i permessi su tutti i database.
Terminata la migrazione bisognerà disattivare l’accesso da remoto.
I permessi possono essere testati con lo stesso phpMyAdmin.
Si ci sono ricascato, costano poco percui mi sono detto… perchè pagare n hosting ( n<10 ) quando puoi prenderti un VPS, farci quello che vuoi e vivere felice.
La prima risposta di una persona sana di mente direbbe perchè lo devi gestire e non hai il tempo per farlo. Ma visto che non lo sono chissene.
OVH vende vps ad un prezzo ridicolo quindi ne ho preso uno per qualche mese e vediamo che succede. La scelta è ricaduata su server CENTOS 7, 64bit, 1 giga di ram, 1 vcore e 10 giga di spazio.
Nelle prossime puntate le scelte che ho fatto e come è andata a finire.
- Java unlimited runtime class and resource redefinition – Hotswap Agent
Hotswap agent provides Java unlimited runtime class and resource redefinition. Hotswap agent supports all major frameworks, it is free, open source and extensible.