h a n g e Vi e
w
N y
Web Performance Notes
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Core Ideas • To a user time passed matters not bytes sent • There is a difference between perceived time and actual time • Page paint time matter • Amount of screen refresh matters – Frames, Emphasis on reflows in HTML/CSS parse • How the screen refreshes matters – All at once vs. incrementally • Application pacing matters – Preloaders, travel search, etc.
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Core Ideas • To some Web owners bytes sent may matter quite a bit as well because of cost. • Obviously cost is bandwidth – How much does 50K cost…nothing – How much does 50K * thousands of customers cost maybe something?
• Note the design focus of e-commerce sites, $ and bytes in content not in navigation • Heavy pages don’t just cause bandwidth they may cost hardware in terms of scalability, servers can’t be done with a connection as quick thus you will need more of them more quickly
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Speed is not just a simple case of bytes
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Core Idea – Golden Rule
Golden Rule of Optimization “Less data, less often” • Send as little as you need to as infrequently as you need to if you want to go faster – Example: compression -> little to send – Example: caching -> less frequent requests
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Scale != Speed • Adding more servers doesn’t make a site faster – Scaling does not mean faster unless things are overloaded
• If a server is overloaded by offloading it, it may appear to go faster but in that sense the server was not operating at optimal efficiency • Do you know the ‘tolerance’ of a server, connection, etc.? – Number of concurrent connections it could handle, amount of traffic before the pipe is saturated, etc.
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Server Side Web Languages
lic
k
Lecture #13
to
bu
c u -tr a c k
.d o
o
w
.c
m
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
Simple (Re)view to Think about Optimization <----Network----> HTTP Request
User Agent of some sort
HTTP Response
Web Server Hardware & Software
Apache, IIS, Zeus, etc.
Server Side programming technology Backend System (e.g. Database)
CGI Apache Module, ISAPI Scripting Tech (PHP)
.c
h a n g e Vi e
w
N y
Optimizations Step by Step
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Web Overview: Steps 1 & 2 – The Request
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Web Overview: Steps 1 & 2 Issues • Main challenge is DNS which is both fragile and robust – Don’t skimp on DNS servers – Consider DNS replication or managed services • UltraDNS (www.ultradns.com)
– Consider using shortened and contingency names to help users
• Forget the www – Minimal domains (e.g www.pint.com ~ pint.com)
• Contingency hosts
• w, ww, wwww • All pretty much “free” just DNS entries
• Contingency domains – – – – –
Expanded out: powellinternet.com Products and brands: www.ipod.com Typos: www.gooogle.com, www.amazom.com Misspells: www.zerox.com Forgot the perioud: wwwpint.com (new domain in minimal form)
lic
k
Lecture #13
.d o
m
w
o
.c
to
bu
c u -tr a c k
C
Server Side Web Languages
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Web Overview: Step 3 – Transmit Request
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 3 Notes • To improve this step reduce “travel time” – – – –
close the gap closer à less hops, less distance geographical/network geographical sensitivity implies edge servers a la CDNs (content distribution network) • Getting beer at the ball park example
• Reduce the request size • make payload smaller; analyze payload • no savings here as request is small, response though will be large
–
Increase bandwidth? • Not really helpful – 10k on a T3 vs 10k on a T1!?
lic
k
Lecture #13
.d o
m
w
o
.c
to
bu
c u -tr a c k
C
Server Side Web Languages
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4: Processing Response
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4 Issues • Bottleneck: Server Capacity • Can the server take my request? – No – too busy right now • -Not – – – – – –
enough capacity or incoming bandwidth hardware/software flash traffic too many requests holding requests open too long (many slow downloaders) taking too long to fulfill requests » processing time of request are significant
• Throw bandwidth and hardware at the problem
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4 Solution 1
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4 Solution 2
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Server Capacity Notes • Simple solution of DNS round-robin is often used for sites with only a few servers • While easy to set up, it has cons – Sub-optimal distribution of traffic across the servers – Does not deal well with hung servers
• To improve the situation you can create a cluster using software or hardware – Hardware often makes more sense (except cost) – Many intelligent switch/loadbalancer vendors • (Foundry, F5, Cisco, Radware, etc.)
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Server Capacity Notes • A load balancer will distribute load across a server farm based upon metrics such as least busy, most available, closest network wise, fastest response, etc. • While you may not be able to afford a load balancer you can segment server traffic as well • Consider a machine like images.pint.com to handle your image traffic, store.pint.com to handle your SSL traffic, and so on. Then by just using your links and changing HTML you will distribute some load around – This particular approach with images actually may have a benefit in user download speed as well since browsers will open new connections to the other domain and parallelize your requests a bit better
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4 Solution 2 Redux
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Server Capacity Contd. • Can the server take my request now? – Yes but… • -Response is still slow! – Static content » disk problems » disk to network copy delays • Get a faster disk drive – Most Web servers are not CPU bound they are disk and network bound • Best solution is memory caching but that does cost money
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Server Capacity Contd. • Can the server take my request now? • Yes but… – -Dynamic content problems – Generation times
– It does take time to build a page on the fly and if you are doing a lot of this your box may be CPU bound • A significant problem here is the so called “static dynamic” – http://www.xyz.com/pressrelease.asp?id=5 in most sites is the same page regardless of the users yet it is been rebuilt every single visit to the site which costs time and CPU resources
• Solution: self-generate content into HTML • Solution: use a reverse proxy cache
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4 Solution Contd.
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4 Solution – Cache Issues • Note the similarity between interpretation and compilation problems with coding in the caching solution • A cache functions by responding to requests for Web objects. If the object requested is unknown, it is fetched from the origin server; if it has been fetched recently, the request is served from the cache. • What you can’t put into a proxy cache easily: – Extremely dynamic content particularly personalized content
• You can do it and recode pages to let the proxy know what is cacheable and what is not, but the work involved may be significant. This problem also plagues CDNs see later slide
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 4 Solution –Connection Offload • Many sites get network bound since they cannot let go of a connection until the last ACK packet is back from the user – Given the mix of fast and slow users you may find that a box will get saturated sooner that it should – Solution: network stack tuning – Solution: TCP termination at the Load Balancer • Terminating and muxing the connections gives the servers orderly workloads to handle
• Add in the overhead of crypto (SSL) and you really want to offload to a server with a special card or have SSL decryption in your terminating device
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
On to the real problem • Once the request has been processed either by the server or a cache and is ready to be sent, you hit the real trouble spot in the process – result delivery
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Step 6: Returning the Data
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y k
Lecture #13
lic
Payload Issues • The return is composed of headers and data • The bulk of the payload is of course the data of a Web page which is composed of two types of components Text HTML/XHTML/XML CSS JavaScript
Binary Images (GIF, JPEG, PNG) Animations (Animated GIFs, Flash, Shockwave) Video Audio PDF Downloads (.exe, .zip, …)
.d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Addressing Payload Issues • Once again our network Aware Web Development Mantra –
“Send less, less often”
• Reduce content sent • Do you really need that image, Flash splash page, etc. • Cool design may = more money in delivery – The fallacy of flat bandwidth rates – Incremental bandwidth costs • Real world examples: goodbye graphic rollovers, CSS oriented design, advertisements as a higher % of byte payload
lic
k
Lecture #13
.d o
m
w
o
.c
to
bu
c u -tr a c k
C
Server Side Web Languages
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Addressing Payload Issues Contd. • Compress images properly – –
Beware of decompression time with large physical dimension images. Paint delay may far outweigh delivery savings. Don’t be packet stupid • The “envelope” holds a basic min. amount about 1K making it smaller doesn’t help!
–
Designers beware that some acceleration devices will recompress your images, sorry to say what you do may not make it to the end user the way you intended.
lic
k
Lecture #13
.d o
m
w
o
.c
to
bu
c u -tr a c k
C
Server Side Web Languages
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Addressing Payload Issues Contd. •
Crunch HTML – – –
Who needs white space, comments, etc? Some types of
is wasted Color remap #ff0000 -> red •
–
Entity remap ¤ -> ¤ •
– –
•
In some cases other way: name -> hex In some cases the other way as well
Most changes would not hurt search engines, users, etc. Most of these byte shaves have to be done automatically to be of value but they add up
I am anti-view source!? (for many reasons)
lic
k
Lecture #13
.d o
m
w
o
.c
to
bu
c u -tr a c k
C
Server Side Web Languages
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Addressing Payload Issues Contd. • Crunch CSS – –
Same whitespace and comment issues as HTML You can also use shorter id and classnames • .P1 instead of .Paragraph1 or .Tc instead of .TableCell • This should be done automatically because of readability
–
Color condensing • #FF0000 can become #f00
–
Rule condensing • Short hand rules background not background-image • Rule rewriting to take advantage or repetition
lic
k
Lecture #13
.d o
m
w
o
.c
to
bu
c u -tr a c k
C
Server Side Web Languages
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Addressing Payload Issues Contd. •
Crunch JavaScript
– – – – – –
Same whitespace and comment issues as HTML & CSS Variable and function renaming can produce significant savings function validation() becomes function v() or similar Some basic dead code elimination Semi-colon removal in some places Object remapping •
Script roll up would be very useful and would also reduce a request Becomes •
– Given JavaScripts shared namespace there is no reason why not
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Request Reduction Contd. • For CSS files you see a similar situation as JS • For images you could adopt an idea called CSS sprites where you make a large image tile of all the independent pieces and then show portions of the image
Next image
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
Request Reduction in Action
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
All About End Users? • -Bytes vs. Time • -Read, Decide, Click, Wait, Repeat • -Download ahead of time – Flash preloaders, cache tricks, JS preload – Mozilla prefetch • http://www.mozilla.org/projects/netlib/ Link_Prefetching_FAQ.html
– Precache example • http://ajaxref.com/ch8/longscroll.html
– Don’t forget Browser Bulk – IE vs Opera vs Mozilla vs Safari – they are different pieces of software with different qualities of execution
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
h a n g e Vi e
w
N y
How do you know you are doing well? • Measure server time, network time, and paint time – Server time is easy, network time is harder, and paint time requires a JavaScript injection to then start and stop a timer – http://ajaxref.com/ch6/connectionspeed.html – Interesting to note that such features are coming directly to browsers now (http://blogs.msdn.com/b/ie/archive/ 2010/06/28/measuring-web-page-performance.aspx) and the W3C is creating performance working group (http:// www.w3.org/2010/06/webperf.html)
k
Lecture #13
lic .d o
m
w
o
Server Side Web Languages
.c
to
bu
c u -tr a c k
C
m
CSE 135 o
.d o
w
w
w
w
w
C
lic
k
to
bu
y
N
O W
!
XC
er
O W
F-
w
PD
h a n g e Vi e
!
XC
er
PD
F-
c u -tr a c k
.c
