Cải thiện hiệu năng của các ứng dụng Web 2.0

Khám phá các cơ chế nhớ sẵn khác nhau phía trình duyệt

Với sự xuất hiện và phổ biến của các ứng dụng Web 2.0, cách con người sử dụng Internet đã dần thay đổi. Các ứng dụng Web 2.0 hiện nay có rất nhiều khía cạnh tiêu biểu, bao gồm việc có một trình khách phong phú, một kích thước trang lớn, rất nhiều mục nhỏ trên một trang, quá nhiều mã JavaScript, v.v... Hầu hết các khía cạnh này, với công nghệ trình duyệt hiện nay, có thể gây ra các vấn đề về hiệu năng phía trình duyệt, nhất là trong các tình huống mạng đường dài. Bài viết này phân tích các sự kiện chủ yếu của các ứng dụng Web 2.0 điển hình và mô tả cách chúng sẽ gây ảnh hưởng đến hiệu năng về phía trình duyệt như thế nào. Nó cũng xem xét phần rất quan trọng của hiệu năng bên trình duyệt -- nhớ sẵn (cache) ở phía trình duyệt.

Jian Qiao Sun, Kỹ sư phần mềm, IBM

Jian Qiao Sun là Kỹ sư Hiệu năng của WPLC.



Hua Pin Shen, Kỹ sư tư vấn phần mềm, IBM  

Photo of Hua Pin ShenHua Pin Shen là Kỹ sư Hiệu năng cấp cao của WPLC.



28 01 2011

Giới thiệu

Với sự xuất hiện và phổ biến của các ứng dụng Web 2.0, và cách con người sử dụng Internet đã thay đổi, một xu hướng mới đã bắt đầu, nó tạo ra một cách tiếp cận người dùng là trung tâm nhiều hơn để quản lý nội dung, chia sẻ thông tin, trao đổi thông tin, làm việc theo nhóm, v.v... Từ quan điểm kỹ thuật, các ứng dụng Web 2.0 không đem lại nhiều đột phá công nghệ mới. Tuy nhiên, các ứng dụng này thực sự đã đem đến một mô hình mới cho việc sử dụng Internet. Các ứng dụng Web 2.0 ngày nay có nhiều đặc tính tiêu biểu, bao gồm có một trình khách phong phú, một kích thước trang lớn, nhiều mục nhỏ trên một trang, quá nhiều mã JavaScript, v.v... Các đặc tính này có thể gây ra vấn đề về hiệu năng ở phía trình duyệt, nhất là trong các tình huống mạng đường dài. Các vấn đề về hiệu năng có thể gây ảnh hưởng tiêu cực đến trải nghiệm của người sử dụng, và thậm chí bạn có thể không nhận thức được các vấn đề này. Do các nhà phát triển có các điều kiện mạng thật tuyệt vời nên tất cả các vấn đề về hiệu năng khó có thể bộc lộ hết.

Bài viết này bắt đầu với một phân tích về các sự kiện chủ yếu của các ứng dụng Web 2.0 điển hình và giải thích cách mà chúng sẽ gây ảnh hưởng đến hiệu năng bên trình duyệt như thế nào. Sau đó nó mô tả một bộ phận rất quan trọng của hiệu năng về phía trình duyệt, đó là bộ nhớ lưu sẵn (cache) ở phía trình duyệt. Bằng cách sử dụng các thiết lập cơ chế nhớ sẵn thích hợp, bạn có thể cung cấp cho những người sử dụng của bạn một trải nghiệm tốt với ứng dụng của bạn. Nếu bạn không có một thiết kế chính sách nhớ sẵn tổng thể, nó không những mang lại cho bạn một hiệu năng kém, mà còn có thể gây ra một số khiếm khuyết về mặt chức năng.

Có nhiều quy tắc ảnh hưởng đến cơ chế nhớ sẵn của trình duyệt. Chỉ kể ngắn gọn, chúng bao gồm các quy tắc Cache-Control (Điều khiển nhớ sẵn), Etag, Expires (Hết hiệu lực), Last-Modified (Lần sửa đổi gần nhất), và Vary (Biến đổi). Tất cả các thiết đặt này đều có các ý nghĩa khác nhau và tình huống sử dụng tốt nhất khác nhau. Khó khăn là ở chỗ không phải tất cả các trình duyệt phổ biến đều có cùng một hành vi đối với cùng các thiết lập. Do đó bạn nên biết chính xác cách thức mà các trình duyệt này sẽ làm việc trước khi bạn quyết định sử dụng chúng. Bài viết này xem xét các hành vi đối với các trình duyệt phổ biến nhất hiện nay trên thị trường: Internet Explorer, Firefox, Chrome, và Safari.

