Well-designed server (6)-Seda architecture notes

2007 - 12 - 21 Well-designed servers (6) -- Seda architecture notes

Blog type:
• Default category

Application Server Design Mode: webservicesoaweb1.overview

• Seda secret
• Adaptive overload control for busy Internet serversBytes
• An architecture for highly concurrent, well-conditioned Internet servicesBytes

The core idea of Seda (staged event-driven architecture) is to divide a request processing process into several stags, and stags consumed by different resources are processed by different threads, stag uses the event-driven asynchronous communication mode.

Furthermore, you can dynamically configure the number of threads in each stage, and downgrade to run (for example, output plain text pages) or reject services during overload.

The following components are usually used in each stage:

• Incoming event queue, event queue.
• Admission controller valve, DOS.
• Dynamically sized thread pool, thread pool.
• Event Handler, The compinent that actually processes the business.
• Resource Controller, which controls the parameters of stage.

2. Seda applications in the Web2.0 + SOA Environment

Web2.0 poses a new challenge to architects. Except Java EE's synchronous calling mechanism (except JMS), limited thread pools and connection pools (out-of-scope performance will decline ), the requirement for Web2.0/SOA for resources defined in JNDI is not consistent. For beep and sctp protocols, you must rely on JCA to write modules separately to implement the persistent connection model.

Java EE cater to Web 2.0 (ibm dw)In terms of statistics, given that the total number of threads in the system is fixed, the larger the resource difference between stages, the more obvious the throughput can be obtained by using Seda.
For example, to process a common mashup request for Web 2.0, take the following steps:

1. Receive user requests (1 unit time)
2. Database Query (4 units of time)
3. Prepare the Web service call parameters (1 unit time) based on the database query results)
4. Initiate a web service call (in 16 units of time ))
5. Returns the result rendering to the user (2 units of time)
   

Then Seda will use a thread for processing 1. receive user requests, 3. prepare WebService, 5. the returned result is processed by two threads. database query, while the five threads process the most time-consuming 4. webService request.
The results show that the system throughput can be significantly improved when the time spent on remote calls remains unchanged and local operations are optimized.

3. Seda instance in mule

• Using Seda to ensure service availability (infoq) Restart)

Mule is a follow-up of the Seda architecture. Each component is asynchronously connected using inbound-> outbound's queue. Each component can set its own thread pool size and queue length.

Therefore, stag in Seda is used to drive asynchronous links between events. Incoming event queue, thread pool, and event handler in stag are all available.

<Mule-Descriptor class = "code-quote" name = "& amp; lt; span"> </mule-Descriptor> "radiocarumo" implementation = "Radiocar" > <Threading-profile class = "code-quote" maxthreadsactive = "& amp; lt; span"> </Threading-profile> "5" maxthreadsidle = "10" Poolexhaustedaction = "Wait" Threadwaittimeout = "-1" Id = "Component" Dothreading = "True" /> <Queue-profile class = "code-quote" maxoutstandingmessages = "& amp; lt; span "> </queue-profile>" 6 "/> <inbound-router> </inbound-router> <endpoint class =" code-quote "address =" & amp; lt; span "> </Endpoint>" radiocarsqueue "/> <router class =" code-quote "classname =" code-quote "> </router>" org. mulefair. routing. bennythegatekeeper "/> <outbound-router> </outbound-router> <router class =" code-quote "classname =" code-quote "> </router>" org. mule. routing. outbound. outboundpassthroughrouter "> <endpoint class =" code-quote "address =" & amp; lt; span "> </Endpoint>" fairareaqueue "/>

Bytes

In the example, inboundrouter bennythegatekeeper implements the role of the administration controller. Originally, poolexhaustedaction = "wait", while the administration controller can directly refuse requests through counters to forward requests to alarm queue.

The only missing stag is the resource controller that dynamically changes the resource parameters. threadpool is not a dynamically sized thread pool, but it does not seem important.

Again, I think that mule is more competent to act as a Service container than an ESB.

Bytes