A little heads up 10

Posted by icy Tue, 02 Dec 2008 22:36:00 GMT

Hey folks,

back in july, I posted about a new lighty branch we planned on creating. A complete rewrite with a new core design. There haven’t been any posts since then about it and you might wonder if it lead to anything.

Well, roughly 4 months, 256 commits and 14 thousand lines of code later, we are at a point at which we have something to show you. We just opened up our project in redmine to the public: http://redmine.lighttpd.net/wiki/lighttpd-sandbox
You can take a look around and browse the source.
We call it “sandbox” because there is one thing we want to really stress: it is not in a useable state yet. Boards as well as ticket/issue tracking have been disabled for it because we are not capable of providing any support at this point.
I repeat: NO SUPPORT FOR SANDBOX
So what state is it in exactly?
  • the config handling is pretty complete
  • basic connection handling including throttling and keep-alive/IO timeouts works
  • error logging works (introducing multiple error log levels and targets)
  • module/plugin interface mostly done
  • completely multithreaded
  • serves static files

I am currently working on the new mod_accesslog. It is already capable of what the 1.x version can but I wanted to expand it a little bit.
A feature that might be quite usefull: have different log formats and targets depending on the status code of the request. This way, you can for example log all request resulting in a 400 or 500 to a special file with addition information you would normally not log.
But I have trouble finding the right way to express that in the config in a good way. This is the perfect moment to get you users out there involved. I’d really like to hear your suggestions so please leave a comment with your ideas. Take a look at the config documention in the sandbox wiki to know what you can use.

A lot of work has been done and there is even more still ahead. It really takes a lot of time and hopefully it will pay off some day.

So much for the bleeding edge part. About 1.x:
There will probably be a 1.4.21 (pre)release soon. Watch out :)
We really would appretiate if more users would test our preleases and report back to us if they find any issues. It’s crucial in order to bring you well-tested and stable releases.
A thank you to all the people who did this in the past at this point!



This is it for today.

Thanks for using lighty.

Comments

Leave a response

  1. mOo Wed, 03 Dec 2008 06:52:03 GMT
    keep on good work
  2. Jan Berger Wed, 03 Dec 2008 11:13:00 GMT
    oh i'm excited about the new branch. will it include lua as the new config language?
  3. akrus Wed, 03 Dec 2008 14:24:16 GMT
    woohoo! that's great! maybe i'll test it some day :) pleeeeeaaaaase add ticket #1288 to 1.4.21, really waiting for it :) Thanks for lighttpd!
  4. ls Thu, 04 Dec 2008 21:01:56 GMT
    thanks for posting and the update, good to hear lighty is still on the move upward and forward. happy to roll out the pre-release and put it through its paces on some high traffic sites for a day or two when you're ready.
  5. happy_complainer Fri, 05 Dec 2008 14:49:36 GMT
    i would be happy if lighttpd developers concentrate more on performance aspect of their webserver because its used mostly because of performance
  6. icy Fri, 05 Dec 2008 18:00:00 GMT
    Jan Berger: partially, it has a frontend for lua so you can write a lua script that is then executed and transformed into the internal byte-code style representation.

    ls: thanks!

    happy_complainer: of course performance is one of the key aspects of lighty. We cannot talk about benchmarks yet but it seems like it will scale even better than the 1.x branch - especially with multicore/multicpu machines because it is fully multithreaded now and we took effort to avoid locks. There are also better algorithms in place which should pay off if there are lots and lots of connections.
  7. jsmith Mon, 15 Dec 2008 19:40:50 GMT
    I'm personally do not care about Lua language (wtf config file should be a programming language at all?) but I do care about performance, flexibility and software support.And lighttpd mostly used in 2 cases: 1) Heavily loaded systems like file sharing\distribution\mirroring services. 2) Resource constrained installations like VDS\VPS servers, embedded devices and so on. Actually very few people needs complicated stuff in config file and after all someone with non-standard needs can write it's own module. P.S. local linux mirror of "Yandex" company uses lighttpd 1.5 :).That's funny since this is one of the biggest mirrors around.This proves Lighty can cope with a DECENT loads.
  8. icy Tue, 16 Dec 2008 01:49:51 GMT
    jsmith: yep those two usecases are indeed what lighty is written for. But also for small personal webservers that people can set up fast and easily.

    So there are three main goals:
    - perform well under high load
    - consume as few resources as possible
    - be easy to set up

    In sandbox there is another goal added while keeping the others:
    - be more flexible
  9. brok Wed, 17 Dec 2008 17:57:15 GMT
    @icy: I guess that an easy setup is the most cruciable point for the success of lighty. Maybe you can include a setup routine as it exists for Apache in the form of XAMPP. In general: You are really responding to market needs by offering an alternative to apache that uses few resources. Keep going! I will try out your releases.
  10. jsmith Thu, 25 Dec 2008 14:54:21 GMT
    So there are three main goals:
    > - perform well under high load
    That's why I'm using it. I have a half dozen of installations on VDS environments (mostly OpenVZ based) and some NAS and router devices (mostly WL-500GP routers and QNAP NAS boxes, see wl500g.info to get idea where lighty used sometimes :D). On VDS more RAM means more moneys if I'm using hosting or it means fewer containers if I own hardware server. So with Lighttpd virtuzlized and resource-limited environments are really perform better.

    >- consume as few resources as possible
    As for me this is important too.

    >- be easy to set up
    As for me, this is less critical. These who want EASY and LAME setup will fing GUI-based servers for both Windows and Linux. However while providing neat GUI and simple setup these servers are neither can cope with any serious load nor they can offer advanced stuff like *CGI interfaces or whatever else. You can't beat these by ease of setup. But anyway, I preferred lighty over nginx due to more simple setup, better documentation and CGI\SCGI support

    >In sandbox there is another goal added while keeping the others:
    - be more flexible
    As for me, I only have few wishes: do not buffer CGI output totally in RAM, make a good use of multicore CPUs where available but do not became Apache No 2 (or there will be no clue to use it instead).Though flexibility is a good goal. If this does not means bloat and speed penalties.
Comments