Just to clarify, Java server side implementations (Servlet) usually assign one thread for each connection (plus any necessary additional threads for asynch processing). So in the given example carla would not be blocked while peter's request is being processed.
Also note that forking an additional process is much more expensive resource wise (and slower) than forking a thread. That's why Java servlets are much more efficient than CGI/ASP (although ASP.NET resolves this with threads and compiled pages - aspx). Just had to jump in here, being a Java advocate and all. Rebol 3.0 sounds cool! Michael -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Petr Krenzelok Sent: Monday, April 29, 2002 3:18 PM To: [EMAIL PROTECTED] Subject: [REBOL] Re: Google + SOAP 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- -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
