test engineer will set up several computers running httperf against the staging

Test engineer will set up several computers running

This preview shows page 449 - 451 out of 502 pages.

test engineer will set up several computers running httperf against the staging site and gradually increase the number of simulated users until some resource becomes the bottleneck. E LABORATION: Longevity bugs and rolling reboot Stress testing can also expose bugs that only appear after a long time or under heavy load. A classic example is a resource leak: a long-running process eventually runs out of a resource, such as memory, because it cannot reclaim 100% of the unused resource due to either an application bug or the inherent design of a
language or framework. Software rejuvenation is a long-established way to alleviate a resource leak: the Apache web server runs a number of identical worker processes, and when a given worker process has “aged” enough, that process stops accepting requests and dies, to be replaced by a fresh worker. Since only one worker (1∕n of total capacity) is “rejuvenated” at a time, this process is sometimes called rolling reboot , and most PaaS platforms employ some variant of it. Another example is running out of session storage when sessions are stored in a database table, which is why Rails’ default behavior is to serialize each user’s session object into a cookie stored at the user’s browser, although this limits each user’s session object to 4KiB in size. Summary: As with testing, no single type of monitoring will alert you of all problems: use a combination of internal and external (end-to-end) monitoring. Hosted monitoring such as Pingdom and PaaS-integrated monitoring such as New Relic greatly simplify monitoring compared to the early days of SaaS. Stress testing and longevity testing can reveal the bottlenecks in your SaaS app and frequently expose bugs that would otherwise remain hidden. Self-Check 12.5.1. Which of the following key performance indicators (KPIs) would be relevant for Application Performance Monitoring: CPU utilization of a particular computer; completion time of slow database queries; view rendering time of 5 slowest views. Query completion times and view rendering times are relevant because they have a direct impact on responsiveness, which is generally a Key Performance Indicator tied to business value delivered to the customer. CPU utilization, while useful to know, does not directly tell us about the customer experience. The idea behind caching is simple: information that hasn’t changed since the last time it was requested can simply be regurgitated rather than recomputed. In SaaS, caching can help two kinds of computation. First, if information needed from the database to complete an action hasn’t changed, we can avoid querying the database at all. Second, if the information underlying a particular view or view fragment hasn’t changed, we can avoid re-rendering the view (recall that rendering is the process of transforming Haml with embedded Ruby code and variables into HTML).

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture