So if I get stick to the "vertical scalability"(Site has sessions), is
it gonna be helpful for performance to run Twisted reactor on a single
core machine vs multi-core machine (after all Python itself has a
Global Interpreter Lock)?
OR
the entire "TwsitedGateway+listenSSL+Site+reactor" USAG
> thank you for such detailed response.
> I feel, finally I've succeed to express my original question correctly.
>
> So if I go one step forward, and lets assume that indeed there is such
> limit of concurrent connections, THAN:
> should it be resolved by another architecture or another usage type
thank you for such detailed response.
I feel, finally I've succeed to express my original question correctly.
So if I go one step forward, and lets assume that indeed there is such
limit of concurrent connections, THAN:
should it be resolved by another architecture or another usage type of
Tw
> Once there is a Site that serving many clients and
> reactor.listenSSL(), for example, that actually serving many TCP
> connections and all these going through TwistedGateway, my logic,
> please correct me if I wrong, says at some point there will be a limit
> on concurrent TCP connections, so ho
I've get confused enough already :-))
Once there is a Site that serving many clients and
reactor.listenSSL(), for example, that actually serving many TCP
connections and all these going through TwistedGateway, my logic,
please correct me if I wrong, says at some point there will be a limit
On 03:59 pm, vit...@synapticvision.com wrote:
>
>Doesn't the event loop have a limit of connections it could handle?
Multiple reactors isn't a realistic solution to this. The solution is
to switch to an event loop that has a higher limit. "The" event loop is
actually a choice of many possible
Doesn't the event loop have a limit of connections it could handle?
Quoting "Reza Lotun" :
>> hi,
>> what would be the right thing to start from in order to build
>> multi-reactor arch to handle thousands of concurrent connections?
>
> Why would you want multiple reactors? The only reason would
On Thu, Nov 12, 2009 at 12:53 PM, wrote:
>
> You right, distributed systems architecture.
>
> Probably I need to rephrase my question more precisely: how to build
> distributed system architecture with Twisted technology only ?
>
> As you mentioned, even reverse proxy could be a another twisted p
You right, distributed systems architecture.
Probably I need to rephrase my question more precisely: how to build
distributed system architecture with Twisted technology only ?
As you mentioned, even reverse proxy could be a another twisted process.
Quoting "Reza Lotun" :
>> How reverse prox
> How reverse proxy knows to balance between couple of twistd processes?
> Do you have may be an example(or doc link) of such proxy that can
> distributing connections to each twistd process?
This is a classic distributed systems architecture. A reverse proxy
can either something like haproxy, ngi
How reverse proxy knows to balance between couple of twistd processes?
Do you have may be an example(or doc link) of such proxy that can
distributing connections to each twistd process?
Quoting "Reza Lotun" :
>> hi,
>> what would be the right thing to start from in order to build
>> multi-rea
> hi,
> what would be the right thing to start from in order to build
> multi-reactor arch to handle thousands of concurrent connections?
Why would you want multiple reactors? The only reason would be to have
one per CPU core. For that the simplest thing would be to manually
start n twistd process
hi,
what would be the right thing to start from in order to build
multi-reactor arch to handle thousands of concurrent connections?
Appreciate the help.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin
13 matches
Mail list logo
