Web容量规划艺术：提高网站性能和可扩展性

5星 · 超过95%的资源需积分: 35 102 浏览量更新于2024-07-27 1 收藏 3.57MB PDF 举报

Web 容量规划的艺术 Web 容量规划是指对网站或应用程序的性能和可扩展性进行规划和优化，以满足不断增长的用户需求和业务需求。该领域涉及到多个方面，包括服务器配置、网络架构、数据库性能、缓存机制、负载均衡、内容分发网络等。作为一名经验丰富的 IT 工业大师，我将从以下几个方面对 Web 容量规划的艺术进行详细的解释： 1. 服务器配置：服务器配置是 Web 容量规划的基础。服务器的配置将直接影响网站的性能和可扩展性。服务器配置包括选择合适的服务器硬件、操作系统、应用服务器软件、数据库管理系统等。例如，在选择服务器硬件时，需要考虑 CPU 的处理速度、内存大小、磁盘存储容量等因素。 2. 网络架构：网络架构是指网站或应用程序的网络结构设计。良好的网络架构可以提高网站的性能和可扩展性。网络架构包括选择合适的网络协议、设计网络拓扑结构、配置网络设备等。例如，在设计网络拓扑结构时，需要考虑网络的可扩展性、可靠性和安全性等因素。 3. 数据库性能：数据库性能是指数据库管理系统的性能和可扩展性。良好的数据库性能可以提高网站的整体性能和可扩展性。数据库性能优化包括优化数据库设计、优化 SQL 语句、配置数据库参数等。例如，在优化数据库设计时，需要考虑数据库的 normalize 设计、索引设计、数据存储结构等因素。 4. 缓存机制：缓存机制是指使用缓存技术来提高网站的性能和可扩展性。缓存机制包括页面缓存、对象缓存、查询缓存等。例如，在使用页面缓存时，需要考虑缓存的生命周期、缓存的存储位置、缓存的刷新机制等因素。 5. 负载均衡：负载均衡是指使用多个服务器来共同承担网站的流量，以提高网站的性能和可扩展性。负载均衡包括硬件负载均衡和软件负载均衡两种方式。例如，在使用硬件负载均衡时，需要考虑负载均衡器的配置、服务器的配置、网络拓扑结构等因素。 6. 内容分发网络：内容分发网络是指使用多个服务器来分发网站的内容，以提高网站的性能和可扩展性。内容分发网络包括边缘缓存、内容分发网络服务器、内容分发网络管理系统等。例如，在使用边缘缓存时，需要考虑缓存的生命周期、缓存的存储位置、缓存的刷新机制等因素。 Web 容量规划的艺术需要考虑多个方面的因素，包括服务器配置、网络架构、数据库性能、缓存机制、负载均衡、内容分发网络等。只有通过对这些方面的深入了解和掌握，才能设计和实现高性能、高可扩展性的网站或应用程序。在 O'Reilly 的书籍《The Art of Capacity Planning》中，作者 John Allspaw 对 Web 容量规划进行了深入的探讨和分析，为读者提供了实用的经验和知识。该书籍涵盖了容量规划的基本概念、服务器配置、网络架构、数据库性能、缓存机制、负载均衡、内容分发网络等方面的知识，是一本非常有价值的参考书籍。

xiv PREFACE

Safari

Books Online

When you see a Safari

Books Online icon on the cover of your favorite

technology book, that means the book is available online through the

O’Reilly Network Safari Bookshelf.

Safari offers a solution that’s better than e-books. It’s a virtual library that lets you easily

search thousands of top tech books, cut and paste code samples, download chapters, and

find quick answers when you need the most accurate, current information. Try it for free

at http://safari.oreilly.com.

Acknowledgments

It’s simply not possible to thank everyone enough in this single, small paragraph, but I will

most certainly mention their names. Most of the material in this book was derived from

experiences in the trenches, and there are many people who have toughed it out in those

trenches alongside me. Peter Norby, Gil Raphaelli, Kevin Collins, Dathan Pattishall, Cal

Henderson, Aaron Cope, Paul Hammond, Paul Lloyd, Serguei Mourachov and Chad Dick-

erson need special thanks, as does Heather Champ and the entire Flickr customer care

team. Thank you Flickr development engineering: you all think like operations engineers

and for that I am grateful. Thanks to Stewart Butterfield and Caterina Fake for convincing

me to join the Flickr team early on. Thanks to David Filo and Hugo Gunnarsen for forcing

me to back up my hardware requests with real data. Major thanks go out to Kevin Murphy

for providing so much material in the automated deployment chapter. Thanks to Andy

Oram and Isabel Kunkle for editing, and special thanks to my good friend Chris Colin for

excellent pre-pre-editing advice.

Thanks to Adam Jacob, Matt St. Onge, Jeremy Zawodny, and Theo Schlossnagle for the

super tech review.

Much thanks to Matt Mullenweg and Don MacAskill for sharing their cloud infrastructure

use cases.

Most important, thanks to my wife, Elizabeth Kairys, for encouraging and supporting me

in this insane endeavor. Accomplishing this without her would have been impossible.

