World: r3wp

here's my default function.. 

  default: func [req params svc][
    raw-input: trim req/in/target
	if raw-input = ""[raw-input: "index.html"]
	qstr: make object! decode-cgi to-string req/in/content 
	bout: copy ""
	requesttype: "http"
	commander
	bout		 		
  ]
]

I want to pass the params to the commander function

Yeah.. I forgot .

commander params

where's the issue ?

Oops.. I went commander[params]

hilarious

Read http://www.rebol.com/docs/core23/rebolcore.htmlbefore posting 
here again! ;-)

What I need is a PHP lobotomy

PHP is bad, look at what it did to you :-)

I feel so dirty. *sob*

I've wrapped up the latest Cheyenne source code, binary and my web 
to fax gateway in on file

one file .. see http://rebol.wik.is/Hylafax

It's a little rough .. but it works.  Needs some graphical enhancements.

Nice work.

How about making it a Rockstar module?

doc, your website has 0.9.18 but I seem to have 0.9.19 ...

0.9.19 has been officially released yet.

has => hasn't

oops

Graham, that's not a problem.

whew

I've released it as beta and posted the download link here, so main 
Cheyenne's users already have it.

Nenad, if I run Cheyenne, then do something like this... (on a newer 
XP box)

a: 1000
while [a > 0][read http://mydomain.com/a: a - 1]


It blazes along fine.. but gets about half way.. then just stalls.. 
waiting.. then further results will just trickle in.. stall.. a few 
more .. etc

Why?

Memory and CPU are hardly touched?

some security limiter of XP to prevent DoS attacks?

check your system event log

http://www.mydigitallife.info/2005/11/15/windows-xp-sp2-tcp-connection-limit-event-id-4226/

I was thinking it may be the ISP throttling to prevent DoS ?

but it's from the same box.

It's not a concurrency issue, READ is blocking, so just one connection 
at a time. I run the same test here (XP-SP3) several times, no problem. 
AFAIR, the same test was running just fine on SP2.

why would my READ block, and not yours?

Would it be an embed issue?

Cheyenne has an async kernel.

Are you running your test in the same process as Cheyenne ?

no

R2 port behaviour is blocking by default.

ahh.. so you didn't test with R2?

I've tested with Uniserve to achieve concurrency and with Apache's 
ab testing tool.

I didn't see it as a big issue.. served up 500 pages in a few seconds.. 
just wondering why?

Check your OS's TCP parameters.

I built a little Memcached system if you're interested.

What are the features of your memcached system ?

It's a cache (block!)of key/value pairs.. the query is turned into 
a checksum, and compared against cache, if it matches, and the expiry 
hasn't expired, it returns the value rather than calling the DB. 
 If the key isn't found, or has expired, then it pulls the query 
from the DB, and stores it in the cache.

The cache is stored in memory.. so blazing

I've set it up to use my AtomDB.. but could be quickly tweaked for 
SQL

The checksum is the key
key: checksum trim thequery

Another feature, if the cache is hit, then the key, value and expiry 
is cut, and inserted into the front of the cache.. making the most 
popular queries at the very beginning of the block.  The less used 
queries will eventually pop off the tail as new queries are added. 
Although I haven't finished that last bit yet.

I already use such memcache system in Cheyenne's RSP engine (but 
duplicated in each RSP process). Using a single server would reduce 
the memory usage but I would loose RSP's DB connection pooling and 
parallel queries advantages.

My memcache is slective, it only caches the queries declared by user, 
not all queries. The MySQL backend that I use already does a good 
job at general query caching.

selective

Im using this one a little differently .. I have a central repository 
of code that runs the framework. When you fire up a copy of the framework, 
it pulls only the pieces it requires to run from the repository, 
and loads into memory. So it automates any code updates, gives a 
massive performance boost as it's in ram, and provided terabytes 
of reusable code, images, js, css etc.

Another local ram-based AtomDB handles user specific data.. and this 
is saved in a rather unique flat file system.