World: r3wp

Doing a quick ('n dirty) benchmark..

dock, is the rebcode test version of rebol compatible with cheyenne?

(sorry, I meant 'doc )

Marteen: I'll add a small Database abstraction layer for RSP: so 
I'll include both mysql and pgsql drivers once this feature added.

Rebcode: don't know if it's compatible with this kernel version, 
didn't tried.

I'll add a remark module for it  :-)  its adds dialected tags to 
html, sort of a functional approach to web.

Running Apache and Cheyenne on my IPOD nano.. 

Using a simple rebol 'read'' loop (10,000 hits) to a 4kb static page 
(localhost).

Apache - 1:41
Cheyenne - 0:52

Graham: you did a very good job with your WebMail. I wish the new 
RSP API and features would allow you to finish the work and release 
it !

cheyenne nearly twice as fast

Good news! Thanks Terry !

does cheyenne handle http 1.0 and 1.1 transparently (expecting yes, 
but need a specific answer)?

But a more elaborate benchmark may show closer results between these 
too. Size of files and OS have big impacts on the results.

1.0 & 1.1 : yes

dockimbel, I assume the benchmarks improve when caching is used?

but not exaustively tested yet. The unit tests are still under development

Caching is on, by default, for files < 16kb

another testapp bug.. now the 16RSP won't fire, sends me back to 
login (previous error message is gone, and works fine with 4RSP)

Ok, working now.. had to clear the cookies

Sessions are not yet completly stable.

does fast-cgi need /command license?

No, it's a client implementation of my own (/Command implements a 
server-side FastCGI protocol)

Terry: this bug has been noted and will be fixed in next release.

thanks... so far, if everything works without bugs, I think you just 
made yourself a new user, I'll be testing it tomorrow.

HTTP support is stable, CGI are ok, RSP too, just avoid sessions 
for now. Next release will bring a complete rewrite of the session 
support for faster and more stable behaviour.

hum... there is one thing I am not sure I get, what do you mean by 
"server-side" (do you imply your's is not, and if so what does that 
really mean?)

session support is still buggy ??  not what I wanted to hear :(

doc, what timeframe between releases? days, weeks, months?

Any php examples?

I should be able to make small releases each week (mainly bugfixes) 
and release monthly new features. It's the rate of release that I've 
doing since a year now (for a few ppl and customers).

Terry: Any php script would work, you just have to connect a php 
exe compiled with fastcgi support. I'll give more info on how to 
setup such config once the fastcgi module will go beta. I plan to 
bundle a php exe with the binary Cheyenne with no setup needs for 
end user.

Terry, how do you run Cheyenne on an iPod?

'from' would be a better term

the ipod acts as a HD

Ah! ok 8)

Graham: yes it still has some issues, that's why I'm working on a 
new implementation that should fix all problems. That's my first 
priority for Cheyenne.

Session support would have been so much more easier to add if REBOL 
had multithreading...

Doc: is sessions support not very easily added if you do it from 
the db-abastraction layer. Much more scalable as well

Marteen: the main issue is more about synchronization between 2 or 
more REBOL processes to avoid the modification of the same session 
data at the same time...

Storing session data in a DB might be an interesting solution, but 
it will be slower than the current native approach.

I've setup a Blog for Cheyenne by adapting Carl's one : http://softinnov.org/cheyenne/blog.cgi

memory resident db ?

Carl's blog needs a way to implement emoticons !

:(

Rebol is alive... again :)

Graham: good idea, I already wrote REBOL code to support emoticons 
in another project. I'll add it to the blog. (Note to myself : The 
link to Carl's blog source code disapeared in our blog template file, 
I have to put it back!)

Memory DB: even in memory if you count the overhead of a SQL layer 
+ storage layer, it would still be much slower than direct storing 
of data in a REBOL block! or hash!.

Doc: I know, but I also read the RubyOnRails book where they measured 
all this. A database scales better, and for low usage the performance 
hit you tahe is little. Files/memory is faster but collapses pretty 
soon, MySQL runs with constant overhead (and little enough, I might 
add). It is more a question of balancing performance with different 
load scenarios.

http://en.wikipedia.org/wiki/Comparison_of_web_servers
Cheyenne missing here :)

I was using rebol blocks to store greylisting data ...

However after a few hundred thousand greylisting entries .. it started 
to collapse a little.  I should have gone db ...