Linux, PHP, MySQL e JAVA Opensource blog

Vedremo in questo articolo come poter lavorare con il server web apache per migliorare le prestazioni del proprio server web e risparmiare al contempo anche banda internet (preziosa e costosa).

Per fare questo si può utilizzare un fantastico modulo di apache, mod_deflate.

FUNZIONAMENTO

Prima di tutto comprendiamo il funzionamento di mod_deflate e cosa fa. Questo modulo si occupa di comprimere html, documenti, immagini e quantaltro prima di servirle al client.
In tal modo otterremo una diminuzione nell’utilizzo della banda e il sito sarà in parte più rapido anche per quei navigatori che dispongono di connettività non a banda larga o comunque non eccelsa.

QUANDO UTILIZZARLO E COME

E’ importante però comprendere quando possiamo utilizzarlo e soprattutto se non sarà un boomerang che ci torna sulla faccia. Per farlo bisogna quindi analizzare il problema.

A) Contenuto del sito web

Nel caso in cui il nostro sito web sia composto prevalentemente da elementi testuali (CSS, HTML, XML etc…) otterremo un’effetto eccezionale comprimendo tali contenuti. Nel caso invece il sito sia composto da Flash, immagini pesanti etc… l’effetto sarà praticamente nullo.

B) Il nostro server ha abbastanza processore?

Un altro aspetto è legato alla potenza del server, infatti se da un lato si ottiene un miglioramento sull’aspetto della banda, avremo come controindicazione un impatto sul carico della CPU che per ogni richiesta deve comprimere il file prima di inviarlo al client. Se ne evince quindi che in caso di poca potenza rischiamo di risolvere i problemi di banda e causarne sull’HW del server web.

ATTIVAZIONE DEL MODULO

Se apache come di default su CentOS 5.1 (presa in esame per l’articolo) ha già incluso il modulo, bisogna solo scommentare la riga relativa:

LoadModule deflate_module modules/mod_deflate.so

CAMBIO CONFIGURAZIONE SERVER WEB

A questo punto dobbiamo definire in apache come e dove utilizzare il modulo.
Per fare questo è davvero inutile andare a sprecare bit su questo articolo :-D, per cui vi rimando direttamente alla parte di configurazione sul sito di apache stessa:

MOD_DEFLATE CONF

Una nota importante da fare, prima di chiudere l’articolo, è relativa alla possibilità di escludere alcuni browser che non supportano pagine zippate e di poter escludere file come ZIP, Immagini, flash etc… (visibile da docs su apache)

Nel caso vi capiti di dover spostare, migrare, gestire un sito web sviluppato sotto piattaforma Windows potrebbe capitare un problema dovuto alla differenza tra Windows e Linux nella gestione del case sensitive/insensitive.

Infatti se mentre sotto piattaforma Windows una URL che fa riferimento a: http://www.miosito.tld/immagine.html apre regolarmente l’eventuale file  IMMagine.html, sotto Linux otterremo un bel NOT FOUND 404.

Naturalmente la soluzione drastica di sistemare tutte le URL o i nomi dei files è abbastanza complicata, lunga, laboriosa e inutile. Per ovviare al problema in apache ci viene incontro il modulo mod_speling attivo o comunque presente su quasi tutti gli apache rilasciati con le varie distribuzioni.

Per poterlo utilizzare verificate con in httpd.conf vi sia scommentata e presente la riga:
LoadModule speling_module modules/mod_speling.so

Nel caso questa riga fosse commentata,  decommentatela e riavviate il server web.

Per default (giustamente) tale modulo è disattivo. Quindi sarà sufficiente definire per la directory o per il virtual host desiderato che tale modulo sia attivo. Per fare ciò è ad esempio possibile inserire queste semplici righe:
<Directory “DOCUMENT ROOT SITO WEB”>
CheckSpelling on
</Directory>

Riavviate il web server e tutto dovrebbe funzionare al meglio.

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com

Casualmente mi sono imbattuto nel dover variare l’impostazione di memory limit su un server di cui non avevo il minimo accesso.
Solitamente infatti sono abituato a sviluppare su server Linux sui quali ho anche poteri di amministratore, in questo caso trattandosi di un hosting su server di un altro provider mi sono imbattuto nel dover aumentare memory_limit per poter far funzionare il noto CRM Sugar Force.

La variabile presente nel php.ini denominata memory_limit ha il compito di limitare il consumo di memoria massimo per uno script php in modo tale da evitare potenziali problemi al server web stesso in caso di cattiva gestione dello script o per qualche loop.
Per default tale valore è impostato ad 8 Mbyte, valore secondo me più che ragionevole.

In pratica Sugar Force richiede la bellezza di 32 Mbyte di memoria (se non erro) per poter funzionare.

Fatto sta che il provider in questione (giustamente) aveva l’impostazione di memory limit globale settata a 8 Mbyte e non funzionava una mazza…

Dubbioso sul poter realmente variare tale impostazione sono andato sul sito di php e nell’appendix ho scoperto quello che MAI mi sarei aspettato:

PHP_INI_ALL per intenderci indica che il valore è variabile da QUALUNQUE script php! Nemmeno come PHP_INI_PERDIR che indica invece che il valore è variabile o per directory da configurazione generale di apache o da .htaccess (se consentito Override da apache).

Insomma, nel caso specifico mi è anche andata bene perchà© ho potuto comodamente caricare in .htaccess “php_value memory_limit 64M” per poter far funzionare il CRM  perà questa cosa per me ha aperto un forte dubbio su tale scelta fatta dagli sviluppatori di php e in particolare dalla Zend.

Fortunatamente la soluzione è abbastanza facile, è infatti sufficiente disabilitare l’Override di apache ([per altro impostazione di default] non rendendo effettive le direttive di .htaccess che vengono quindi ignorate) e disattivando da php.ini la possibilità  di utilizzare la funzione ini_set().

Perà per un provider che eroga hosting per chiunque acquista uno spazio web (magari a prezzi stracciati) diventa limitativo e restrittivo.
Penso che un approccio diverso da parte della Zend e degli sviluppatori di php in merito a tale configurazione sarebbe più opportuno… almeno per le nuove versioni e configurazioni di default.

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com

Volevo scusarmi per i problemi di raggiungibilita’ del blog che si sono verificati in questi giorni a causa di problemi tecnici del provider che ospita il sito web, DB e posta elettronica.

Non ho idea di quali siano stati i problemi, tuttavia hanno richiesto interventi di manutenzione straordinaria da parte di Natan (hosting provider).

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com

Anche se il blog si propone per lo più per quanto riguarda php, Linux etc… ho trovato un articolo utile e interessante che riguarda l’URL rewrite anche in ambiente Windows su tecnologia ASP.NET

http://blog.devexperience.net/en/10/URL_Rewriting_implementing_a_HttpHandler.aspx

Vi ricordo che nel blog sono presenti gli articoli e brevi how to per la gestione mod_rewrite di apache.

http://www.massimo-caselli.com/2006/01/23/wordpress-gestione-mod_rewrite/

http://www.massimo-caselli.com/2006/01/08/mod_rewrite-apache-sviluppo-siti-internet/

http://www.massimo-caselli.com/2006/01/16/apache-mod_rewrite-siti-multilingua/

Ciao. Maxgrante
info[AT]massimo-caselli[DOT]com