Lưu vào bộ nhớ cache, PHP tạo hình thu nhỏ tải chậm

Câu hỏi Phần A (100 tiền thưởng, được trao)
Câu hỏi chính là làm thế nào để tạo trang web này, tải nhanh hơn. Đầu tiên chúng ta cần đọc những thác nước này. Cảm ơn tất cả các đề xuất của bạn về phân tích đọc thác nước. Bằng chứng từ các biểu đồ thác nước khác nhau được hiển thị ở đây là nút cổ chai chính: hình thu nhỏ do PHP tạo. Việc tải dữ liệu không cần giao thức từ CDN do David khuyên dùng đã mang lại tiền thưởng cho tôi, mặc dù làm cho trang web của tôi chỉ nhanh hơn 3% về tổng thể, và trong khi không trả lời nút thắt chính của trang web. Thời gian để làm rõ câu hỏi của tôi, và, một tiền thưởng khác:

Câu hỏi Phần B (100 tiền thưởng, được trao)
Trọng tâm mới bây giờ là giải quyết vấn đề mà 6 hình ảnh jpg gặp phải, điều này gây ra phần lớn sự chậm trễ tải. 6 hình ảnh này là hình thu nhỏ do PHP tạo, nhỏ và chỉ 3 ~ 5 kb, nhưng tải tương đối rất chậm. Lưu ý " thời gian đến byte đầu tiên " trên các biểu đồ khác nhau. Vấn đề vẫn chưa được giải quyết, nhưng một khoản tiền thưởng đã thuộc về James, người đã sửa lỗi tiêu đề mà RedBot đã nhấn mạnh : "Yêu cầu có điều kiện-Nếu điều chỉnh-trả lại toàn bộ nội dung không thay đổi." .

Câu hỏi Phần C (tiền thưởng cuối cùng của tôi: 250 điểm)
Thật không may, sau khi ngay cả lỗi tiêu đề REdbot.org đã được sửa, độ trễ gây ra bởi các hình ảnh do PHP tạo ra vẫn chưa được xử lý. Những gì trên trái đất là những hình thu nhỏ 3 ~ 5Kb nhỏ đang suy nghĩ? Tất cả thông tin tiêu đề đó có thể gửi một tên lửa lên mặt trăng và trở lại. Bất kỳ đề xuất nào về nút cổ chai này đều được đánh giá cao và được coi là câu trả lời có thể, vì tôi bị mắc kẹt trong vấn đề thắt cổ chai này trong bảy tháng nay. Tôi cảm ơn trước.

[Một số thông tin cơ bản trên trang web của tôi: CSS ở trên cùng. JS ở phía dưới (Jquery, JQuery UI, đã mua menu awm / menu.js engine, tab js engine, video swfobject.js) Các dòng màu đen trên hình ảnh thứ hai hiển thị những gì bắt đầu tải. Robot giận dữ là thú cưng của tôi "ZAM". Anh ấy vô hại và thường hạnh phúc hơn.]

Tải thác: Thời gian | http://webpagetest.org

Tên miền song song được nhóm | http://webpagetest.org

Site-Perf Waterfall | http://site-perf.com

Công cụ Pingdom Thác nước | http://tools.pingdom.com

Thác nước GTmetrix | http://gtmetrix.com

Đầu tiên, sử dụng nhiều tên miền đó yêu cầu một số tra cứu DNS. Bạn nên kết hợp nhiều hình ảnh đó thành một sprite thay vì truyền bá các yêu cầu.

Thứ hai, khi tôi tải trang của bạn, tôi thấy hầu hết các chặn (~ 1.25s) trên all.js. Tôi thấy điều đó bắt đầu với (một phiên bản cũ của) jQuery. Bạn nên tham khảo từ Google CDN, để không chỉ giảm thời gian tải mà còn có thể tránh hoàn toàn yêu cầu HTTP cho nó .