Trong bài này, chúng tôi cũng sử dụng Mashups của IBM® và trình "Roller Weblogger" mã nguồn mở để đưa ra các thí dụ về cách áp dụng các chỉ thị khác nhau như thế nào nhằm sử dụng tốt nhất cơ chế nhớ sẵn của trình duyệt.

Bối cảnh

Trong môi trường Internet hiện nay, các ứng dụng Web 2.0 đang trở nên phổ biến hơn. Nhiều trang Web xây dựng trên công nghệ Web 2.0, chẳng hạn như Facebook, Youtube, v.v... IBM cũng có các ứng dụng Web 2.0, chẳng hạn như Lotus Connections và Lotus Mashups.

Có một phương pháp luận cơ sở cho thời gian đáp ứng của trình duyệt:

  • Thời gian đáp ứng của trình duyệt = Thời gian phía máy chủ + Thời gian tải trang + Thời gian biểu hiện của trình duyệt
  • Thời gian tải trang = (Số lượng các yêu cầu / Tương tranh) * Độ trễ + Tổng kích thước trang / Băng thông

Trong các phương trình trên:

  • "Thời gian phía máy chủ” là thời gian dành cho các tiến trình phía máy chủ, chẳng hạn như việc xác thực của LDAP hoặc lấy thông tin từ một cơ sở dữ liệu.
  • "Thời gian biểu hiện của trình duyệt” là thời gian để trình duyệt biểu hiện trang và bao gồm cả các hoạt động chẳng hạn như thi hành JavaScript và phân tích ngữ pháp cây DOM.
  • "Số lượng các yêu cầu” là số các yêu cầu HTTP.
  • "Tương tranh” là số lượng các kết nối song song đến máy chủ mà trình duyệt đang có.
  • "Tổng kích thước trang” là kích thước toàn bộ của một trang.
  • "Độ trễ” và “Băng thông” là các số đo về tình trạng của mạng. Trong một môi trường mạng khoảng cách xa thông thường, băng thông là khoảng 1M và độ trễ là khoảng 100 miligiây. Do đó, việc giảm còn 100 KBytes về kích thước hoặc giảm còn 1 yêu cầu có thể tiết kiệm được 0,1 giây trong thời gian đáp ứng.

Xin lưu ý rằng vì tính phức tạp của tình huống thế giới thực, phương trình này có thể không bao hàm hết tất cả các tình huống.

Trong một ứng dụng Internet phong phú Web 2.0 điển hình (thí dụ, Lotus Mashup Maker), trước tiên trình duyệt gửi yêu cầu xác định dạng thức đến máy chủ. Sau khi nhận được dữ liệu phản hồi về xác định dạng thức, trình duyệt sẽ gửi yêu cầu dữ liệu tới máy chủ. Sau đó trình duyệt sẽ biểu hiện trang này cho người sử dụng. Trong mẫu hình này, có nhiều yêu cầu các mục nhỏ chẳng hạn như các tệp tin JavaScript, tệp tin CSS, v.v... Trong một môi trường mạng đường dài, nó có thể gây ra các vấn đề về hiệu năng phía khách mà sẽ ảnh hưởng nghiêm trọng đến trải nghiệm của người sử dụng. Phần lớn các tệp tin là tệp tin tĩnh, có thể được đưa vào bộ nhớ sẵn (cached), nên nếu bạn thêm vào các cache-control (điều khiển nhớ sẵn) chính xác, tiêu đề hết hiệu lực, và một số siêu dữ liệu tiêu đề khác ảnh hưởng đến việc nhớ sẵn của trình duyệt, bạn có thể cải thiện một cách rõ rệt trải nghiệm của người sử dụng.

Cơ chế nhớ sẵn của trình duyệt

Có một số quy tắc ảnh hưởng đến bộ nhớ sẵn của trình duyệt. Trong phần này, chúng ta sẽ thảo luận từng cái một.

Cache-Control

