[erlang-questions] MySQL cluster - MnesiaXXL
Tue Oct 24 00:26:24 CEST 2006
> Zeus is certainly faster than yaws on static content - a lot of web
> are. I do however have a really hard time to believe that any web
> server is
> faster than yaws on dynamic content.
Zeus do all its cooking in kernel space and reduce to the max context
switching between user and kernel space.
You can't go faster than that. It's simply impossible Claes.
Add whatever you want to Yaws, and do it for years, you'll never reach
kernel space speed. Sorry for this bad news.
> Yaws has the dyn-content producer so tightly integrated inside the
> actual web server so in order do better than yaws on dynamic content
> we would have to
> 1. implement in C
What's the problem with C?
Erlang is in C?
Unix(-like) are in C?
Even Plan9 is in C (almost)? Do you know anything better than Plan9?
Any good thing is in C and after that in Erlang ;-)
I've no objection against C. It's a problem for people comming from very
high level languages without good OS/compiler knowledges. Our team (very
little team, just 2 motivated persons) developped a C API with a
complete OOP style support. We have classes, inheritance, composition,
exception handling, objects persistence, and ultra optimized set of data
Our moto is simple: "optimize for small size" (nothing more than 10Kb).
Ah I forget the main component, our memory manger (~600 bytes). With it,
we can allocate more than 200M objects per/sec in very very cheap today
machine (~0 cache misses).
It's almost the perfect language (after Fortran 66* of course ;-) see
> 2. do not use OS thread, use event loop + state machine
Yes, never use OS thread. I'm using libevent instead. For state machine,
I'm using a stacked st.
> 3. integrate dynlanguage (php ??) inside the web server loop
> and precompile (JIT) the php pages
No, not necessary in my case. Using so high level language will
introduce unpredictable behaviours.
> 4. Write a proper php compiler which produces assembly code.
> (and even worse - if we compare to the yaws_api:ehtml_expander
> which is a small partial evaluator which is built into the
> HTML producer. It's not especially easy to use and few people use it
> but it is worth the effort when we want to squeeze those extra cycles)
I agree with you Claes.
What I want to explain is simple. Using a generic API could perform
well, but using a specific, thighted API is the best when you're looking
for maximum performance.
* Fortran 66: if you can read in French, see:
More information about the erlang-questions