Cụ thể, các thư viện jQuery và jQuery UI mới nhất có thể được tham chiếu tại các URL này (xem bài đăng này nếu bạn quan tâm tại sao tôi bỏ qua http:):

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

Nếu bạn đang sử dụng một trong các chủ đề UI UI mặc định, bạn cũng có thể lấy CSS và hình ảnh của nó ra khỏi Google CDN .

Với việc lưu trữ jQuery được tối ưu hóa, bạn cũng nên kết hợp awmlib2.jsvà tooltiplib.jsthành một tệp duy nhất.

Nếu bạn giải quyết những điều đó, bạn sẽ thấy một sự cải thiện đáng kể.

Tôi đã có một vấn đề tương tự cách đây vài ngày và tôi tìm thấy head.js . Đó là một Plugin Javascript cho phép bạn tải tất cả các tệp JS song song. Mong rằng sẽ giúp.

Tôi xa một chuyên gia nhưng ...

Liên quan đến vấn đề này: "Yêu cầu có điều kiện If-Modified-Because trả về toàn bộ nội dung không thay đổi." và ý kiến ​​của tôi.

Mã được sử dụng để tạo Thumbnails nên được kiểm tra như sau:

1. Có một phiên bản lưu trữ của hình thu nhỏ.
2. Là phiên bản lưu trữ mới hơn hình ảnh gốc.

Nếu một trong hai điều này là sai, hình thu nhỏ sẽ được tạo và trả lại bất kể điều gì. Nếu cả hai đều đúng thì nên thực hiện kiểm tra sau:

1. Có tiêu đề HTTP_IF_MODIFIED_SINCE không
2. Thời gian sửa đổi lần cuối của phiên bản được lưu trong bộ nhớ cache có giống với HTTP_IF_MODIFIED_SINCE không

Nếu một trong hai là sai, hình thu nhỏ được lưu trong bộ nhớ cache sẽ được trả về.

Nếu cả hai điều này đều đúng thì phải trả lại trạng thái 304 http. Tôi không chắc chắn nếu nó được yêu cầu nhưng cá nhân tôi cũng trả lại các tiêu đề Kiểm soát bộ đệm, Hết hạn và Sửa đổi lần cuối cùng với 304.

Liên quan đến GZipping, tôi đã được thông báo rằng không cần phải có hình ảnh GZip nên bỏ qua phần bình luận đó.

Chỉnh sửa: Tôi đã không nhận thấy sự bổ sung của bạn vào bài viết của bạn.

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

Tôi cũng chắc chắn rằng mã của bạn cần kiểm tra tiêu đề HTTP_IF_MODIFIED_SINCE và phản ứng với nó. Chỉ cần đặt các tiêu đề này và tệp .htaccess của bạn sẽ không cung cấp kết quả được yêu cầu.

Tôi nghĩ bạn cần một cái gì đó như thế này:

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

Ồ, thật khó để giải thích mọi thứ bằng hình ảnh đó .. Nhưng ở đây, một số cố gắng:

• các tệp 33-36 tải muộn, vì chúng được tải động trong swf và swf (25) được tải hoàn toàn trước khi tải bất kỳ nội dung bổ sung nào
• các tệp 20 & 21 có thể (tôi không biết, vì tôi không biết mã của bạn) các thư viện được tải bởi all.js (11), nhưng để 11 thực thi, nó chờ toàn bộ trang (và tài sản) để tải (bạn nên thay đổi nó thành dom rồi)
• hai tệp 22-32 được tải bởi hai thư viện đó, một lần nữa sau khi chúng được tải hoàn toàn

Chỉ là một phỏng đoán đơn giản vì loại phân tích này đòi hỏi rất nhiều thử nghiệm A / B: tên miền .ch của bạn dường như khó tiếp cận (các dải màu xanh lục dài trước khi byte đầu tiên xuất hiện).

Điều này có nghĩa là trang web .ch được lưu trữ kém hoặc ISP của bạn không có tuyến đường tốt đến họ.