Cache-Control (điều khiển nhớ sẵn) là quy tắc quan trọng nhất. Trường này dùng để xác định rõ các chỉ thị mà toàn bộ các cơ chế nhớ sẵn (caching mechanisms) dọc theo chuỗi yêu cầu/đáp ứng phải tuân theo. Các chỉ thị quy định các hành vi nhằm ngăn chặn bộ nhớ đệm gây nhiễu loạn bất lợi đến yêu cầu hay đáp ứng. Các chỉ thị này thường đè lên các thuật toán nhớ sẵn mặc định. Các chỉ thị về nhớ sẵn là đơn hướng, theo nghĩa là sự hiện diện của một chỉ thị trong một yêu cầu không hàm ý rằng cùng một chỉ thị đó được áp dụng cho đáp ứng.

Định nghĩa cache-control là: Cache-Control = "Cache-Control" ":" cache-directive (chỉ thị nhớ sẵn). Bảng 1 cho thấy các giá trị có thể áp dụng được.

Bảng 1. Các giá trị chỉ thị nhớ sẵn thông dụng
Cache-directive (chỉ thị nhớ sẵn)Mô tả
public (công cộng)Toàn bộ nội dung sẽ được đưa vào bộ nhớ sẵn..
private (riêng tư)Nội dung chỉ được nhớ sẵn trong bộ nhớ sẵn riêng tư.
no-cache (không nhớ sẵn)Toàn bộ nội dung sẽ không được đưa vào bộ nhớ sẵn.
no-store (không lưu trữ)Toàn bộ nội dung sẽ không được nhớ sẵn trong bộ nhớ sẵn hoặc trong một tệp tin tạm Internet.
must-revalidation/proxy-revalidation (phải tái xác nhận / proxy tái xác nhận)Nếu nội dung đã nhớ sẵn đã cũ, phải gửi yêu cầu đến máy chủ/proxy để xác nhận lại nó.
max-age=xxx (xxx là số)Sau xxx giây, nội dung đã nhớ sẵn trở nên cũ

Bảng 2 cho thấy trình duyệt sẽ gửi lại yêu cầu đến máy chủ hay sẽ sử dụng nội dung đã nhớ sẵn trong các tình huống khác nhau.

Bảng 2 cho thấy trình duyệt sẽ gửi lại yêu cầu đến máy chủ hay sẽ sử dụng nội dung đã nhớ sẵn trong các tình huống khác nhau
Chỉ thị nhớ sẵnMở một cửa sổ trình duyệt mớiNhấn Enter trong cửa sổ gốcLàm mớiNhấn nút Back
publicTrình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.
privateTrình duyệt gửi lại yêu cầu đến máy chủ.Khi xuất hiện lần đầu, trình duyệt gửi yêu cầu đến máy chủ. Sau đó nó biểu hiện trang đó từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.
no-cache/no-storeTrình duyệt gửi lại yêu cầu đến máy chủ.Trình duyệt gửi lại yêu cầu đến máy chủ.Trình duyệt gửi lại yêu cầu đến máy chủ.Trình duyệt gửi lại yêu cầu đến máy chủ.
must-revalidation/proxy-revalidationTrình duyệt gửi lại yêu cầu đến máy chủ.Khi xuất hiện lần đầu, trình duyệt gửi yêu cầu đến máy chủ. Sau đó nó biểu hiện trang đó từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ.Trình duyệt biểu hiện trang từ bộ nhớ đệm.
max-age=xxx (xxx là số)Sau xxx giây, trình duyệt gửi lại yêu cầu đến máy chủ.Sau xxx giây, trình duyệt gửi lại yêu cầu đến máy chủ.Trình duyệt gửi lại yêu cầu đến máy chủ.Sau xxx giây, trình duyệt gửi lại yêu cầu đến máy chủ.

Cache-Control là thiết lập quan trọng nhất liên quan đến bộ nhớ sẵn của trình duyệt vì nó đè lên các thiết lập khác chẳng hạn như Expires (Hết hiệu lực) và Last-Modified (đã sửa đổi gần nhất). Hơn nữa, do các hành vi của trình duyệt về cơ bản là như nhau, đặc tính này là cách hiệu quả nhất để xử lý vấn đề nhớ sẵn chung cho nhiều trình duyệt.

Expires

Trường tiêu đề của thực thể Expires đưa ra ngày và giờ mà sau đó thì đáp ứng được coi là cũ. Một mục nhớ sẵn đã cũ không thể được bộ nhớ sẵn (hoặc một bộ nhớ sẵn của proxy hoặc một bộ nhớ sẵn của tác nhân người sử dụng) trả lại một cách bình thường, nếu nó trước tiên không được xác nhận bởi máy chủ gốc (hoặc bởi một bộ nhớ sẵn trung gian mà có một bản sao tươi mới của thực thể). (Ghi chú: chỉ thị điều khiển nhớ sẵn max-age và s-maxage sẽ đè lên tiêu đề Expires.)

