..mer om .ODT i PHP

Jag har de senaste dagarna använt systemet i den här posten(http://www.abergman.se/skapa-odt-dokument-med-odtphp/) för att kunna generera dokument on the fly från variabler som jag själv anger, både placeholders i form av %PLACEHOLDER% och fördefinierad text. Allt är databasbaserat och fint.

Jag lärde mig att man inte kan deklarera variabler on-the-fly med php, MEN man kan använda arrayer, jag löste det såhär:

$variabel = data;
$array[$variabel] = $variabel;

Det innebär att $array[data]  = data. Det är ett smidigt sätt när man till exempel vill döpa variabler från värden i en databas. Den här lösningen kommer att användas för att generera bla avtal i Ngcrm.

Optimering med CDN (Content Delivery Network)

När man optimerar sidor jobbar man i många fall med att separera statiskt innehåll som bilder, javscript och css från dynamiska filer som .php. Eftersom de olika filtyperna har olika sätt att hanteras och olika uppdaterings/åldrigstid så väljer man ofta att leverera de olika filtyperna med olika webbservrar med olika cacheinställningar.

I många fall är det helt värdelöst att ha en dubbel uppsättning webbservrar att hålla koll på utan man väljer att lägga sina statiskafiler hos någon som kan leverera dem åt dig, ett så kallt Content Delivery Network(CDN).  Exempel på sådana är Amazon S3 och även flickr.

Ibland vill man själv ha koll på sitt innehåll och då kan det vara en idé att bygga ett eget CDN, hur man uppnår det på bästa sätt kan diskuteras men det alldra enklaste är helt enkelt att lägga dina filer på en annan server och länka in dem i dina dynamiska sidor.  För att sedan få lite kräm och hastighet på filerna bör du välja en webbserver som ärbra på statiska filer, tex nginx. Vill spara ännu mer kraft kan man även lägga en cache framför, som Varnish.

De stora CMS:erna WordPress och Drupal stöjder båda distribution av filerna till ett CDN, med häjlp av W3 Total Cache-modulen till WordPress kan du även lägga alla dina nyuppladdade filer på CDN:et mha FTP, helt sömlöst utan att dina användare och besökare märker det.

Inomkort kommer det en praktisk guide här på www.abergman.se på hur man bygger ett eget CDN, eller ett PCDN, Private CDN.

HipHop for PHP på Debian (Testing)

I mitt sökande efter bra sätt att optimera prestandan på maskinerna så sprang jag över “HipHop for PHP” som är utvecklat av killarna bakom facebook, som ett sätt för dem att kunna utnyttja sina maskiner bättre. Enligt egen utsago så har de kunnat halvera CPU-belastningen med upp till 50%!

Detta kan de uppnå genom att använda sig av HipHop for PHP som konverterar PHP:t till C++ och sedan kompilerar det, så man kan köra sin PHP-applikation som en demon, antingen direkt på port 80 och slippa ha en webbserver, eller som jag planerar göra; På någon annan obskyr port och använda Nginx som gateway.

Som vanligt när man ska testa något så får man inleda med att installera det, och då HipHop For php är relativt nytt så finns det ännu inga färdiga paket att installera, dessutom så kräver HipHop for PHP en del patchade paket för att funka, så vi är utlämnade till en manuell installation. När jag först skulle installera beroendena så provade jag på Debian Lenny, men tyvärr så fanns inte ett paket som hör ihop med libboost till Stable än, så istället för att försöka haxxa in det manuellt så valde jag att uppdatera burken till testing istället, då kunde jag utan problem dra in alla beroenden.

apt-get install cmake g++ libboost-dev flex bison re2c libmysqlclient14-dev libxml2-dev libmcrypt-dev libicu-dev openssl binutils-dev libcap-dev libgd2-xpm-dev zlib1g-dev libtbb-dev libonig-dev libpcre3-dev git-core autoconf libtool libcurl4-openssl-dev libboost-system-dev libboost-program-options-dev libboost-filesystem-dev

När det här är installerat, så är det dags att ge sig på HipHop for PHP och de paket som måste patchas och installeras manuellt, som jag uppfattar det så är patcharna skickade till respektive projekt för att komma med i paketet, men det verkar inte vara klart än. Först, ladda hem källkoden för HipHop:

mkdir hiphop
cd hiphop
git clone git://github.com/facebook/hiphop-php
cd hiphop-php
export CMAKE_PREFIX_PATH=`/bin/pwd`/../
export HPHP_HOME=`/bin/pwd`
export HPHP_LIB=`/bin/pwd`/bin
git submodule init
git submodule update
cd ..

Sedan är det dags att ladda ner  och patcha libevent.

wget http://www.monkey.org/~provos/libevent-1.4.13-stable.tar.gz
tar -xzvf libevent-1.4.13-stable.tar.gz
cd libevent-1.4.13-stable
cp ../hiphop-php/src/third_party/libevent.fb-changes.diff .
patch < libevent.fb-changes.diff
./configure --prefix=$CMAKE_PREFIX_PATH
make
make install
cd ..

Det ska inte vara något problem att kompilera, skulle du köra fast av någon anledning så får du skriva en kommentar så ska jag försöka hjälpa dig! Nästa i tur för att kompileras är ICU4, detta behöver inte patchas utan ska bara installeras.

wget http://download.icu-project.org/files/icu4c/4.2.1/icu4c-4_2_1-src.tgz
tar -xvzf icu4c-4_2_1-src.tgz
cd icu/source
./configure --prefix=$CMAKE_PREFIX_PATH
make
make install
cd ../../

Inga konstigheter där heller, nästa och sista paketet innan HipHop for PHP är libcurl, det är viktigt att komma ihåg -p0 som flagga i patch och att se till att tiden på maskinen är korrekt.

wget http://curl.haxx.se/download/curl-7.20.0.tar.gz
tar -xvzf curl-7.20.0.tar.gz
cd curl-7.20.0
cp ../hiphop-php/src/third_party/libcurl.fb-changes.diff .
patch -p0 < libcurl.fb-changes.diff
./configure --prefix=$CMAKE_PREFIX_PATH
make
make install
cd ..

Så var det dags för det sista innan vi kan testa; Kompilera HipHop for PHP!

cd hiphop-php
cmake .
make

Hela installationsprocessen är ganska straight forward och inga större konstigheter, dock så är den lite tidskrävande om man ska göra den på många maskiner. Hur man sedan använder HipHop återkommer jag med i ett senare inlägg.

För att testa så det fungerar som det ska så ska jag testa HipHop for PHP med ett enkelt “Hello World”-exempel: Läs det här

Källa: http://mediakey.dk/~cc/howto-install-hiphop-for-php-on-ubuntu/ som i sin tur tagit den från http://wiki.github.com/facebook/hiphop-php/building-and-installing-on-ubuntu-910

x86 64 eller x86

Jag behövde nyligen ta reda på om maskinen jag satt på var 64-bitars eller inte, detta av den enkla anledningen att jag planerar att testa HipHop för PHP på den. HipHop är i korthet ett sätt att konvertera PHP till c++ och sedan kompilera det och köra det som en standalone applikation, tanken bakom detta är att spara CPU då PHP är relativt prestandakrävande.

Hur som helst, för att ta reda på om maskinen är en 64 bitars eller 32 bitars så använder man sig av kommandot uname -a, och bör få en output som liknar den nedan.

Linux host.local 2.6.26-2-amd64 #1 SMP Tue Jan 12 22:12:20 UTC 2010 x86_64 GNU/Linux

I mitt fall var det således en 64 bitars maskin, vilket är perfekt, då hiphop än så länge bara funkar på 64 bitar. Om det inte framgår så är det x86_64 i slutet på raden som talar om vad det är för arkitektur.

CodeIgniter och Nginx

I sitt blogginläggCmsDirekt skriver David V. Wallin lite kort om hur man får ramverket CodeIgniter att lira på Nginx: Det är egentligen bara en rewriteregel och en liten förändring på hur man skickar sidor till php-fpm. Såhär ser  konfigurationen ut som du kompletterar din vhost med:

location /{
if (!-f $request_filename) {
rewrite ^(.*) /index.php?$1 last;
}
}
 
location ~ \.php$ {
fastcgi_pass   127.0.0.1:9000;
fastcgi_index  index.php;
include /etc/nginx/fastcgi_params;
fastcgi_param  SCRIPT_FILENAME  /var/www/example.org/index.php;
}
 

Notera att efter SCRIPT_FILENAME så skickar vi inte med variablen $FASTCGI som vi gör när vi konfigurerar för vanligt php, utan vi skickar explicit med index.php eller vilken sida man nu har som förstasida.

php5-fpm och “Short open tag”

I php så kan man tydligen fuska med taggarna, detta var inget jag visste sedan tidigare, men David visste. Så när han byggde www.ngweb.se så använda han sig av sådana taggar, dvs <? och ?>.

När vi sedan migrerade från apache2 till Nginx och php5-fpm så slutade dessa funka, ingen av oss visste riktigt varför men det visade sig efter att jag kollat igeom php.ini för php5-fpm att det är ett val i konfigurationen som stänger av eller slår på detta. Nu hade David redan fixat det här i koden, men det är värt att skriva ner ifall jag eller någon annan stöter på det igen. I konfigurationen för php5-fpm(och troligen all annan php) finns ett val som heter “short_open_tag” detta kan vara On eller Off, mer läsning om short_open_tag kan du hitta på: http://php.net/short-open-tag och www.cmsdirekt.se.

WordPress cache

Jag upplevde att  min blogg gick lite långsamt, även om så kanske inte var fallet. Så jag började fundera på hur jag skulle kunna fixa det och kom och tänka på att det kanske fanns en cacheplugin, jag har ännu inte fixat en cache för webbservern men det står på listan, så tills vidare fick jag nöja mig med att leta efter en plugin för att ordna cachen i wordpress, jag vet att det finns i drupal då jag minuterna innan hade meckat med http://www.ledigajobben.se/ för att få igång det och Boost-funktionen i drupal på Nginx, men mer om det senare.

I mitt googlande efter en cache modul så hittade jag WP-cache som verkade vettigt och enkelt att installera, det var bara att söka upp och installera pluginen samt lägga till en ‘define’ i wp-config.php på maskinen samt aktivera cachen så var det klart sen, och jag upplever att det gör en märkbar skillnad.

Mer om cache och Nginx senare, ska installera Varnish framför Nginx för att hantera cache för alla produktionssiter.

Nginx rewrite för drupal

Har du en drupalsite som du vill köra på Nginx så måste du skriva om rewrite reglerna för siten, precis som för WordPress( som du kan läsa om här: Nginx rewrite för wordpress ).

Precis som för wordpress ska du lägga till rewriteregler i location för roten för siten, det bör se ut såhär:

if (!-e $request_filename) {
    rewrite ^/(.*)$ /index.php?q=$1 last;
}

Eventuellt kan du behöva lägga till “break;” innan slutklammern för rewrite regeln.