Với các sơ đồ, điều này có thể giải thích một hit hiệu suất lớn.

Trên một mặt lưu ý, đó là mát mẻ này cụ cuzillion mà có thể giúp bạn sắp xếp ra những thứ phụ thuộc vào đặt hàng của bạn của ressource tải.

Hãy thử chạy các bài kiểm tra Y! Slow và Tốc độ trang trên trang web / trang của bạn và làm theo các hướng dẫn để loại bỏ các tắc nghẽn hiệu suất có thể có. Bạn sẽ nhận được hiệu suất rất lớn khi bạn đạt điểm cao hơn ở Y! Slow hoặc Tốc độ trang.

Những xét nghiệm này sẽ cho bạn biết những gì sai và những gì cần thay đổi.

Vì vậy, tập lệnh PHP của bạn đang tạo hình thu nhỏ trên mỗi lần tải trang? Trước hết, nếu hình ảnh được thu nhỏ không thay đổi thường xuyên, bạn có thể thiết lập bộ đệm sao cho chúng không phải được phân tích cú pháp mỗi khi tải trang không? Thứ hai, tập lệnh PHP của bạn có sử dụng cái gì đó như imagecopyresampled()để tạo hình thu nhỏ không? Đó là một nhược điểm không tầm thường và tập lệnh PHP sẽ không trả lại bất cứ điều gì cho đến khi hoàn thành mọi thứ. Sử dụng imagecopymerged()thay thế sẽ làm giảm chất lượng của hình ảnh, nhưng tăng tốc quá trình. Và bạn đang giảm bao nhiêu? Những hình thu nhỏ này có kích thước 5% so với ảnh gốc hay 50%? Một kích thước lớn hơn của hình ảnh gốc có thể dẫn đến sự chậm lại do tập lệnh PHP phải lấy hình ảnh gốc trong bộ nhớ trước khi nó có thể thu nhỏ nó và tạo ra một hình thu nhỏ nhỏ hơn.

Tôi đã tìm thấy URL của trang web của bạn và kiểm tra một tệp jpg riêng lẻ từ trang chủ. Mặc dù thời gian tải là hợp lý bây giờ (161ms), nhưng nó đang chờ 126ms, quá nhiều.

Tất cả các tiêu đề được sửa đổi lần cuối của bạn đều được đặt thành Sat, ngày 1 tháng 1 năm 2011 12:00:00 GMT, có vẻ quá "tròn" để trở thành ngày thực sự của thế hệ ;-)

Vì Kiểm soát bộ đệm là "công khai, tuổi tối đa = 14515200", các tiêu đề được sửa đổi lần cuối tùy ý sẽ có thể gây ra sự cố sau 168 ngày.

Dù sao, đây không phải là lý do thực sự cho sự chậm trễ.

Bạn phải kiểm tra xem trình tạo hình thu nhỏ của bạn làm gì khi hình thu nhỏ đã tồn tại và những gì có thể tiêu tốn rất nhiều thời gian để kiểm tra và phân phối hình ảnh.

Bạn có thể cài đặt xdebug để cấu hình tập lệnh và xem các nút thắt cổ chai ở đâu.

Có thể toàn bộ điều sử dụng một khung hoặc kết nối với một số cơ sở dữ liệu không có gì. Tôi đã thấy mysql_connect () rất chậm trên một số máy chủ, chủ yếu là do họ đang kết nối bằng TCP và không phải socket, đôi khi có một số vấn đề về DNS.

Tôi hiểu rằng bạn không thể đăng máy phát điện trả tiền của mình ở đây nhưng tôi sợ có quá nhiều vấn đề có thể xảy ra ...

Nếu không có lý do thực sự tốt (thường là không có) thì hình ảnh của bạn không nên gọi trình thông dịch PHP.