Expires nhận các giá trị theo khuôn dạng sau: "Expires: Sun, 08 Nov 2009 03:37:26 GMT". Nếu ngày mà nội dung được xem đến là trước ngày đã cho, nội dung đó không được coi là hết hiệu lực và sẽ được lấy ra từ bộ nhớ sẵn. Nếu ngày đó đã qua, nội dung bị coi là đã hết hiệu lực, và bộ nhớ sẵn sẽ có một hành động nào đó. Bảng 3-6 cho thấy các hành vi khác nhau của trình duyệt đối với các hoạt động khác nhau của người sử dụng.

Bảng 3. Các hành động ứng với hiệu lực của nhớ sẵn khi người sử dụng mở một cửa sổ trình duyệt mới
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không cũ.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.
Nội dung là cũ.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Bảng 4. Các hành động ứng với hiệu lực của nhớ sẵn khi người sử dụng nhấn Enter trong cửa sổ trình duyệt gốc
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không cũ.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.
Nội dung là cũ.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Bảng 5. Các hành động ứng với hiệu lực của nhớ sẵn khi người sử dụng nhấn F5 để làm mới trang
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không cũ.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.
Nội dung là cũ.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Bảng 6. Các hành động ứng với hiệu lực của nhớ sẵn khi người sử dụng nhấn phím Back hoặc Forward
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không cũ.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.
Nội dung là cũ.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.

Ghi chú: Tất cả các trình duyệt đều được giả định chạy với các thiết lập mặc định.

Last-Modified/E-Tag

Giá trị trường tiêu đề của thực thể Last-Modified (đã sửa đổi gần nhất) thường được sử dụng như một bộ xác nhận hiệu lực nhớ sẵn (cache validator). Nói đơn giản, một mục trong bộ nhớ sẵn được coi là có hiệu lực nếu thực thể không bị sửa đổi kể từ thời điểm ứng với giá trị Last-Modified. Giá trị trường tiêu đề đáp ứng ETag, một thẻ thực thể, cung cấp một bộ xác nhận hiệu lực nhớ sẵn “mờ đục”. Điều này cho phép sự xác nhận hiệu lực tin cậy hơn trong các tình huống khi việc lưu trữ ngày tháng sửa đổi là rất bất tiện, khi mà độ phân giải một giây của các giá trị ngày tháng HTTP là không đủ, hoặc khi mà máy chủ gốc muốn tránh các nghịch lý nhất định có thể phát sinh từ việc sử dụng ngày tháng sửa đổi.

Các trình duyệt khác nhau có các hành vi khác nhau đối với cấu hình. Bảng 7-10 cho biết các hành vi trình duyệt khác nhau đối với các hoạt động khác nhau của người sử dụng.

Bảng 7. Hành động ứng với Last-Modified E-Tag khi người sử dụng mở một cửa sổ trình duyệt mới
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không bị thay đổi từ lần truy cập cuối cùng.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.
Nội dung đã bị thay đổi từ lần truy cập cuối cùng.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Bảng 8. Hành động ứng với Last-Modified E-Tag khi người sử dụng nhấn Enter trong cửa sổ trình duyệt gốc
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không bị thay đổi từ lần truy cập cuối cùng.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.
Nội dung đã bị thay đổi từ lần truy cập cuối cùng.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Bảng 9. Hành động ứng với Last-Modified E-Tag khi người sử dụng nhấn F5 để làm mới trang
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không bị thay đổi từ lần truy cập cuối cùng.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 304.
Nội dung đã bị thay đổi từ lần truy cập cuối cùng.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Bảng 10. Áp dụng thiết lập không có bộ nhớ sẵn và người sử dụng nhấn phím Back hoặc Forward
Firefox 3.5IE 8Chrome 3Safari 4
Nội dung không bị thay đổi từ lần truy cập cuối cùng.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.
Nội dung đã bị thay đổi từ lần truy cập cuối cùng.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.

Ghi chú: Tất cả các trình duyệt đều được giả định chạy với các thiết lập mặc định.

Không có thiết lập nào liên quan đến bộ nhớ sẵn