GOALS, ISSUES, AND PROCESSES IN CAPACITY PLANNING 3

Quick and Dirty Math

The ideas I’ve just presented are hardly new, innovative, or complex. Engineering disci-

plines have always employed back-of-the-envelope calculations; the field of web opera-

tions is no different.

Because we’re looking to make judgments and predictions on a quickly changing land-

scape, approximations will be necessary, and it’s important to realize what that means in

terms of limitations in the process. Being aware of when detail is needed and when it’s not

is crucial to forecasting budgets and cost models. Unnecessary detail means wasted time.

Lacking the proper detail can be fatal.

Predicting When Your Systems Will Fail

Knowing when each piece of your infrastructure will fail (gracefully or not) is crucial to

capacity planning. Capacity planning for the web, more often than one would like to

admit, looks like the approach shown in Figure 1-2.

Including this information as part of your calculations is mandatory, not optional. How-

ever, determining the limits of each portion of your site’s backend can be tricky. An easily

segmented architecture helps you find the limits of your current hardware configurations.

You can then use those capacity ceilings as a basis for predicting future growth.

For example, let’s assume you have a database server that responds to queries from your

frontend web servers. Planning for capacity means knowing the answers to questions such

as these:

• Taking into account the specific hardware configuration, how many queries per second

(QPS) can the database server manage?

• How many QPS can it serve before performance degradation affects end user experience?

Adjusting for periodic spikes and subtracting some comfortable percentage of headroom

(or safety factor, which we’ll talk about later) will render a single number with which you

can characterize that database configuration vis-à-vis the specific role. Once you find that

“red line” metric, you’ll know:

FIGURE 1-2. Finding failure points

4 CHAPTER ONE

• The load that will cause the database to fail, which will allow you to set alert thresholds

accordingly.

• What to expect from adding (or removing) similar database servers to the backend.

• When to start sizing another order of new database capacity.

We’ll talk more about these last points in the coming chapters. One thing to note is the

entire capacity planning process is going to be architecture-specific. This means the calcu-

lations you make to predict increasing capacity may have other constraints specific to your

particular application.

For example, to spread out the load, a LAMP application might utilize a MySQL server as a

master database in which all live data is written and maintained, and use a second, repli-

cated slave database for read-only database operations. Adding more slave databases to

scale the read-only traffic is generally an appropriate technique, but many large websites

(including Flickr) have been forthright about their experiences with this approach, and

the limits they’ve encountered. There is a limit to how many read-only slave databases

you can add before you begin to see diminishing returns as the rate and volume of

changes to data on the master database may be more than the replicated slaves can sus-

tain, no matter how many you add. This is just one example where your architecture can

have a large effect on your ability to add capacity.

Expanding database-driven web applications might take different paths in their evolution

toward scalable maturity. Some may choose to federate data across many master data-

bases. They may split up the database into their own clusters, or choose to cache data in a

variety of methods to reduce load on their database layer. Yet others may take a hybrid

approach, using all of these methods of scaling. This book is not intended to be an advice

column on database scaling, it’s meant to serve as a guide by which you can come up with

your own planning and measurement process—one that is right for your environment.

Make Your System Stats Tell Stories

Server statistics paint only part of the picture of your system’s health. Unless they can be

tied to actual site metrics, server statistics don’t mean very much in terms of characterizing

your usage. And this is something you’ll need to know in order to track how capacity will

change over time.

For example, knowing your web servers are processing X requests per second is handy,

but it’s also good to know what those X requests per second actually mean in terms of

your users. Maybe X requests per second represents Y number of users employing the site

simultaneously.

It would be even better to know that of those Y simultaneous users, A percent are upload-

ing photos, B percent are making comments on a heated forum topic, and C percent are

poking randomly around the site while waiting for the pizza guy to arrive. Measuring

those user metrics over time is a first step. Comparing and graphing the web server hits-

per-second against those user interaction metrics will ultimately yield some of the cost of

剩余153页未读，继续阅读

majinjing3

粉丝: 2
资源: 29

Web容量规划艺术：提高网站性能和可扩展性

The Art of Capacity Planning Scaling Web Resources in the Cloud(2nd) epub

Web容量规划的艺术.part1

[创业的艺术.盖伊·川崎].Guy.Kawasaki.-.The.Art.Of.The.Start.pdf

[计算机科学经典著作].Addison.Wesley.Donald.E.Knuth.The.Art.of.Computer.Programming.Volume.1.pdf

（第二卷）计算机程序设计艺术.The.Art.of.Computer.Programming.Vol2.3rd.Edition_zh-cn.pdf

（第一卷）计算机程序设计艺术.The.Art.of.Computer.Programming.Vol1.3rd.Edition_zh-cn.pdf

计算机程序设计艺术.The.Art.of.Computer.Programming.全三卷

Self.Service.Linux.Mastering.the.Art.of.Problem.Determination

Addison.Wesley.Donald.E.Knuth.The.Art.of.Computer.Programming.Volume.1

Addison.Wesley.The.Art.of.Computer.Programming.Volume.4A.2011

最新资源