Additionally, determinism may also become
a problem, especially in complex systems where internal server concurrency may lead to
unpredicted behavior. In those cases, a simple approach could be to execute client requests
sequentially, but then performance might decrease notably. Another performance problem
appears on write operations, which need to be multicast with strict ordering, a communication
mechanism much less efficient than conventional multicast. Additionally, recovery has to
be complemented with application-specific state transfer code if simple copy commands do
not suffice, and finally, application-specific configurations should be provided to optimize
read operations, which in some cases could be complex to analyze.
The key element in the architecture is the request manager. It is responsible of selecting
which actions should be multicast; it has to build the bridge between clients and Web applications,
and many points of inefficiency could appear in simple designs. Some effort should
be placed into its configurability and its relation with recovery actions, but significant effort
should be placed to design the component to allow most operations to proceed concurrently
without ordered multicasts.
Pages:
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579