Nếu bạn không xác định bất kỳ thiết lập nào liên quan đến bộ nhớ sẵn, các trình duyệt khác nhau có các hành vi khác nhau, và đôi khi các hành vi của cùng một trình duyệt lại khác nhau khi được chạy một vài lần trong cùng một tình huống. Điều đó có thể trở nên phức tạp. Ngoài ra, một nội dung nào đó không nên đưa vào bộ nhớ sẵn sẽ được nhớ sẵn, nó có thể gây ra các vấn đề về an ninh.

Các trình duyệt khác nhau có các hành vi khác nhau. Bảng 11 cho thấy các hành vi khác nhau của trình duyệt.

Bảng 11. Áp dụng thiết lập không có bộ nhớ sẵn và người sử dụng mở một cửa sổ trình duyệt mới
Firefox 3.5IE 8Chrome 3Safari 4
Mở một trang mới.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Nhấn Enter trong cửa sổ gốc.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Nhấn F5 để làm mới.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.
Nhấn phím Back hoặc Forward.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt biểu hiện trang từ bộ nhớ sẵn.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.Trình duyệt gửi lại yêu cầu đến máy chủ. Mã trả về là 200.

Ghi chú: Tất cả các trình duyệt đều được giả định chạy với các thiết lập mặc định.

Ví dụ áp dụng

Phần này cung cấp các ví dụ về phân tích một điểm Web để xác định hành vi nhớ sẵn đúng đắn bằng cách sử dụng cả công cụ thương mại của IBM và công cụ mã nguồn mở.

Roller Weblogger của Apache

Roller Weblogger của Apache là một ứng dụng Web 2.0 mã nguồn mở. Nó là máy chủ blog Java™ mã nguồn mở điều khiển các blog như blogs.sun.com, blog.usa.gov, IBM Lotus Connections, IBM Developer Works, và nhiều địa chỉ khác.

Trong bài này, chúng tôi chọn các blog của My developerWorks IBM làm ví dụ để giải thích chi tiết các thiết lập bộ nhớ sẵn. Hình 1 cho thấy một ảnh chụp màn hình của trang blog My developerWorks.

Hình 1. Trang blog My developerWorks
Một bảng điều khiển có các thẻ ở bên trái, một danh sách các blog có sẵn ở trung tâm, một danh sách các blog có các ảnh tác giả ở bên phải

Trang này có 62 yêu cầu, hầu hết là png, gif, js, hoặc một số kiểu tệp tin tĩnh khác. Khi người sử dụng truy cập trang này lần đầu tiên, phải mất khoảng 16 giây để hoàn thành việc hiển thị toàn trang trong trình duyệt. Nếu bạn xác định được đúng đắn các thiết lập của bộ nhớ sẵn thì phần lớn các tài nguyên sẽ được đưa vào bộ nhớ sẵn ở phía trình duyệt. Do đó, khi người sử dụng truy cập trang này một lần nữa thì số lượng các yêu cầu cho trang này giảm còn 22, và sẽ chỉ mất khoảng 6 giây để tải. Trải nghiệm của người sử dụng cải thiện một cách đáng kể.

Bây giờ chúng ta sẽ phân tích một số thiết lập quan trọng đối với bộ nhớ sẵn dành cho yêu cầu. Kết quả liên quan đến Weblogger nhìn thấy trong hình 2.

Hình 2. Tiêu đề của đáp ứng từ trang nhà các blog My developerWorks 1
Vạch màu đỏ hai dòng : 'Last-Modified Tue, 13 Oct 2009 05:48:08 GMT' và 'Cache-Control public, must- revalidate, max-age=5'

Trước hết, Cache-Control đè lên các thiết lập Last-Modified, vì vậy trang này có thể được đưa vào bộ nhớ sẵn trên máy cục bộ trong 5 giây, nhưng phải xác nhận hiệu lực lại nếu nội dung là cũ. Khi một người sử dụng truy cập trang này, trình duyệt trước tiên sẽ kiểm tra bộ nhớ sẵn cục bộ để xác định xem các tệp cục bộ đã hết hiệu lực chưa. Nếu nội dung là cũ, trình duyệt sẽ gửi một yêu cầu đến máy chủ để so sánh dấu thời gian Last-Modified. Nếu tệp tin đáp ứng có cùng một nhãn thời gian Last-Modified, máy chủ trả về mã 304 cho trình duyệt để báo rằng tệp tin đáp ứng cũng như nhau.

Hình 3. Tiêu đề của đáp ứng từ trang nhà các blog My developerWorks 2
Các chi tiết từ trang My developerWorks Blog có dòng sau được làm nổi bằng vạch màu đỏ: 'Cache-Control no-cache, max-age=0'

