Tuesday, August 30, 2011

Website is not an island

Today I joined the Webinar from compuware talking about How to Mitigate the performance risk of 3rd party Web components. Apart from their impressive application delivery chain explanation of the necessity to test and monitor Web performance from end user perspective, "No website is an island" is also an interesting topic with regard to the importance of looking at third party web component performance.

There are quite a few talks about Ad and Google Analytics performance. Current Web sites are getting richer (average page size is keeping increasing). Most contents are not served from single host (domain), instead from different outside sources, like Advertisement, Analytics, NewsFeed, Blog, Social network, APIs, Video, Shopping cart, Search engine, Rating&Review and Cloud objects. The benefits of using 3rd party components outweigh the risks - it is not under your control.

The best way is to mitigate the risk using below guidelines:
  • Choose 3rd party component with high SLA
  • Decide on a mitigation strategy (fault-tolerance, fallback, design for failure, alternative)
  • Test it under all conditions
  • Figure out a way to monitor it
During the webinar, Compuware CTO also talked about 5 best practices, and I totally agree the tips for Mobile Web site because it covers 3 major factors (# of requests, download size and network latency) regarding mobile Web performance.
  • Minimize third-party content
  • Limit # of hosts, connections and requests
  • Keep size small and use CDN

Monday, August 29, 2011

Web browsers and engines

When programming Web, we need consider cross browsers to make sure the HTML/CSS/Javascript codes work well in different Web browsers. As of today, the most popular web browsers are Internet Explorer, Firefox, Google Chrome, Safari, and Opera.

Web browser has an engine to take marked up content (such as HTML, XML, image files, etc.) and formatting information (such as CSS, XSL, etc.) and displays the formatted content on the screen. (for data and view) This engine is also called sometimes called layout engine or rendering engine.

  1. Internet Explorer 9 uses Trident
  2. Firefox uses Gecko
  3. Chrome uses WebKit
  4. Safari uses WebKit
  5. Opera uses Presto

Apart from layout engine, Web browser also needs a javascript engine to execute javascript (for actions).  Most new javascript engines have JIT compiler for better performance (See SunSpider for benchmark data)

  1. Chakra: A new IE JScript engine used in Internet Explorer 9. It was first previewed at MIX 10 as part of the Internet Explorer Platform Preview.
  2. SpiderMonkey: A JavaScript engine in Mozilla Gecko applications, including Firefox. The engine has two types of JIT compilers, that are sometimes referred to as J├ĄgerMonkey or TraceMonkey.
  3. V8: A JavaScript engine used in Google Chrome.
  4. SquirrelFish: The JavaScript engine for Apple Inc.'s WebKit. Also known as Nitro.(JavascriptCore)
  5. Carakan: A JavaScript engine developed by Opera Software ASA, included in the 10.50 release of the Opera web browser.

In my mind, new Web browsers are getting faster, and Web development is more focusing on framework, pattern and productivity. We are moving to HTML5, Javascript (latest version 1.8.5) and CSS3, and expecting to see less difference across these browsers. A new Web era is coming.

Sunday, August 28, 2011

Two errors when javascript calls flash methods

There are two frequent errors I met when I writing javascript and flash communication codes.

1. Error calling method on NPObject!
This error usually means Flash side exception, it might be caused by Flash itself error handling logic, or caused by wrong parameters passed to Flash from Javascript.

2. Uncaught TypeError: Object #<HTMLObjectElement> has no method 'xxx'
This error usually means flash object is not available or no such a method, it might be caused by flash object is not fully loaded, or not found the correct object, or call the wrong flash method (from Flash ExternalCallInterface).

Friday, August 26, 2011

Open source 101

Open source software is software provided on terms allowing user to use, modify, and distribute the source code. It is different from freeware or shareware. In the open source world, "free" usually means "freedom to modify and redistribute source code" rights that do not necessarily come with freeware or shareware.

An open-source license is a copyright license for computer software that makes the source code available for everyone to use. Copyleft licenses require that you share any modifications that you make to the original code. Usually, these licenses also require that you share these modifications under the exact same open source software license as the source code. Different open source licenses have different levels of copyleft, namely No Copyleft, Weak Copyleft and Strong Copyleft.

Here are a list of common licenses:

  • GPL v.3 - GNU General Public License, version 3   
  • LGPL v.3 - GNU Lesser General Public License, version 3 (sometimes referred to as the "Library" General Public License)   
  • GPL v.2 - GNU General Public License, version 2   
  • LGPL v.2.1 - GNU Lesser General Public License, version 2.1 (sometimes referred to as the "Library" General Public License)   
  • MPL - Mozilla Public License, version 1.1   
  • Eclipse - Eclipse Public License, version 1.0   
  • CPL - Common Public License, version 1.0   
  • CDDL - Common Development and Distribution License, version 1.0   
  • MIT - MIT License   
  • BSD - Berkeley Software Distribution License or "New BSD"
Take away:
Feel free to use MIT/BSD license which has no copyleft, try to avoid GPL which has strong copyleft. MPL, Eclipse, CPL, CDDL are falling into weak copyleft category.

Friday, August 5, 2011

MySQL/InnoDB Replication Options

MySQL Asynchronous Replication
Master doesn't wait for slave
Slaves determines how much to pull log events from Master (Bin log) to Slave (Relay log)
Read stale data on slave

No flow control

Master failure
Data loss

MySQL Semi-Sync Replication
Master waits for an ACK from slave
Slave logs the transaction event in relay log and ACKs
Read stale data on slave
No flow control

Master failure
Data loss

Schooner MySQL Sync Replication

After commit, all Slaves guaranteed to receive and commit the change
Slave in lock-step with Master
Read stale data on slave
No flow control

Master failure
Data loss

DRBD (Distributed Replicated Block Device)
Block level replication available for Linux
Suitable for a Master with Direct Attached Storage (DAS)

SAN (Storage Area Network)
Shared disk with similar pros and cons as DRBD
Available for multiple OS
Snapshot backups are a plus


Thursday, August 4, 2011

Cache related Http Headers

Http headers can instruct what kind of cache mechanism browser and proxy should obey along the request/response chain. For static resources (Javascript, CSS, images, flash etc), it is suggested to apply cache on browser or proxy side to reduce # of Http requests.

Response Headers:
Cache-Control     Tells all caching mechanisms from server to client whether they may cache this object (public/private to control if browser or proxy cache, no-store to control if save to disk, max-age is to control how long to cache)
Expires     Gives the date/time after which the response is considered stale (suggested 1 year from now, for aggressive static resource cache)
Date     The date and time that the message was sent (It is useful for Expires by date time)
ETag     An identifier for a specific version of a resource, often a message digest (Suggest to disable it for performance, or re-configure ETag to remove server specific info. See If-None-Match. ETag takes precedence over Last-Modified if both exist)
Last-Modified     The last modified date for the requested object, in RFC 2822 format (for conditional get, 304 Not Modified, see If-Modified-Since)
Pragma     Implementation-specific headers that may have various effects anywhere along the request-response chain. (Http1.0, example is Pragma: no-cache)
Vary     Tells downstream proxies how to match future request headers to decide whether the cached response can be used rather than requesting a fresh one from the origin server. (The most common case is to set Vary: Accept-Encoding, so that proxy knows if return cached compressed data to browser)

Request Headers:
Cache-Control     Used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain
If-Modified-Since     Allows a 304 Not Modified to be returned if content is unchanged
If-None-Match     Allows a 304 Not Modified to be returned if content is unchanged
Pragma     Implementation-specific headers that may have various effects anywhere along the request-response chain

It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag.

You use the Cache-control: public header to indicate that a resource can be cached by public web proxies in addition to the browser that issued the request.

Avoiding caching
HTTP version 1.1 -> Cache-Control: no-cache
HTTP version 1.0 -> Setting the Expires  header field value to a time earlier than the response time


Tuesday, August 2, 2011

Mobile Web Optimization Webinar Takeaway

Last week I attended a webinar from Compuware talking about mobile web optimization using page speed. The talk was very clear and well organized. It first went through the importance of mobile web performance, then discussed key difference between mobile and desktop, then detailed page speed rules about mobile web.

Browser is the entry point to mobile web
The browser is becoming the integration platform
The browser is becoming more complex
    - # of hosts per user transaction
    - Many RIA frameworks
    - Performance differences across devices

Free performance tools
Page Speed
dynaTrace Ajax Edition

Mobile web page load process
Mobile channel establishment
DNS lookup
TCP connect
Http request
Parse & Layout (subrequests)

Key differences between mobile and desktop
    round-trip time (High channel establishment time, lower RTT)
    bandwidth (3G vs Cable)
    CPU (JS execution times, layout times, 10x JS runtime cost, 1 ms per kb parsing)
    memory (more code/objects - more GC, more DOM, more memory)
Interaction model
    (touch vs click, mobile click event with 300-500ms delay)

Page Speed Rules
Use an application cache (how about localstorage?)
Defer JS parsing (how about deferring JS download?)
make landing page redirects cacheable (Cache-control: private, max-age > 0) (How long? 301 and 302 are both cacheable?)
prefer touch events (why not disable click event on mobile?)


90% line in JMeter aggregate report

I considered 90% line is the response data 90% users will see, but recently realized this was wrong. JMeter online Help has detailed explanation about every item in Aggregate report.

The 90% line tells you that 90% of the samples fell at or below that number. However, it is more meaningful than average in terms of SLA. We expect it within 2x of average time. That is, if average time is 500ms, we expect 90% line is less than 1000ms. Otherwise the system fluctuates a lot.