1) Scaricare pacchetto e scompattare sul desktop (versione NON TS):
http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_win_nonts_x86.zip

2) Copiare il file
ioncube_loader_win_5.2.dll in:
C:\Programmi\Zend\ZendServer\lib\phpext

3) Aprire il file con editor testuale:
C:\Programmi\Zend\ZendServer\etc\php.ini
Sopra la riga:
zend_extension=”C:\Programmi\Zend\ZendServer\lib\ZendExtensionManager.dll”
Inserire queste due righe:
zend_extension=”C:\Programmi\Zend\ZendServer\lib\phpext\ioncube_loader_win_5.2.dll”
zend_extension_ts=”C:\Programmi\Zend\ZendServer\lib\phpext\ioncube_loader_win_5.2.dll”

Salvare e riavviare apache.

Verificare in phpinfo() se l’estensione viene caricata correttamente.

Per prima cosa, installiamo freetds:
yum install freetds

Dopo procediamo a installare l’estensione mssql di ZS che non � fornita di default:
yum install php-mssql-zend-ce

L’estensione sar� attivata da sola. Meglio comunque riavviare lo zend server.

Andare all’interno di /etc/freetds.conf

Mettere:
# Myserver
[mysqlserver]
host = 192.168.X.X
port = 1433
tds version = 8.0

A questo punto per connettersi da php utilizzare:

mssql_connect(“192.168.X.X”, “login”, “pwd”) or die (“Failed”);

E il gioco � fatto.

http://www.addedbytes.com/apache/mod_rewrite-cheat-sheet/

Benchmark apache 2.2.x VS Lighttpd 1.4.x

Se qualcuno fosse a conoscenza di qualche modo (da firebug non lo capisco) per individuare da client se un server utilizza mod_deflate e me lo segnala far� cosa ben gradita.

Spero di poter ottenere una maggiore rapidit� nelle pagine visto che di fatto il blog � composto tutto da html, css etc…

[UPDATE] A quanto pare l’entry che ho messo nell’.htaccess viene ignorata… infatti con questo tool:
http://www.gidnetwork.com/tools/gzip-test.php

Pare che le pagine del blog non siano zippate, mentre ad esempio quelle di www.190.it si…

[FONTE]: http://news.netcraft.com/archives/2008/04/14/april_2008_web_server_survey.html

Di primo acchito avevo pensato ad una crescita importante di Lighttpd… (che comunque cresce al punto che la linea verde inizia a intravedersi) e invece eccoti Microsoft che fa un balzo in avanti notevole in trend di crescita da ormai due anni…

Da notarsi anche Google, in grande ascesa…

Insomma, brutti tempi per il server web re indiscusso? Ai posteri l’ardua sentenza…

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 , 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)

PREMESSE AL PROBLEMA

• mysql versione > 4.1.x
• Tipo di encoding delle pagine web php utf8

DESCRIZIONE PROBLEMA

La situazione problematica nasce nel momento in cui abbiamo un sito web che deve gestire caratteri extra latini, per esempio nel mio caso ho affrontato questo problema dovendo realizzare un sito in lingua russa, ovvero utilizzando il cirillico.
Il mio approccio alla situazione e’ stato quello di realizzare TUTTE le pagine web con codifica utf8 e database, tabelle e campi di testo utf8 a loro volta.
La cosa che mi ha fatto impazzire e capirci veramente poco per diverso tempo e’ che se io inserivo nel database caratteri cirillici come ad esempio (Привет – ciao) e da PhpMyADMIN (di seguito PMA) vedevo male, idem il dump, mentre quando tiravo su i dati da applicativo tutto funzionava a meraviglia.
Capitava l’inverso con PMA, ovvero se inserivo in cirillico su PMA e visualizzavo da PMA tutto bene, via applicazione niente.

SOLUZIONE

Prima di tutto vi invito a leggervi questa parte di manualistica online di mysql, CHARSET.

Sostanzialmente sui server mysql di sistemi di hosting italiani (ma credo anche americani) e comunque in generale, l’impostazione del default_character_set � impostata a latin1.
Ma anche qualora sia impostata ad utf8 quando via script php ci connettiamo al database mysql la nostra sessione di default (nonostante la pagina sia encodata utf8) sar� attivata con character set latin1, cosa succede quindi, che i dati e le query che inviamo sfasano e il sistema memorizza erroneamente i dati.

Di fatto il comportamento giusto lo ha PMA, dobbiamo cercare quindi di emularlo.
Per farlo basta di fatto lanciare dopo ogni connessione la seguente query: SET NAMES utf8
Cos� facendo la connessione tra client e server sar� UTF8.

CONCLUSIONE

Per concludere possiamo dire che per siti che trattano lingua standard europee come italiano, inglese, francese etc… possiamo avere tutto il DB latin1, connessione client server latin1 ed encoding ISO-8859-1

Nel caso di siti con cirillico, arabo etc… utilizziamo tutto il database UTF8, encoding delle pagine UTF8 e soprattutto dobbiamo eseguire per sicurezza la query sopra indicata dopo ogni connessione con mysql.

Mi scuso per non essere stato molto chiaro in alcuni punti, purtroppo questo argomento � complesso e fastidioso…
Se avete suggerimenti sono benvenuti.

Ciao a tutti. Max
info[AT]massimo-caselli[DOT]com