World: r3wp

There's no need for session affinity internally in Cheyenne, the 
session context is carried with the request to any worker process.


CGI/RSP requests are dispatched to any available worker process. 
If all are busy, a new one is forked up to the maximum number (8 
by default). If the max number of workers is reached and all are 
busy, the request is queued (the queue is global). Once a worker 
becomes available, it gets a new request assigned at once.

Btw, worker processes are not equal wrt the load. The first in the 
list gets the more jobs to do, especially if requests can be processed 
fast (which should be the case in most of well-coded scripts). So, 
you get a natural "affinity" to the first worker (having the most 
code and data cached there) for all new incoming requests. 

So, in the long run, you can look at workers memory usage to see 
how the workload is spread, the first one having the biggest memory 
usage, the last one having the lowest. Looking at the last one is 
a good indicator if the number of workers needs to be raised or not, 
if his memory footprint hasn't changed since the last restart, your 
server is doing fine with the load. I should expose some workers 
and job queue usage stats to help fine tune workers numbers.

Thanks, good to know

I do see the asymmetry on our server. I have also had cases, though, 
where the number of workers went above eight or to zero. I'm not 
sure if that is still happening with the recent version

The worker number doesn't decrease unless you're using the -w command 
line option (or unless your code or a native bug crash some of them 
badly). Having more than 8 workers is possible if some of them are 
blocked (in a endless loop or waiting something forever). If you 
quit Cheyenne in that case, they'll remain there and will need manual 
killing. Cheyenne could do a better job at handling those non-responding 
workers in future versions.

R3 is more suited for such.
secure [memory integer!] and secure [eval integer!]
Allow to quit from forever loops.
(Not from a forever loop, which does nothing, though)

And perhaps
  secure [time time!]

yeah perhaps... is there a ticket for that request ?

I I guess, Carl didn't want offer this by default, because the slow 
down may  be drastic.

I don't know if there's a ticket. I could live with relatively coarse 
granularity, which would be much better than nothing, if that at 
least made it possible.

At least a memory constraint is a good one. That should prevent memory 
leakage. I personally don't like eval at all, as my brain is not 
mature enough to be able to guess, how many cycles will my script 
ideally need. I would welcome time constraint as well, and it was 
proposed, but not accepted.

Here's what does not work yet:


# If the program quits, the exit code is set to 101, the same as 
any security termination; however, we may want to use special codes 
to indicate the reason for the quit.

# Some types of loops are not yet checked, but we will add them. 
For example, PARSE cycles are not yet counted.

# Time limits are not yet supported, but may be added in the future. 
However, the cycle limit is better for most cases, because it is 
CPU speed independent.

You can quit/return any exit code

It's about automatic quits by the SECURE functionality

yeah, and you can catch it as an error. It stay relevant.

Yeah, but you can't analyse the error, because you always get 101

Are you sure ? accordingly the doc, we got :

>> secure [eval [throw 50000]]
>> loop 100000 [next "test"]
** Access error: security violation: eval
** Where: loop
** Near: loop 100000 [next "test"]


So, you can decipher the error message and send back the appropriate 
quit/return code

security violation: eval

You can also do it in a try statement and check the error codes.

Ah, seems this limitation only applies then if you let R3 quit without 
further processing

Bad news - looks like WebSockets will be disabled in Firefox 4 due 
to security concerns.


http://feedproxy.google.com/~r/Bludice/~3/S6Lw15UdA2I/websocket-security

Same in Chrome: http://codereview.chromium.org/5643005/

Aargh

I saw the news yesterday for FF4. The badly written RFC for ws was 
alarming since the beginning, this kind of design defect doesn't 
surprise me much, but it's such a waste...I hope the new CONNECT-based 
workaround will be adopted rapidly.

Google can't hire designers as good as work for REBOL for free ;-)

When can we exepect Cheyenne like NGINX ? What is missing ? Cheyenne 
is the best product to promote REBOL !?

Why? I'm using Cheyenne with Nginx... Nginx for serving static content, 
dynamic by Cheyenne. I use slogan:  "when east meets west".

Ok,  they claimed that "Nginx now hosts nearly 6.55% (13.5M) of all 
domains worldwide."
When for Cheyenne ?

There's a possibility that users might require certificates to access 
my app ... can that be done with Cheyenne and something else?

Client certificates?

So, what would you have to use server side to manage and authenticate 
the certificates?

Sorry, that was a question, not a suggestion. Do you actually want 
to authenticate based on client certificates?

Yes

Use SSL: http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500

Or use Nginx as a reverse proxy to Cheyenne.

So, I don't need Apache then?

I'm currently using Cheyenne ... and stunnel to provide SSL

Looks like I could still use stunnel .. and put all the certificates 
in a directory and disconnect users who don't present a certificate

I might have a few hundred users ... so hopefully this can cope.

So, I guess I'm asking if anyone has experience with this and was 
it straight forward?

Hundred users total, or concurrently?

total

I'm looking to implement a nationwide registry for patients taking 
biologics

Shouldn't be much of a problem performance wise

worst case scenario - 60 concurrent users

How many requests would they make within a minute?

I wouldn't have thought that many ... of course I'm just guessing!

Well, that determines your scalability concerns

60 Concurrent users is a lot - except if they're idling for five 
minutes between every request

I guess I can just get a bigger VM if it comes down to it ... :) 
 Yes, I expect they'll be idling most of the time

So, I guess the next question is .. how does one determine if the 
server is overloaded?