World: r3wp

This is fine.  just need to grok the system better.

That helps alot, thanks

Graham: still no crash on your server

true

(sorry, wrong channel)

I reduced the number of javascript elements on the page.

I'll put them back and see if it happens again.

One last question for now if you don't mind.. sending a response 
back to the page.. .. is this correct?
req/out/content: "test"

Do you have a really basic make-response function?

yes, but you have to set the res/out/code (HTTP response code as 
integer! value)

Here's what I have.. 
install-HTTPd-extension [
	name: 'mymodule

	order: [
	url-translate first
	make-response first
	]
	
	url-translate: func [svc req conf][	
	;probe svc/client/remote-ip
	none
	]
	
	 make-response: func [svc req conf /local res sess][
		if all [declined? req none? req/app][return none]	
	req/out/content: "test"
return true	
		 
	]
	
]

req/out/code

lacks : req/out/code: 200

and delete the : if all.. line

Eureka!

this line is for testing in mode-rsp/make-response if the request 
should be processed by mod-rsp or not.

That should be Rebol's new name ;)

Agreed ;-)

That's great..   so very extensible.. I have a really basic core 
Chyenne, and can add mods as I go..

Well, I guess it's good as it's not crashing now.

I wonder if it was because I had some paths wrong to the javascript 
libraries ...?

Trimming out the extra modules really sped things up.. doing 1000 
localhost page hits in < 9 secs

Would that kill the rsp engine if it tried to include non existent 
libraries?

Cannot make it crash whatever I do...Anyway, if you can reproduce 
the problem, I'd like to know what caused your error.

humm, good question :-)

might be the cause, let me try that

I originally had relative paths .. but the Yahoo libraries were above 
the webroot

so, I switched then to using absolute paths to Yahoo itself

I wasn't sure if rsp would allow me to include outside the webroot

currently, there's no restriction on that, but I have to sandbox 
those include functions.

Hmm  ..that's not correct.

Oops.. that was < 9 secs with vv debugging on.. turned off it was 
< 4 secs

rsp would include the file correctly, but the generated page would 
reference libraries outside the webroot

Tested here, seems ok, I got an RSP catched error telling me that 
the file is not found.

I'll play some more and see if I can reproduce .. though I would 
prefer not to see more errors :)

Ran 3 scripts concurrently doing 5000 page reads each  .. all 3 finished 
around 33 secs.

Any idea on concurrent user limits?

I've done some stress test on a previous version of Cheyenne, it 
was sustaining around 500 concurrent connections on static pages 
requests. (RSP have a limitation of  <500 due to a design bug in 
task-master. This bug will be fixed in a few days).

I need to do more stress tests on that to publish officialy Cheyenne's 
performances.

Btw, the testing tool was written in REBOL, it may have some bugs. 
I'll do more serious testing using third-party stress test tools.

sessions: Is it possible to add a cookie-free session handling by 
adding a session ID to the URLs?

I like the way I can omit many print statements by escaping out of 
the rsp as follows

<%

 qry: rejoin ["select age, diagnosis from diagnoses where patient 
 = " session/content/uid ]
	sql: do-sql 'remr qry
	if not empty? sql [
		%> <table border=1><tr><th>Age</th><th>Diagnosis</th></tr> <%
		foreach record sql [

   %> <tr><td> <% prin record/1 %> </td><td> <% prin record/2 %> </td> 
   </tr> <%
			response/flush
		] 
		%>
		</table> <%
	]
%>

Robert, you can still track the sessionid

or, does that need cookies???

Not that I know about. But I have to do it myself, right?

Or is there an option for RSP to use cookie or session-id?

try turning off cookies and see if the session id is preserved

I would guess not

Graham: instead of writing <% prin record/1 %>, you can use the following 
syntax : <%= record/1 %>

Session currently only use cookies. The session ID is available (session/id) 
so you could embed it in urls, but session cookies support is hardwired 
in the RSP engine, so it would require a lot of internal changes 
to not rely on cookies.