Tạo quy tắc viết lại cho máy chủ web của bạn lưu trữ hình ảnh trực tiếp nếu nó được tìm thấy trên hệ thống tệp. Nếu không, hãy chuyển hướng đến tập lệnh PHP của bạn để tạo hình ảnh. Khi bạn chỉnh sửa hình ảnh, thay đổi tên tệp hình ảnh để buộc người dùng có phiên bản được lưu trong bộ nhớ cache để tìm nạp hình ảnh mới được chỉnh sửa.

Nếu nó không hoạt động thì ít nhất bây giờ bạn sẽ không liên quan gì đến cách tạo và kiểm tra hình ảnh.

Điều tra việc sử dụng dữ liệu phiên của PHP. Có lẽ (chỉ có thể), tập lệnh PHP tạo hình ảnh đang chờ để khóa dữ liệu phiên, bị khóa bởi trang chính vẫn hiển thị hoặc các tập lệnh kết xuất hình ảnh khác. Điều này sẽ làm cho tất cả các tối ưu hóa JavaScript / trình duyệt gần như không liên quan, vì trình duyệt đang chờ máy chủ.

PHP khóa dữ liệu phiên cho mọi tập lệnh đang chạy, từ khi bắt đầu xử lý phiên, đến khi tập lệnh kết thúc hoặc khi session_write_close () được gọi. Điều này có hiệu quả nối tiếp mọi thứ. Kiểm tra trang PHP trên các phiên, đặc biệt là các bình luận, như trang này .

Đây chỉ là một phỏng đoán hoang dã vì tôi đã không xem mã của bạn nhưng tôi nghi ngờ các phiên có thể đóng vai trò ở đây, sau đây là từ mục Hướng dẫn sử dụng PHP trên session_write_close():

Dữ liệu phiên thường được lưu trữ sau khi tập lệnh của bạn kết thúc mà không cần gọi session_write_c Đóng (), nhưng vì dữ liệu phiên bị khóa để ngăn việc ghi đồng thời, chỉ một tập lệnh có thể hoạt động trên phiên bất cứ lúc nào. Khi sử dụng bộ khung cùng với phiên, bạn sẽ trải nghiệm các khung tải từng cái một do khóa này. Bạn có thể giảm thời gian cần thiết để tải tất cả các khung bằng cách kết thúc phiên ngay khi tất cả các thay đổi đối với các biến của phiên được thực hiện.

Như tôi đã nói, tôi không biết mã của bạn đang làm gì nhưng những biểu đồ đó có vẻ đáng ngờ. Tôi gặp vấn đề tương tự khi tôi mã hóa chức năng phục vụ tập tin nhiều phần và tôi gặp vấn đề tương tự. Khi phục vụ một tệp lớn, tôi không thể làm cho chức năng nhiều phần hoạt động và tôi không thể mở một trang khác cho đến khi quá trình tải xuống hoàn tất. Gọi session_write_close()cố định cả hai vấn đề của tôi.

Bạn đã thử thay thế các trang được tạo bởi php bằng các hình ảnh thông thường để xem có sự khác biệt nào không? Vấn đề có thể xảy ra - một lỗi trong mã php của bạn dẫn đến việc tái tạo hình thu nhỏ theo mỗi lần gọi máy chủ - sự chậm trễ trong mã của bạn (ngủ ()?) Liên quan đến sự cố đồng hồ - một vấn đề khó khăn gây ra tình trạng chủng tộc rất xấu vì tất cả các hình thu nhỏ được tải / tạo cùng một lúc.

Tôi nghĩ thay vì sử dụng tập lệnh tạo hình thu nhỏ đó, bạn phải thử TinySRC để tạo nhanh hình thu nhỏ được lưu trữ nhanh và được lưu trữ trên đám mây. Nó có API rất đơn giản và dễ sử dụng, bạn có thể sử dụng như: -

http://i.tinysrc.mobi/ [chiều cao] / [chiều rộng] /http://domain.tld/path_to_img.jpg

