[REBOL] Re: Google + SOAP
From: petr:krenzelok:trz:cz at: 29-Apr-2002 21:18
Andreas Bolka wrote:
>Sunday, April 28, 2002, 2:25:04 AM, Petr wrote:
>
>>Christian Langreiter wrote:
>>
>>
>
>>>But there has not been an answer on my high-performance server
>>>quetsion yet - I just don't hope because there isn't any ;-)
>>>
>>>
>
>>You haven't answered why you consider Rugby being blocking one ;-) I
>>tried Ruby several times and it does some 250 RPC echos in a sec ...
>>So, what is enough for you? :-)
>>
>>
>
>i think chris' considers rugby beeing no option as it is not able to
>accept a concurrent call while it is processing one.
>
>250 echo (!!!) calls / sec might be fine, but as soon as the funcs
>beeing called actually do something, you'll never get there ;)
>
>consider the following: we have two clients, let's call the peter and
>carla and we have a server (a rugby server) which exports a func
>called 'long-running-func'. to produce a result, this func takes 10
>secs at average.
>
>peter calls long-running-func on server.
>1 sec later, carla tries to call long-running-func on server too, but
>rugby is not able to accept calls in this stage.
>
>carla has to wait the average 10 seconds until peter's call finished.
>only then her call gets processed!
>
>chris' original question:
>
>>"What is the "official RT way" to write high-performance, concurrent
>>servers in REBOL?"
>>
>>
>
>the concurrent is the key!
>
>[maarten, no offense intended! i don't want to imply that this
>behaviour is rugby's fault]
>
No, it isn't Rugby's fault, sorry :-) Your scenario is of course
correct, but replace Rugby and Rebol by Java, etc. - it's just the same.
If some func takes 10 sec, then it takes 10 sec. Maybe using Java, it
will be faster, but still blocking.
So, what is the solution, what are implications?
1) I know where you are trying to point maybe - is that threading? Well,
you don't need threading to help solve it - you can launch separate task.
2) It is quite normal, that if something is blocking, you will want to
create proxy like scenario - so main Rugby process listens to requests
and chains them to another e.g. already pre-run Rugby processes, which
will do the job. Once finished, your proxy will be noticed, and can
transfer the result back to the user.
3) each request can wait for quite some time and even OS can help you
(backlogging). The bad thing with Rebol is, that we can't influence tcp
connection oppening/closure phase, which is still blocking, but it will
change with Rebol 3.0, where we will get fully async protocols
4) Even Rugby has threads. If you write your function in clever way (but
I expect it being rather difficult), you could accomplish concurrent
calls to one function at "one time"
5) Rugy is blocking while writing to the port, but even this can be
solved ...
6) Ppl should calm down sometimes :-) Do you want to run server being
accessed by 10 ppl a sec, so generating 600 request per minute?
7) Have you ever tried Rugby? :-)
Cheers,
-pekr-
