eZ Publish 4

• Publié le 04 Décembre 2007 à 00:52
• 0 commentaire - 0 trackback

eZ Publish 4 est enfin sorti, j'en ai déjà beaucoup parlé lors de la sortie d'eZ Publish 4 Alpha1, après le eZ Publish Developper Day à Paris et encore hier avec mon benchmark entre eZ Publish 3.10 et eZ Publish 4 avec différentes configurations de PHP. Maintenant il n'y a plus qu'à l'utiliser. Mais surprise intéressante, l'extension eZ Flow annoncée et présentée lors du developper day est intégrée à cette version. J'ai regardé avec attention la vidéo de présentation qui reprend grosso modo la démonstration du 31 octobre; c'est assez impressionnant d'intégration et de facilité d'utilisation reste à voir si ce sera facilement utilisable/intégrable avec ses propres design et templates...

Enfin avis personnel, la version à vraiment attendre est la prochaine stable prévue en début d'année qui marquera l'intégration réelle et profonde des eZ Components ce qui promet des changements beaucoup plus importants et probablement des améliorations dans bien des secteurs (performances, flexibilité, ...).

Benchmark between eZ Publish 4 and eZ Publish 3.10 with or without a PHP opcode cache

• Publié le 02 Décembre 2007 à 19:36
• 3 commentaires - 0 trackback

After 2 alphas and one beta release, eZ Publish 4 rc1 has been released last week. I'm trying to upgrade but I'm facing an encoding problem. In the meantime, I made a benchmark between eZ Publish 4rc1 with PHP 5.2.5 and eZ Publish 3.10.0 with PHP 4.4.7 on a Debian Etch system using the Dotdeb packages. I also tested the performances of APC, eAccelerator and XCache opcode cache modules in those configurations.

Protocol

I'm using the recommended configuration for Virtual Host setup of eZ Publish. I wrote this shell script to test performances of eZ Publish.

#! /bin/sh
 
REQUESTS=100
CONCURRENCY=2
TESTS=5
PAUSE_TESTS=90
URL='http://dev.pwet.fr/blog'
DATA_LOG_DIR=~/tests/results_php4_blog/
CONF_DIR=~/tests/conf
PAUSE_CONF=180
 
PHP_CONFD=/etc/php4/apache/conf.d/
 
[ ! -d $DATA_LOG_DIR ] && mkdir -p $DATA_LOG_DIR
 