[width] (tùy chọn): - Đây là chiều rộng tính bằng pixel (ghi đè kích thước thích ứng hoặc kích thước gia đình). Nếu có tiền tố là '-' hoặc 'x', nó sẽ trừ đi hoặc thu nhỏ lại theo tỷ lệ phần trăm, kích thước được xác định.

[height] (tùy chọn): - Đây là chiều cao tính bằng pixel, nếu chiều rộng cũng có mặt. Nó cũng ghi đè kích thước thích ứng hoặc kích thước gia đình và có thể được thêm tiền tố với '-' hoặc 'x'.

Bạn có thể kiểm tra tóm tắt API tại đây

Câu hỏi thường gặp

TinySrc có giá bao nhiêu?

Không có gì.

Khi nào tôi có thể bắt đầu sử dụng tinySrc?

Hiện nay.

Làm thế nào đáng tin cậy là dịch vụ?

Chúng tôi không đảm bảo về dịch vụ tinySrc. Tuy nhiên, nó chạy trên một cơ sở hạ tầng đám mây phân tán lớn , do đó nó cung cấp tính sẵn sàng cao trên toàn thế giới. Nó nên đủ cho tất cả các nhu cầu của bạn.

Nó nhanh như thế nào

tinySrc lưu trữ hình ảnh đã thay đổi kích thước trong bộ nhớ và trong kho dữ liệu của chúng tôi trong tối đa 24 giờ và nó sẽ không tải hình ảnh gốc của bạn mỗi lần. Điều này làm cho các dịch vụ nhanh chóng từ quan điểm của người dùng. (Và giảm tải máy chủ của bạn như một hiệu ứng phụ đẹp.)

Chúc may mắn. Chỉ là một gợi ý, vì bạn không cho chúng tôi xem mã: p

Vì một số trình duyệt chỉ tải xuống 2 lượt tải xuống tương đương cho mỗi tên miền, bạn không thể thêm các tên miền bổ sung để loại bỏ các yêu cầu qua hai đến ba tên máy chủ khác nhau. ví dụ: 1.imagecdn.com 2.imagecdn.com

Trước hết, bạn cần xử lý If-Modified-Sincecác yêu cầu và một cách thích hợp, như James nói. Lỗi đó nói rằng: "Khi tôi hỏi máy chủ của bạn nếu hình ảnh đó được sửa đổi từ lần trước, nó sẽ gửi toàn bộ hình ảnh thay vì có / không đơn giản".

Thời gian giữa kết nối và byte đầu tiên thường là thời gian tập lệnh PHP của bạn chạy. Rõ ràng là một cái gì đó đang xảy ra khi kịch bản đó bắt đầu chạy.

1. Bạn đã xem xét hồ sơ nó? Nó có thể có một số vấn đề.
2. Kết hợp với vấn đề trên, tập lệnh của bạn có thể chạy nhiều lần hơn mức cần thiết. Lý tưởng nhất là chỉ tạo ngón tay cái nếu hình ảnh gốc được sửa đổi và gửi ngón tay cái được lưu trong bộ nhớ cache cho mọi yêu cầu khác. Bạn đã kiểm tra xem tập lệnh có tạo ra các hình ảnh không cần thiết không (ví dụ cho mỗi yêu cầu)?

Tạo tiêu đề thích hợp thông qua ứng dụng là một chút khó khăn, cộng với việc chúng có thể bị ghi đè bởi máy chủ. Và bạn có thể bị lạm dụng vì bất kỳ ai gửi một số tiêu đề yêu cầu không có bộ đệm sẽ khiến trình tạo hình thu nhỏ của bạn chạy liên tục (và tăng tải). Vì vậy, nếu có thể, hãy cố gắng lưu những ngón tay cái được tạo ra đó, gọi hình ảnh đã lưu trực tiếp từ các trang của bạn và quản lý các tiêu đề từ đó .htaccess. Trong trường hợp này, bạn thậm chí sẽ không cần bất cứ thứ gì trong .htaccessmáy chủ của mình nếu máy chủ của bạn được cấu hình đúng.

