[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: lua use in lighttpd cml
- From: Markus Walther <markus@...>
- Date: Sun, 05 Feb 2006 14:16:43 +0300
Klaus Ripke wrote:
recently we got some surprising news about lighty
(like this single threaded webserver working
almost the same as the multithreaded zeus),
anyway, I found no track of the use of Lua in it's CML
(on the list nor the wiki nor uses.html).
Yes, I noticed this too some time ago and even wrote Lua scripts to
abuse it a little :-) See below for a small example.
You need a 1-line patch to enable GET params (script?a=1&b=2&c=3 => Lua
global table get={a=1,b=2,c=3) to work correctly in lighttpd 1.4.9
(patch available from me or the lighttpd developer).
CML stands for Cache Meta Language and is a way to describe
sophisticated caching behaviour of the lighttpd web server, turning
dynamic web pages (driven by PHP, Lua, what have you) into static files
whenever there was no change. So, you get the full power of Lua to
describe when and how to cache, and you communicate with the web server
using a few reserved variables and return values
(output_contenttype,request,get,output_include,CACHE_HIT,CACHE_MISS --
see below). The latest functionality in CML is called PowerMagnet, a way
to do sophisticated URL rewriting AFAIK.
The developer, Jan Kneschke, notes it's _not_ a good idea to (ab)use
this to _also_ generate the dynamic web pages themselves (that's what I
did for fun in my experiments, BTW). This is because lighttpd is
single-threaded for reasons of maximum speed, so CML-based dynamic
content generation happens synchronously, blocking everything until it's
done. He recommends using the FastCGI interface instead, so that's what
I'm doing now.
But yes, for quick Lua web scripting hacks and if you are not too
concerned about their performance, lighttpd is a perfect and very nice
web server that can be built out of the box with Lua.
(Is lighttpd perhaps the only high-performance web server where Lua is
available so directly/not as a module?)
It's a pity a chance was missed to use Lua to also handle the
configuration files. Jan Kneschke says Lua/CML came _after_ that part
was designed/implemented and he doesn't want a dependency on Lua in
embedded situations with tight memory. I may however add this as an
option when I have time.
So for the record
http://lighttpd.net/documentation/cml.html
Jan notes a nice over 30 fold speedup (4900:150)
compared to doing the same in PHP.
That's wrong. The comparison is about simulating caching _in the
scripting language_ (PHP or Lua would make no difference, I believe), or
doing it _in the webserver_! Webservers are most efficient delivering
static content, so it does make sense to move that decision - whether to
send some static cached file or regenerate it by running your PHP,Lua,
etc. (Fast)CGI script - to the webserver. The Lua-based CML merely
expresses the caching rules _and_ allows you to piece together
independent parts of a multi-part web page (output_include below), which
gives you another performance bonus if those parts are modified at
different intervals, i.e. have independent caching characteristics.
--Markus Walther
-- EXAMPLE index.cml for lighttpd web server
output_contenttype = "text/html"
local cwd = request["CWD"]
-- let's generate some dynamic content from within CML
local f=assert(io.open(cwd.."dynamic_content.html","w"))
-- show request and get (URL-encoded) params
f:write("<br><br>\n<b>REQUEST</b><br>\n")
for k,v in pairs(request) do
f:write(k,"=",v,"\n<br>\n")
end
f:write("<br><b>GET</b><br>\n")
for k,v in pairs(get) do
f:write(k,"=",v,"\n<br>\n")
end
-- list directory,showing some aux. functions in CML
f:write("<br><b>DIRECTORY</b> ",cwd,"<br>\n")
for file in dir_files(cwd) do
f:write("<b>",file,
file_isreg(file)==0 and "/ " or " ",
"</b> ",
"MD5 of filename: ",md5(file),"\n<br>\n")
end
f:close()
-- piece together various parts
output_include = {cwd.."static_part1.html",
cwd.."dynamic_content.html",
cwd.."static_part2.html"}
return CACHE_HIT -- no regeneration of dynamic content
-- (we did it ourselves)