(RADIATOR) threading

[Andy De Petter]

Hugh Irvine wrote:

>
> Hello Andy -
>
> How is threading different from using a "front-end" instance of 
> Radiator and multiple "back-end" instances?
>
> Indeed in my consulting work I very often find that using a 
> "front-end" pre-processing instance to sort the incoming requests 
> before forwarding them to dedicated per-service "back-end's" is very 
> often a much more useful approach.
>
> And as mentioned, a really fast SQL database server running a well 
> tuned database is almost always the most important factor by far.
>
> In truth we would rather spend time working on Diameter (which 
> tentatively will include threading).
>
> Also note that these days its usually cheaper to just throw hardware 
> at these things anyway.
>
> regards


I'ld rather see the combination fo both. ;)

You may add as many backends as you wish, but you can only handle 
(number of backends) requests at once.  While you could have (number of 
backends x number of threads) requests at once, with threading model.

There's a lot more potential to find there, rather than multiplying the 
backends, to increase the number of requests you can handle 
simultaneously.  I'm fully aware, that most of the time, the problem is 
the database, but once you've found a way to scale that one too (by 
master-slave model for example), you want to do more requests 
simultaneously .. which in my opinion can be most optimal, by having 
multi-threaded processes, running on multiple backends. ;)

At this time, I've scaled radiator with hardware load balancers, which 
redirect to multiple radiator servers... but *jumping up and down* I 
want multi-threading :p

A

-- 
Andy De Petter - andy.de.petter at skybel.net - MSN: andy at belgacom.net
Belgacom ITN/NTA/NST - Carlistraat 2 - 1140 Brussels (Belgium)
Tel +32 (0)2 7248116 - Fax +32 (0)2 7248111 - ICQ  #1548957
  "Cogito Ergo Sum - I think, therefore I am."
                                                -- R. Descartes
*** DISCLAIMER ***
This e-mail and any attachments thereto may contain information, which
is confidential and/or protected by intellectual property rights and
are intended for the sole use of the recipient(s) named above. Any use
of the information contained herein (including, but not limited to,
total or partial reproduction, communication or distribution in any
form) by persons other than the designated recipient(s) is prohibited.
If you have received this e-mail in error, please notify the sender
either by telephone or by e-mail and delete the material from any
computer. Thank you for your cooperation.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3322 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.open.com.au/pipermail/radiator/attachments/20041026/351cc661/attachment.bin>