Ngoài những điều này, bạn có thể áp dụng một số ý tưởng tối ưu hóa sáng từ các phần hiệu suất của câu hỏi SO đẹp tổng thể này về cách làm trang web đúng cách , như chia tài nguyên của bạn thành tên miền phụ không cần nấu, v.v. Nhưng dù sao, hình ảnh 3k không nên mất một giây để tải, điều này là rõ ràng khi so sánh với các mục khác trong biểu đồ. Bạn nên cố gắng phát hiện vấn đề trước khi tối ưu hóa.

Bạn đã thử thiết lập một số tên miền phụ trong máy chủ web NGINX đặc biệt để phục vụ dữ liệu tĩnh như hình ảnh và biểu định kiểu chưa? Một cái gì đó hữu ích có thể đã được tìm thấy trong chủ đề này .

Về hình thu nhỏ bị trì hoãn, hãy thử đặt một cuộc gọi để tuôn ra () ngay sau cuộc gọi cuối cùng đến tiêu đề () trong tập lệnh tạo hình thu nhỏ của bạn. Sau khi hoàn thành, hãy tạo lại biểu đồ thác nước của bạn và xem liệu độ trễ hiện có trên cơ thể thay vì các tiêu đề. Nếu vậy, bạn cần xem xét logic để tạo và / hoặc xuất dữ liệu hình ảnh.

Kịch bản xử lý các hình thu nhỏ hy vọng sẽ sử dụng một số loại bộ đệm để bất kỳ hành động nào xảy ra đối với hình ảnh bạn đang phục vụ sẽ chỉ xảy ra khi thực sự cần thiết. Có vẻ như một số hoạt động đắt tiền đang diễn ra mỗi khi bạn phục vụ các hình thu nhỏ đang trì hoãn bất kỳ đầu ra nào (bao gồm các tiêu đề) từ tập lệnh.

Phần lớn vấn đề chậm là TTFB (Thời gian đến byte đầu tiên) của bạn quá cao. Đây là một vấn đề khó giải quyết mà không thân mật với các tệp cấu hình máy chủ, mã và phần cứng cơ bản của bạn, nhưng tôi có thể thấy nó tràn lan theo mọi yêu cầu. Bạn có quá nhiều thanh màu xanh lá cây (xấu) và rất ít thanh màu xanh lam (tốt). Bạn có thể muốn ngừng tối ưu hóa frontend một chút, vì tôi tin rằng bạn đã làm được nhiều việc trong lĩnh vực đó. Bất chấp câu ngạn ngữ rằng " 80% -90% thời gian phản hồi của người dùng cuối được dành cho lối vào ", tôi tin rằng bạn đang xảy ra trong phần phụ trợ.

TTFB là công cụ phụ trợ, công cụ máy chủ, xử lý trước khi xuất và bắt tay.

Thời gian thực thi mã của bạn để tìm nội dung chậm như truy vấn cơ sở dữ liệu chậm, thời gian nhập và thoát hàm / phương thức để tìm hàm chậm. Nếu bạn sử dụng php, hãy thử Firephp . Đôi khi, một hoặc hai truy vấn chậm được chạy trong khi khởi động hoặc khởi tạo như kéo thông tin phiên hoặc kiểm tra xác thực và những gì không. Tối ưu hóa các truy vấn có thể dẫn đến một số lợi ích hoàn hảo tốt. Đôi khi mã được chạy bằng cách sử dụng php preend hoặc spl autoload để chúng chạy trên mọi thứ. Những lần khác, nó có thể được cấu hình bởi apache conf và điều chỉnh để tiết kiệm trong ngày.

