lighty's life

lighty developer blog

Optimizing PHP + FastCGI

Over the last evenings I helped several lighty users to tune their application stack. Instead of telling the same story over and over again I wrote it down into a wiki page: "wiki://Docs:PerformanceFastCGI"://trac.lighttpd.net/trac/wiki/Docs%3APerformanceFastCGI Over time this will be the main source for application tuning, hints and secrets.

XCache's Demo

It has been about 5 months since the first announcement of XCache.
But many of you may still wonder how XCache “looks” like. So i’ve spent some hours and finally setup Administration demo page and
Coverage viewer demo page

XCache was stable (the cacher stufs), but now becomes more stable (installing, configuring), and seems a bit hot recently if you may google for “php” +"xcache" :)

Thanks for your support and encourage, XCache will goes on and on..

Forum Is on the New Host

The forum just got migrated to the new lighty-server. As long as the DNS is not update and as fallback, the old lighty server is proxying to the new host. As a side-effect, registering a account in the forum works again. The trac on the new host also sends out notifications on ticket updates again.

The Docs Are Dead, Long Live the Docs

... oh not again. The Docs are now in the wiki instead of a dead, boring manual, see "www.lighttpd.net"://www.lighttpd.net/ points to the new location already. If you want, the docs are editable for everyone now. It is an easy way to improve the docs, check if they are right, fix typos, rephrase the wording, add more examples, ... Thanks go to hoffie and the others who helped to move the docs to the wiki.

Mod_cml Is Dead, Long Live Mod_cml

Yep, mod_cml will vanish from the distribution of lighttpd 1.5.0. It will get a new name and will get a full blown set of functions to manipulate the execution of a request in lighty. It reason to rename mod_cml is that the focus of this module has changed from the its first implementation. It is not about checking if a request is a cache-hit or not. It is about deciding how to handle a request. Any status code can be returned, any content source will be able to be queried to assemble the content (files, memcache). The main reason is to allow us to change the names like 'trigger_handler' and 'CACHE_HIT' to something more appropriate. In the end no big change, but a neccesary one to make the use of this powerful module more obvious. ... Perhaps the new name will be mod_cml ... what would be the new meaning of this abbreviation ? Any suggestions ?