This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Users expect “service on demand” from the Web - Bhatti et.al
Dynamic web content: On the increase – Barford et.al Much harder to scale than static content – Stading et.al Consider: Web Services (SOAP, WSDL, etc), easier to
build clients with much smaller “think times”, greater strain on scalability.
Dynamic Content Degradation: Deliver degraded version of content under load. Aim: deliver “acceptable” version to an end user that is cheaper to deliver than original. Static web images – Abdelzaher and Bhatti, Multimedia - Chandra et al. Degrading content via a distributed, tiered network -
Chen and Iyengar. As opposed to:
Dynamic Web Content Caching: Has limited applicability. Resource Management: Can deny access to unlucky majority.
A number of approaches to generating same web content (same URI).
An Approach Selector to pick which approach is most appropriate. Two parameters: lower-time-limit and upper-time-limit. Parameters act as elapsed-time thresholds. Cross a
threshold, choose a different approach. Slowest content generating approach called a baseline.
Want to answer : “How can we minimise the overhead of the application development process WRT content degradation?” Avoid JIC (Just in case) degradation. Explore JIT (Just in time). Declarative approach, mark-up code that degrades with alternatives Manual, fine-grained behaviour alteration at run-time (exploring now –
adaptable architecture based on generative communications).
Servlet engine architecture (and specification) too limiting. We desire a more adaptive architecture: Ability to dynamically alter supporting architecture and its configuration
(thread limits, etc) Ability to manually modify behaviour as load changes. Individual
(running) object replacement; objects interacting that know nothing of each other.