48
Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

Embed Size (px)

Citation preview

Page 1: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

Architecting the Network for SharePoint 20102007Presented by

Michael Koyfman

Solution Architect

Page 2: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

2

F5 Continues to be #1 in the WW Application Delivery Controller Market for Q110

Q110 Gartner ADC Market Share

SOURCE: Gartner

Cisco22.4%

F5 NETWORKS44.2%

Others13.9%

Radware8.8%

Citrix10.6%

Q110 ADC* Market Share Leaders

– F5 : 44.2%– Cisco: 22.4%– Citrix: 10.6%

Q110 ADC Market Share Revenue Leaders

– F5: $126.4 Million– Cisco: $64 Million– Citrix: $30.4 Million

Q110 ADC Q/Q Revenue Growth– F5: 12.5%– Cisco: -8.6%– Citrix: -15%

Q110 ADC Total Market Numbers– Revenue: $285.7 Million– Q/Q Revenue Growth: 1%

*Application Delivery Controller (ADC) Segment Includes: Server Load Balancing/Layers 4-7 Switching and Advanced (Integrated) Platforms

Page 3: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

3

F5 Dominates in Advanced Platform ADC Segment for Q110

Q110 Gartner Advanced Platform ADC Market

Share

SOURCE: Gartner

Citrix15.7%

F5 NETWORKS61%

Radware10.5% Others

13.8%

Q110 Advanced Platform ADC* Market Share Leaders

– F5: 61%– Citrix: 15.7%– Radware: 10.5%

Q110 Advanced Platform ADC Market Share Revenue Leaders

– F5: $126.4 Million

– Citrix: $30.4 Million

– Radware: $21.7 MillionQ110 Advanced Platform ADC Q/Q Revenue Growth

– F5: 12.5%– Citrix: -15%– Radware: 2.4%

Q110 Advanced Platform ADC Total Market Numbers

– Revenue: $207.1 Million– Q/Q Revenue Growth: 4.3%

*Advanced Platform Segment Includes: ADCs that integrate several functions (typically more than four) on a single platform (for example, load balancing, TCP, connection management, SSL offload, compression and caching)

Page 4: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

4

Magic Quadrant for Application Delivery Controllers, 2009

Leadership Position

F5 Networks - Strengths• F5 Networks has a broad and comprehensive

vision with industry-leading understanding of the needs of application development, deployment and management.

• The vendor has a comprehensive feature set with a full range of extensibility delivered through iRules and iControl, and integration with popular integrated development environments (IDEs), such as Eclipse and .NET/Visual Basic.