Hãy tìm những vòng lặp không hiệu quả. Tìm kiếm các cuộc gọi tìm nạp chậm của bộ nhớ cache hoặc các hoạt động i / o chậm gây ra bởi các ổ đĩa bị lỗi hoặc sử dụng không gian đĩa cao. Tìm kiếm tập quán bộ nhớ và những gì đang được sử dụng và ở đâu. Chạy thử nghiệm lặp lại 10 lần trên webpagetest trên một hình ảnh hoặc tệp chỉ sử dụng chế độ xem đầu tiên từ các vị trí khác nhau trên thế giới và không phải cùng một vị trí. Và đọc nhật ký truy cập và lỗi của bạn, quá nhiều nhà phát triển bỏ qua chúng và chỉ dựa vào các lỗi xuất hiện trên màn hình. Nếu máy chủ web của bạn có hỗ trợ, hãy yêu cầu họ giúp đỡ, nếu họ không thể lịch sự yêu cầu họ giúp đỡ, điều đó sẽ không gây hại.

Bạn có thể thử Tìm nạp trước DNS để chống lại nhiều tên miền và tài nguyên, http://html5boilerplate.com/docs/DNS-Prefetching/

Là máy chủ của riêng bạn một máy chủ tốt / tốt? Đôi khi một máy chủ tốt hơn có thể giải quyết rất nhiều vấn đề. Tôi là một fan hâm mộ của ' phần cứng là rẻ, lập trình viên là đắt tiền ', nếu bạn có cơ hội và tiền nâng cấp một máy chủ. Và / Hoặc sử dụng CDN như maxcdn hoặc cloudflare hoặc tương tự.

Chúc may mắn!

(ps tôi không làm việc cho bất kỳ công ty nào trong số này. Ngoài ra, liên kết đám mây ở trên sẽ lập luận rằng TTFB không quan trọng, tôi đã ném nó vào đó để bạn có thể nhận thêm một lần nữa.)

Xin lỗi để nói, bạn cung cấp cho một vài dữ liệu. Và bạn đã có một số gợi ý tốt.

Làm thế nào bạn phục vụ những hình ảnh? Nếu bạn phát trực tuyến những thứ đó qua PHP thì bạn đang làm một việc rất tệ, ngay cả khi chúng đã được tạo.

KHÔNG BAO GIỜ HÌNH ẢNH STREAM VỚI PHP. Nó sẽ làm chậm máy chủ của bạn, bất kể bạn sử dụng nó như thế nào.

Đặt chúng trong một thư mục có thể truy cập, với một URI có ý nghĩa. Sau đó gọi họ trực tiếp với URI thực sự của họ. Nếu bạn cần trên thế hệ bay, bạn nên đặt một .htaccess trong thư mục hình ảnh chuyển hướng đến tập lệnh php của trình tạo chỉ khi thiếu hình ảnh yêu cầu. (đây được gọi là chiến lược cache theo yêu cầu).

Làm như vậy sẽ sửa phiên php, proxy trình duyệt, bộ nhớ đệm, ETAGS, bất cứ thứ gì cùng một lúc.

WP-Supercache sử dụng chiến lược này, nếu được cấu hình đúng.

Tôi đã viết cái này cách đây một thời gian ( http://code.google.com.vn/p/cache-on-request/source/detail?r=8 ), bản sửa đổi cuối cùng đã bị hỏng, nhưng tôi đoán 8 hoặc ít hơn sẽ hoạt động và bạn có thể lấy .htaccess làm ví dụ chỉ để kiểm tra mọi thứ (mặc dù có nhiều cách tốt hơn để định cấu hình .htaccess so với cách tôi đã sử dụng).

Tôi đã mô tả chiến lược đó trong bài đăng trên blog này ( http://www.stefanoforenza.com/need-for-cache/ ). Nó có thể được viết xấu nhưng nó có thể giúp làm rõ mọi thứ.

Đọc thêm: http://meta.wikidia.org/wiki/404_handler_caching