for ini in $CONF_DIR/* ; do
    INI_BASE=`basename $ini`
    echo $INI_BASE
    DATA_LOG="$DATA_LOG_DIR/$INI_BASE.dat"
    [ -f $DATA_LOG ]  && rm -f $DATA_LOG
    touch $DATA_LOG
    # active extension
    ln -s $ini $PHP_CONFD/$INI_BASE
    /etc/init.d/apache restart > /dev/null  2>&1 
    sleep 2
 
    # initialize cache
    wget $URL -O /dev/null > /dev/null 2>&1
    sleep 2
 
    # tests
    for i in `seq 1 $TESTS` ; do
        echo "  Test $i"
        ab -c $CONCURRENCY -n $REQUESTS $URL | grep 'Requests per' | tr -s ' ' | cut -d ' ' -f 4 >> $DATA_LOG
        sleep $PAUSE_TESTS
    done
    sleep $PAUSE_CONF
 
    rm -f $PHP_CONFD/$INI_BASE
    /etc/init.d/apache restart
done

I've run this shell script with a PHP4 setup (eZ Publish 3.10) and then with a PHP5 setup (eZ Publish 4.0rc1) sharing the same database. The script uses 4 configurations of PHP (no opcode cache, apc, eaccelerator, xcache), for each it makes 5 series of 100 requests with a concurrency of 2 with ab (Apache Benchmark) and it logs the mean number of requests per second. There are pauses between tests. I've run those tests on two pages of this site on a dedicated test server, the first one is the /blog page with view cache et cache-block enabled and the second one is /man/linux but with no view cache and no cache-block at all in order to see how eZ Publish 4 and 3.10 performs on retrieving its cache or on building a page from scratch. The first one makes 6 SQL queries and uses 2 cache-block and its view cache. The second one, without content related caches, makes about 100 SQL queries an displays about 10 XML blocks and 3 dynamic lists.

Result with a cached page

Without an opcode cache on cached page, eZ Publish 4 is about 10% quicker than eZ Publish 3.10 but with an opcode cache system, the difference is about 50% ! It's interesting to note that with PHP4, eAccelerator seems to be the faster yet, about 10% more than APC or XCache but with PHP5 there's almost no difference (more or less 2%).

Result with a page without content related cache

In this test, without an opcode cache, eZ Publish 4 is 85% faster than eZ Publish 3.10. And with an opcode, eZ Publish 4 using PHP 5.2.5 is about 150% faster than eZ Publish 3.10 !

Conclusion

No doubt, eZ Publish 4 is really faster than eZ Publish 3.10 and even more with an opcode cache.

I think I'm going to test eZ Publish 4 and 3.10 with apache 1.3 and apache 2.2 and perhaps with different configuration of MySQL 5.0, stay tuned :)

URL aliases transformed into numbers when upgrading to eZ Publish 3.10.0 ?

• Publié le 26 Novembre 2007 à 00:20
• 1 commentaire - 0 trackback

After the slowness of the PHP upgrade script and the disappearance of the URL Wildcard translation (these problems are corrected in the future 3.10.1 release), eZ Publish 3.10.0 gives me another problem when I try to upgrade a 3.9.0 site. Running the updateniceurls.php PHP script transforms the nice URL aliases into numbers. Another developer seemed to have the same problem in the forum, but no solution was provided...

In fact, for this site I configured one var directory for each siteaccess (I don't know why...), so when I cleared the cache using ezcache.php script only the cache of the default siteaccess was really cleared and obviously I specified the one with a dirty cache to run upgrade scripts ! That's why updateniceurls.php didn't find the URL transformation commands and made strange things...

We can sometimes read " Remember to clear the cache", now I would say " Remember to clear the cache for all siteaccesses" :-)

Le bug d'Internet Explorer sur le téléchargement de fichier en PHP (et autres ...)

• Publié le 19 Novembre 2007 à 23:25
• 0 commentaire - 0 trackback

Via PHPIndex, j'ai lu aujourd'hui un article très intéressant sur la mise en cache côté serveur et la manipulation du cache côté client en PHP plus une introduction au package PEAR Cache_Lite. Hormis ce dernier chapitre, la majeure partie de l'article est applicable avec d'autres langages pour peu que ceux-ci soient capable d'envoyer des en-têtes HTTP au navigateur via un équivalent de la fonction header.

Mais au détour de cet article, en page 2 pour être exact, l'auteur explique un des bugs d'Internet Explorer intervenant lorsqu'on force le téléchargement d'un fichier via un script côté serveur en employant un code du type suivant (souvent employé lors de la génération de d'exports en tout genre) :

<?php
// différentes opérations
header( 'Content-Disposition: attachment, filename=fichier.ext' );
// ici je génère mon fichier
// ...
?>

L'envoi d'un en-tête de ce type provoque sous IE un comportement complètement aberrant. En fait, ce navigateur (si on peut appeler cela comme ça) fait une première requête pour télécharger le fichier puis en exécute une seconde avant de proposer effectivement à l'utilisateur d'ouvrir le fichier et donc si vous envoyez d'autres en-têtes pour éviter la mise en cache côté client du fichier et bien IE efface le fichier qu'il vient de télécharger lors de la seconde requête HTTP !

La solution est donc d'envoyer des en-têtes HTTP indiquant la mise en cache du fichier généré soit de manière permanente si celui-ci ne change pas (via les en-têtes Pragma et Cache-Control) ou sur une durée plus moins longue (via l'en-tête Last-Modified)... Voila une belle Microsofterie à classer dans un coin de la tête sous peine d'y perdre encore 2 bonnes heures la prochaine fois...

Apache Rewrite rules to replace wildcard based url translation in eZ Publish 3.10.0

• Publié le 15 Novembre 2007 à 22:14
• 2 commentaires - 0 trackback

Wildcard based URL translation has been removed in eZ Publish 3.10.0. In the upgrading from eZ Publish 3.9.x to 3.10.0 documentation on eZ.no, we can now read (I think this note was not there when I upgrade at the beginning of October...) :

Before continuing, note that eZ Publish 3.10.0 does not support wildcard based URL forwarding anymore. This possibility was removed when implementing the multilingual URLs functionality. However, it might be added in the future (refer to changelogs and latest release announcements for more information).

Wildcard based URL translation is (was...) a very easy to use way to install a kind of simple rewriting rules on a site from eZ Publish almost without technical knowlegde. I use this feature to shorten long URLs when using the layout module for specific RSS feeds for instance.

Wildcard rules are still in the database, so I wrote a small script that transforms eZ Publish wildcard rules into apache rewrite rules. You can download the script, you just have to run it from eZ Publish root directory. For me, it generates something like :

#### Auto-generated rules ####
## you may need to load mod_rewrite
## you may need to uncomment the following line
# RewriteEngine on
### Direct rules
## for those rules, you need to load mod_proxy
# eZ Publish rss/feed/tag/* -> layout/set/rss/content/view/rsspost/{1}
RewriteRule rss/feed/tag/(.*) layout/set/rss/content/view/rsspost/$1 [P,L]
# eZ Publish rss/feed/commentaires/* -> layout/set/rss/content/view/rssco/{1}
RewriteRule rss/feed/commentaires/(.*) layout/set/rss/content/view/rssco/$1 [P,L]
# eZ Publish rss/feed/trackback/* -> layout/set/rss/content/view/rsstb/{1}
RewriteRule rss/feed/commentaires/(.*) layout/set/rss/content/view/rsstb/$1 [P,L]

You can put the generated code in the apache configuration, but you'll probably have to tweak rewrite rules. Of course mod_rewrite has to be loaded in apache (you already have it in a Virtual host setup) and for direct rules (kind of alias without redirect) you also need mod_proxy to be loaded. As I use apache 1.3 under Ubuntu, I run these commands as root :

$ sudo apache-modconf apache enable libproxy
Replacing config file /etc/apache/modules.conf with new version
$ sudo /etc/init.d/apache reload