[erlang-questions] MySQL cluster - MnesiaXXL

[Yerl]

Hi guys!

> Zeus is certainly faster than yaws on static content - a lot of web 
> servers
> 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 
structures.
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 
note below)

> 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.

Note:
* Fortran 66: if you can read in French, see:
  http://www.systella.fr/~bertrand/veritable.html

cheers
Younès