• F5 has developed a very large community of committed users (using F5's DevCentral portal) that helps fuel the use of iRules to solve unique data center application challenges, creating a loyal and engaged user base.

• F5 has a solid financial position and continued market-leading position.

SOURCE Link

Page 5: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

6

Purpose: How can the Network be Leveraged to achieve:

• Scalability– Building the Right Infrastructure to Meet the Current User Load,

and Also Allow for Future Growth.

• High Availability– Architecting the “Bullet Proof” SharePoint Deployment– Eradicating the Single Points of Failure

• Performance– Building a SharePoint Deployment with the Best Possible End

User Experience

Page 6: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

7

Load Balancing Concepts

User Requests

SingleServer

The Typical Single Server Deployment

Users connect directly to the open IP:Port of the Server

No redundancy, little scalability

Page 7: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

8

Load Balancing Concepts

User Requests

Farm ofServers

Introduction of the Load Balancer

• Hardware Device• Different models for capacity

• Sits in front of the server farm, accepting the user connections, and then dispatching the connection to a chosen server.

• Most modern LBs are multi-function(caching, compression, rate shaping, firewalling, etc…)

• Most LBs can load balance multiple types of traffic

Instead of a single server, a Load Balancer allows you to scale the number of available servers

Page 8: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

9

Load Balancing Concepts

User Requests

Farm ofServers

How it works:

A properly configured Load Balancer is constantly monitoring the health and availability of the servers in the farm. It will use this information to help it make a load balancing decision.

Instead of the User making the connection directly to the server, the User makes a connection to the Virtual Server, which resides on the external facing side of the Load Balancer

The Load Balancer will send the connection to a specific server based upon• The LB algorithm selected• Health & Availability of the servers

Page 9: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

10

Load Balancing Concepts

User Requests

Farm ofServers

Load Balancing Methods:

Some are static• Round Robin• Ratio

Some are dynamic, and try to take certain network and server characteristics into account• Least Connections• Fastest Server• Trending

Historically, static methods were preferred, as they tended to have the lightest impact on the Load Balancer, however today’s Load Balancers are capable of handling even complex LB algorithms without any performance degradation. F5 recommends using a dynamic LB method with SharePoint.

Page 10: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

11

Load Balancing Concepts

User Requests

Farm ofServers

Persistence: Once a user is sent to a specific server, do follow on connections/requests need to be sent to the same server?

Common Persistence Methods:Source IP BasedCookie BasedSSL IDCustom Methods

Most SharePoint deployments do not require persistence, however since a SharePoint front end can build an object cache, there is benefit to enabling it. It’s recommended to use a combination of Cookie & Source IP based persistence.

Page 11: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

12

Load Balancing Concepts

User Requests

Farm ofServers

Leveraging a Load Balancer to Eliminate the Single Points of Failure

• Redundant Load Balancers• Instant failover• Share state

• Redundant & Meshed Switch Architecture• No single path out to the next hop• Spanning Tree support

• Multihomed Networks• Multiple ISP links into the Data Center

• Multiple Data Centers• “Global” load balancing

Is it possible to eliminate all the Single Points of Failure?

Is ‘5 9s of uptime’ achievable? Realistic?

Page 12: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

13

What Else Can My Load Balancer Do?

User Requests

Farm ofServers

*Differs by vendor, but most include technologies to alleviate server load, accelerate traffic, and minimize bandwidth utilization.

• SSL termination• Compression• Content Spooling• TCP multiplexing• TCP optimizations• Browser optimizations• Rate shaping• Intelligent Browser Referencing (caching at the browser)

Results from using these features with SharePoint 2007 can be found here http://h71019.www7.hp.com/ActiveAnswers/library/GetPage.aspx?pageid=570023&statusid=0&audienceid=0&ccid=0&langid=121

Page 13: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

14

Real-World Performance

1/3 Reduction in Servers

1/3 Reduction in Licenses

1/3 Reduction in Management Time

114.8Million

5Million

95% Fewer Connections

1.87Terabyte

621Gigabytes

66% Reduction in

Bandwidth

3 Seconds

1 Seconds

200% FasterEnd-to-EndPage Load Time

350 Million Page Hits in 1 Week

Page 14: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

15

On to SharePoint………

Page 15: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

16

The Single SharePoint Server Deployment

• No Redundancy– Complete failure with any piece

• No Scalability– Measurable maximum capacity– 50 to 75 Requests per second max

• Performance Concerns– Early performance degradation

User Requests

Single Server:• Web Server• Application Server• Database

Microsoft on the Single Server Deployment• Good for evaluation• Good for very small deployments• Benefit of minimal overheadhttp://technet.microsoft.com/en-us/library/cc263202.aspx

Page 16: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

17

Scaling Out The Deployment

User Requests

Clustered or Mirrored SQL Database

Each Server Running• Web Server• Application Roles

“The Small Server Farm”

Common initial deployment

• Database split from Front End Servers

• Meets requirements for HA• Allows for future scalability• 175 to 250 RPS Maximum

Front End Servers are responsible for• Servicing web requests• Application Services, such as

• Searching• Indexing

Source : http://technet.microsoft.com/en-us/library/cc262243.aspx

Page 17: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

18

Scaling Out The Deployment

User Requests

Clustered or Mirrored SQL Database

Web Servers

Application Server

“The Medium Server Farm”

Same as the Small Server Farm, however the Application Server has been split from the Web Servers

175 to 250 RPS Maximum

Allows the Application Server’s CPU intensive functionality (search, excel services, etc) to have dedicated CPU cycles

Source: http://technet2.microsoft.com/Office/en-us/library/bd99c3a9-0333-4c1c-9793-a145769e48e61033.mspx?mfr=true

Page 18: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

19

Scaling Out The Deployment

User Requests

Clustered or Mirrored SQL Database

Application Servers

Web Servers

“The Large Server Farm”

All Servers, including Web, Application, and DB are scaled to meet demand

Can scale to support “Hundreds of thousands of users”

Availability Work Sheet from Microsofthttp://technet2.microsoft.com/Office/en-us/library/9ccfb27f-ecba-4b7d-b9a0-88fac71478a31033.mspx?mfr=true

Source: http://technet2.microsoft.com/Office/en-us/library/bd99c3a9-0333-4c1c-9793-a145769e48e61033.mspx?mfr=true

Page 19: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

20

Scalability – The Art of Sizing

• The Challenge is to size the deployment appropriately– How many servers are needed?– How are the server roles split?– What type of hardware should be used?

• The 2 Sided Sizing Dilemma– Microsoft can’t give precise sizing guidelines– Customers can’t precisely profile their user base

• Fortunately, the amount of accurate and reliable sizing information is dramatically increasing

Page 20: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

21

Scaling the Network vs. Scaling the ServersWhat needs to be considered when sizing? Is scaling a server infrastructure linear with scaling the network?

Considerations for server sizing includeHow many total users?How many concurrent users on average?Typical behavior of users? Posting, searching…. Etc.How many page views per person?How many users at peak times?How many sites are planned?What hardware architecture is being used?

Considerations for network sizing includeWhat are the peak new connections per second?What is the peak number of users/connections?What is the peak bandwidth being consumed?How many servers is the Load Balancer responsible for monitoring?What else will the Load Balancer be doing? Caching, Compression……etc

http://technet.microsoft.com/en-us/library/cc261700.aspx

Page 21: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

22

BIG-IP Hardware Line-up

Dual core CPU4 10/100/1000 + 2x 1Gb SFP1x 160GB HD4 GB memorySSL @ 5K TPS / 1 Gb Bulk1 Gbps max software compression

1 Gbps Traffic

BIG-IP 3600

Dual core CPU8 10/100/1000 + 2x 1Gb SFP1x 160 GB HD + 8GB CF4 GB memorySSL @ 10K TPS / 2 Gb bulk1 Gbps max software compression

2 Gbps Traffic

BIG-IP 8900

BIG-IP 1600

2 x Dual core CPU16 10/100/1000 + 8x 1Gb SFP2x 320 GB HD (S/W RAID) + 8GB CF8 GB memorySSL @ 25K TPS / 4 Gb bulk5 Gbps max hardware compression

6 Gbps Traffic

BIG-IP 69002 x Quad core CPU16 10/100/1000 + 8x 1Gb SFP + 2x 10Gb SFP+2x 320 GB HD (S/W RAID) + 8GB CF16 GB memorySSL @ 58K TPS / 9.6Gb bulk8 Gbps max hardware compression

12 Gbps Traffic

BIG-IP 3900

Quad core CPU8 10/100/1000 + 4x 1Gb SFP1x 300 GB HD + 8GB CF8 GB memorySSL @ 15K TPS / 3.8 Gb bulk3.8 Gbps max software compression

4 Gbps Traffic

BIG-IP 8950

2 x Quad core CPU16 10/100/1000 + 8x 1GB SFP + 2x 10Gb SFP+2x 320 GB HD (S/W RAID) + 8GB CF ?16 GB memorySSL @ 56K TPS / 9.6Gb bulk8 Gbps max software compression

20 Gbps Traffic

BIG-IP 11050

2 x Hex core CPU16 10/100/1000 + 8x 10 SFP+ 10Gbps2x 320 GB HD (S/W RAID) + 8GB CF32 GB memorySSL @ 100K TPS / 15Gb bulk12 Gbps max software compression

40 Gbps Traffic

Page 22: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

23

Sizing – Rough Guidelines

A single server deployment can handle between 50 to 75 RPS.

When scaling out Web Front Ends, assume each one can handle roughly 100 RPS. Assume 85 RPS if Query Search is running on the WFE.

According to Microsoft, use the following to determine how many RPS a user will make

Light user, access every 180 secs (20/hr), 1 RPS = 180 active users Typical user, access every 100 secs (36/hr), 1 RPS = 100 active users Heavy user, access every 60 secs (60/hr), 1 RPS = 60 active users Extreme user, access every 30 secs (120/hr), 1 RPS = 30 active users

References: http://technet.microsoft.com/en-us/library/cc262971.aspx

Page 23: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

24

Microsoft SharePoint 2007 DevelopmentHoffman, Foster. Sams Publishing

Part I dives into some sizing exercises

Sizing Resources

Microsoft Office SharePoint Server 2007 Administrator’s CompanionBill English. Microsoft Press.

Chapters 2 & 3 discusses sizing in detail

Microsoft TechnetGood information with sizing worksheets

http://technet2.microsoft.com/Office/en-us/library/031b0634-bf99-4c23-8ebf-9d58b6a8e6ce1033.mspx?mfr=true

Microsoft SharePoint Products and Technologies Team Blog http://blogs.msdn.com/sharepoint/

Joel Oleson & Mike Watson’s Blog Entries – MS IT Case Study

Page 24: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

25

Sizing Resources

HP Sizing and Configuration Tool for Microsoft Office SharePoint Server 2007

Plug in various information about user base, and it returns a full suggested hardware package

One of the most comprehensive sizing guides out there.

http://h20338.www2.hp.com/activeanswers/Secure/548230-0-0-0-121.html

Page 25: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

26

Sizing Guidelines

Database Clustering

High Availability and Scalability of SQL back end is achieved via SQL clustering technology.

No Load Balancer needed.

For replication, both data mirroring and log shipping is supported.

Sizing the SQL cluster for Performance and Availability

Is there a strategy to maintaining a certain maximum size to a specific SP database? Should I create separate DB’s or SQL instances for different SP sites?

There is a strategy for SP DB implementation, but it has more to do with making administration (i.e. backups & restores) easier than performance.http://www.microsoft.com/downloads/details.aspx?FamilyID=B9091243-0E17-404D-8853-57309F885722&displayLang=en

Page 26: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

27

Sizing Guidelines

Database Clustering

High Availability and Scalability of SQL back end is achieved via SQL clustering technology.

No Load Balancer needed.

For replication, both data mirroring and log shipping is supported.

Sizing the SQL cluster for Performance and Availability

As a guideline, what is the recommended number of Web Front Ends to SQL servers?

Best Practices• HA Minimum of 2• Authenticated Traffic

“4:1”*• Anonymous Traffic

“6:1”*• Suggested Limit “8:1”**

*Source http://blogs.msdn.com/joelo/archive/2007/07/12/massive-scale-deployment-modularity-in-sharepoint-farms.aspx**Source http://technet2.microsoft.com/Office/en-us/library/6a13cd9f-4b44-40d6-85aa-c70a8e5c34fe1033.mspx?mfr=true

Page 27: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

28

Sizing vs. Performance Docs

2 Great Resources that compare how sizing affects performance

Microsoft Office SharePoint Server 2007 on HP ProLiant servers – performance summary http://h71028.www7.hp.com/ERC/downloads/4AA1-1793ENW.pdf

Discusses when to scale up vs. out (more cores vs. more servers)

Plan for performance and capacity (Office SharePoint Server) http://technet2.microsoft.com/Office/en-us/library/8dd52916-f77d-4444-b593-1f7d6f330e5f1033.mspx?mfr=true

Discusses acceptable performance limits

Page 28: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

29

High Availability

• Health Monitoring: How does the appliance determine if the servers are up/down?

• Load Balancing: How does the appliance distribute traffic to the Front Ends?

• Persistence: Can (and should) the appliance keep a user attached to the same Front End that they initially attached to?

Page 29: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

30

Multiple Data Center Challenge

Router

BIG-IP LTM

SharePoint Farm SQL DB

Site 1

Client

Router

BIG-IP LTM

SharePoint Farm SQL DB

Site 2

Can I deploy SharePoint in Active/Active Redundant DataCenters?

Page 30: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

31

Multiple DataCenter Challenge

Can SharePoint be deployed with Active/Active Redundant DataCenters?

Not in any way supported by Microsoft.

Router

BIG-IP LTM

SharePoint Farm SQL DB

Site 1

Client

Router

BIG-IP LTM

SharePoint Farm SQL DB

Site 2

Reasoning: SQL replication engine (mirroring/log shipping) just isn’t ready to handle real time replication with concurrent SharePoint user access

Page 31: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

32

Multiple Data Center Challenge

• Strategies to replace the Active/Active Deployment

– Active/Standby Data Centers– Splitting SharePoint Sites, using both Data Centers– Data Center Multihoming

Page 32: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

33

Multiple Data Center Challenge

Router

BIG-IP LTM

SharePoint Farm

Site 1 (Active)

Client

Router

BIG-IP LTM

SharePoint Farm SQL DB

Site 2 (Standby)

Solution 1: Active/Standby DataCenter

All users sent to DC1, unless it is no longer accessible.

Then all users will be sent to mirrored instanced in DC2

Good solution, the main drawback is the expense.

Page 33: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

34

Multiple DataCenter Challenge

Router

BIG-IP LTM

SharePoint Farm

DC 1 (Active for Site A) (Standby for Site B)

Client

Router

BIG-IP LTM

SharePoint Farm SQL DB

DC 2 (Active for site B) (Standy for site A)

Solution 2: Multiple SharePoint Sites

SharePoint split into multiple sites, each using different SQL instances

Site A uses Data Center 1 as its primary DC, and Data Center 2 as its backup

Multiple Benefits, including no ‘dark fiber’.

Site A = humanresources.intranet.netSite B = development.intranet.net

Page 34: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

35

Multiple Data Center Challenge

Clustered or Mirrored SQL Database

Application Server

Web Servers

Clustered or Mirrored SQL Database

Application Server

Web Servers

ISP (Link) Load Balancing Routing (BGP) Solution

Strategy 3: Multihoming the Data Center

Page 35: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

36

Multihoming the Data CenterBGP Solution

Clustered or Mirrored SQL Database

Application Server

Web Servers

Routing (BGP) Solution

Use 2 or more separate ISPs to peer with each other, creating a single ‘virtual’ ISP link.

Benefits: ISP Links share IP space, so DNS caching not an issue

Drawbacks:Convergence time can be long.

Difficult to fully leverage all available bandwidth

Page 36: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

37

Multiple Data Center Challenge

Clustered or Mirrored SQL Database

Application Server

Web Servers

ISP (Link) Load Balancing

ISP Load Balancing

Multiple ISP links are used.

DNS used to direct users in via ISP1, ISP2, ISP3, etc..

Benefits:Performance based usage of ISP links

Better Bandwidth Utilization

Drawbacks:DNS caching

Page 37: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

38

Performance

• Problem: How Can The Content Be Delivered To The End User In The Most Efficient Way Possible?

• Combination of Technologies

Page 38: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

39

SSL Acceleration• SSL Connections to a server

can eat up as much as 30% of available CPU cycles.

• SSL on NT/IIS means up to 37x fewer connections/second

• SSL Acceleration Devices typically have specialized ASIC processors for terminating SSL.

• SharePoint officially supports SSL offloading

SSL/TLSEncrypted

Clear TextHTTP

– * Source: Networkshop Scaling eCommerce Infrastructure http://www.networkshop.ca

Page 39: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

40

Business Benefit

The F5 Solution

Control Bandwidth Usage

KaZaa &Email

Video Conferencing

Oracle

HTTP Traffic

4x

3x

2x

1x

Client

Rate Shaping + iRules - Bandwidth management to prioritize high-priority applications over P2P traffic and other low-priority applicationsPacket Filtering - Selective filtering of P2P sites based on protocol, addresses, and/or ports

Control bandwidth usage and spending

Minimize impact on business-critical applications

Get more bandwidth from the same size pipe

Control traffic spikesControl per application, per protocol,

per user

Page 40: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

41

Fast Cache Unmatched Flexibility Provides Superior Application Offloading

• Intelligent memory based cache • Full support for static and dynamic content• Exclusive “Multi-Store” caching for prioritized

application service• Superior caching of pre-compressed content• Most advanced cache controls - iRules

Page 41: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

42

HP / F5 Joint SharePoint 2007 Best Practices & Deployment Guide

• Joint performance testing to determine best practices for accelerating SharePoint 2007 & 2010

• Over 100 separate tests ran & recorded, with varying network conditions, such as latency, packet loss, & bandwidth

• Whitepaper (results) posted:http://www.f5.com/pdf/solution-center/hp-wp-deploy-ltm-sharepoint.pdf

Page 42: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

43

HP Results

• Internet – asymmetric BIG-IP LTM with WebAccelerator solution • While not able to provide all the capabilities and benefits of a symmetric solution,

results show that deploying a single BIG-IP LTM with WebAccelerator appliance in this scenario will have measurable benefits in terms of increased throughput and in providing users with an improved experience.

– • Typical throughput improvements for the 6Mbps and 1536Kbps tests approached a factor of 2 (double the throughput). Again, it was not possible to emulate sufficient load for the 44Mbps tests to drive the accelerated WAN to capacity, but the trends are similar to the 6Mbps tests and the same degree of improvement should be expected.

– • The hits-per-page ratio dropped from 3:1 (un-accelerated) to about 1.2:1 (accelerated) showing a good degree of protocol optimization.

– • Average page (response) times showed improvements ranging from factors of between 3 and 5 (that is, some functions took one fifth of the time).

– • Client LAN traffic was reduced to 75% of the un-accelerated cases. – • A good level of compression was achieved, but note that the users’ browsers are used to

un-compress the data and need to be set to do so.

Page 43: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

44

Branch Office Scenario Results

• Average time for a Document Open decreased 12x

• Average time for a Page Open decreased by over 6x

Avg Page Avg Search

Avg List Open

Avg Doc Open

0

1

2

3

4

5

6

7

8

9

Unaccelerated

Web Accelerator (sym)

Page 44: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

45

Internet Scenario Results

• Average Page Open Time decreased by over 60%

• Average Search Time decreased by over 40%

Avg Page Avg Search Avg List Open Avg Doc Open 0

2

4

6

8

10

12

Unaccelerated

Web Accelerator

Page 45: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

46

Questions to ask ANY vendor

• Give me your SharePoint Story– What testing have you done with SharePoint?– What SharePoint specific development efforts have

you undertaken?

Page 46: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

47

Questions to ask ANY vendor

• How do you determine server availability and health?

• What’s the recommended method of distributing traffic?

• What methods does the appliance have for persisting users?

Page 47: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect

48

F5 Resources

F5 SharePoint 2010 Deployment Guidehttp://www.f5.com/pdf/deployment-guides/f5-sharepoint-2010-dg.pdf

HP F5 SharePoint Acceleration Dochttp://h71019.www7.hp.com/ActiveAnswers/library/GetPage.aspx?pageid=570023&statusid=0&audienceid=0&ccid=0&langid=121

F5 Microsoft Business Development TeamJeff Bellamy–Business Development Director for the Microsoft Partnership –

[email protected] – 425-890-1331Ryan Korock – Senior Solutions Architect – [email protected] – 206-272-6953James Hendergart – Business Development Manager – [email protected] – 206-272-

5543Helen Johnson – Solutions Engineer – [email protected] – 206-272-6238

Page 48: Architecting the Network for SharePoint 20102007 Presented by Michael Koyfman Solution Architect