replace loop to find unuseed client with stack?

[Larry]

Ry -

hi - I've been giving ebb a try and I like it quite a bit. I love
programming in ruby, but it is very slow. I really like the idea of
making the things that happen all the time very fast, and only
invoking ruby for actual dynamic content.

With that in mind, and an eye towards maximum scalability:

1) In the on-request(.) routine, where you're searching for the next
available client, this loop could take quite long - the higher the
load, the longer it could take. Why not add a stack to hold available
clients (just their index)?

2) A question about keep-alive. What happens if the browser requests
keep-alive, but then the user never sends another request? I know
there are timeouts and such, but I didn't specifically see anywhere
you close an open/in-use client socket if there is no request for a
certain period.

3) Along the lines of 2), if a client socket is waiting for more read
data or another write buffer, and it doesn't get it for some time, can
you timeout and close the socket (send some sort of error back to the
user)?

4) It would be really nice if ebb supported some sort of simple in-
memory caching. I know lots of people use memcached, but that is kind
of a heavyweight solution in my mind - lots of copying across process
boundaries.

Thanks.

Larry Lewis

[c_r]

> 4) It would be really nice if ebb supported some sort of simple in-
> memory caching. I know lots of people use memcached, but that is kind
> of a heavyweight solution in my mind - lots of copying across process
> boundaries.

this sounds outside the scope of the HTTP server that is ebb

but im curious anyway. can you describe the scenario in more detail?

in element [1] everything ever generated by the 'framework' is written to a file

so anything that has been requested before just conks out after an ETAG matches

and anything that doesnt is a simple open(). the kernel caches the commonly opened files in RAM. and of course if you use a SSD, its almost in RAM already

so im wondering if this caching stuff is really necessary to bother with, as a developer anymore

[1] http://element.rubyforge.org

>
> Thanks.
>
> Larry Lewis

[ry]

Hi Larry,

> 1) In the on-request(.) routine, where you're searching for the next
> available client, this loop could take quite long - the higher the
> load, the longer it could take. Why not add a stack to hold available
> clients (just their index)?

it could be optimized - but looping through a thousand integers is
extremely fast. it's definitely not the number one thing in ebb that
needs to be fixed now :)

> 2) A question about keep-alive. What happens if the browser requests
> keep-alive, but then the user never sends another request? I know
> there are timeouts and such, but I didn't specifically see anywhere
> you close an open/in-use client socket if there is no request for a
> certain period.

for keep-alive connections, user-agents close connections after
they're done with them. otherwise it times out.

> 3) Along the lines of 2), if a client socket is waiting for more read
> data or another write buffer, and it doesn't get it for some time, can
> you timeout and close the socket (send some sort of error back to the
> user)?

this happens. i think the default is 30 seconds.
The timeout can be changed with EBB_TIMEOUT in src/ebb.h

> 4) It would be really nice if ebb supported some sort of simple in-
> memory caching. I know lots of people use memcached, but that is kind
> of a heavyweight solution in my mind - lots of copying across process
> boundaries.

yes, this would be very useful. I'd rather keep ebb simple and focused
on socket processing, but it can be used a general library in which
one could implement such a thing.

Off Topic Advertisement: I'm working on a caching server - which does
require copying across processes - but is a bit more web-oriented than
memcached. It is slightly more than key/value data storage:
http://github.com/ry/caching-service/tree/master


ry

[Larry]

Ry, c_r -

relative to caching, etc:

I agree that solid state drives are about to change lots of things,
and hopefully simplify some of the programming we do. Kind of like all
the games we had to play when we only had 640k of main memory. But...

Current SSD's have about a half millisecond seek time and a 120mb/sec
transfer rate. Main memory has essentially 1 microsec seek time (the
instructions necessary to find something) and at least 800mb/sec
transfer rate, so we're still talking an order of magnitude
difference. Of course, there's always fusion-io (if they ever ship).

Whenever there's at an order of magnitude difference AND the caching
memory is relatively cheap, it may make sense to cache, IMHO. If you
look at how many time a typical website has to actually generate new
content, it's relatively infrequent. But it's often not the whole page
that's the same, just most of it. So some elegant way to do "fragment"
caching would be neat.

Ry - I haven't looked at your caching server, yet - but I will -
thanks for telling me.

Larry