Thiết lập Cache-Control này chỉ ra rằng đáp ứng này không thể đưa vào bộ nhớ sẵn được. Từ quan điểm nghiệp vụ, yêu cầu này được dùng để kiểm tra xác thực và uỷ quyền của người sử dụng, nó không nên được đưa vào bộ nhớ sẵn.

Hình 4. Tiêu đề của đáp ứng từ trang nhà các blog My developerWorks 3
Chỉ ra các dòng sau được làm nổi bằng vạch màu đỏ: 'Cache-Control public, max-age=86400' và 'Last-Modified Sun, 15 Feb 2009 21:48:46 GMT'

Tệp tin đáp ứng này là một tệp thư viện JavaScript rất hiếm khi bị sửa đổi nên nó có độ tuổi tối đa (max-age) bằng một ngày.

Trung tâm Mashup (Mashup Center)

Trung tâm Mashup được thiết kế để cung cấp một giải pháp mashup nghiệp vụ dễ sử dụng, hỗ trợ một quá trình lắp ráp các phần mềm ứng dụng theo tình huống động, sống còn đối với hoạt động của doanh nghiệp (line-of-business) — với các khả năng an ninh và điều quản mà CNTT yêu cầu. Nó gồm có Lotus Mashups và InfoSphere MashupHub. Hình 5 cho thấy một ảnh chụp nhanh của Lotus Mashups đang hoạt động.

Hình 5. Trang chủ Mashup
Phân tích Lotus Mashup của một trang có trình xem dữ liệu về thông tin dừng lại (park) trên đỉnh và ba biểu đồ ví dụ cạnh nhau

Hình 6 và 7 cho thấy các tiêu đề HTTP chọn lọc.

Hình 6. Tiêu đề đáp ứng của trang nhà Mashup 1
Phản hồi từ tiêu đề đáp ứng của trang nhà Mashup 1 với 'Expires Wed, 14 Oct 2009 07:56:36 GMT' và 'Cache-Control public, max-age=86400' in red

Yêu cầu này lấy ra thông tin chủ đề mà có thể được đưa vào bộ nhớ sẵn từ máy chủ.

Hình 7. Tiêu đề đáp ứng của trang nhà Mashup 2
'Đặt Cookie JSESSIONID=0000Fqxf-SY3wIX3UbLOD-Mv0_7:~1; Path=/' 'Expires Thu, 01 Dec 1994 16:00:00 GMT' và 'Cache-Control no-cache=set-cookie, set-cookie2'

Đây là trang chính cá nhân, nó không nên được đưa vào bộ nhớ sẵn. Chú ý giá trị ngày tháng Expires (hết hiệu lực) được đặt ở một ngày rất xa trong quá khứ sao cho nó sẽ luôn được làm mới.

Tóm tắt

Do tính phức tạp của nhiều trình duyệt, các thiết lập bộ nhớ sẵn đúng đắn là rất quan trọng. Trong bài này, chúng tôi đã mô tả các cách làm tốt nhất sau đây:

  • Nhớ sẵn càng nhiều tệp tin càng tốt để có thể giảm bớt thời gian tải về và cải thiện hiệu năng.
  • Hãy sử dụng các chỉ thị điều khiển nhớ sẵn (cache-control) để xác định hành vi bộ nhớ sẵn càng nhiều càng tốt, nhất là đối với IE. Điều này làm giảm bớt sự không nhất quán giữa các trình duyệt khác nhau và là cách tốt nhất để cải thiện hiệu năng.
  • Đừng sử dụng "no settings related with cache." (không có thiết lập nào về bộ nhớ sẵn).
  • Với các thiết lập mặc định, khi được mở mới, trình duyệt IE hầu như luôn luôn gửi một yêu cầu đến phía máy chủ để lấy ra dữ liệu.
  • Nếu một trang không nên đưa vào bộ nhớ sẵn, hãy sử dụng " no-cache, no-store" để chắc chắn rằng trang đó sẽ không được đưa vào bộ nhớ sẵn, nhất là khi dữ liệu đó liên quan đến an ninh hoặc thông tin nhạy cảm.
  • Nếu không cần thiết, không sử dụng yêu cầu kiểu POST, vì nó không thể đưa vào bộ nhớ sẵn được.

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=SOA và dịch vụ Web
ArticleID=619722
ArticleTitle=Cải thiện hiệu năng của các ứng dụng Web 2.0
publish-date=01282011