Thời gian dành cho công việc
Lệnh không treo hoặc chờ đợi một cái gì đó lãng phí thời gian,
nó thực sự làm việc mà mất thời gian; Nó có thể mất thời gian bằng cách thêm nhiều độ trễ mạng nhỏ. Nhưng nó cũng có thể có sự chậm trễ ở phía youtube, điều đó cộng lại.
Rằng chỉ cần thời gian để tải xuống HTML cần thiết;
Lệnh cần thực hiện ít nhất hai yêu cầu HTTP, lần lượt từng yêu cầu và có thể nhiều hơn nữa.
Vì vậy, nếu bất cứ điều gì chậm, nó sẽ nhân với số lượng yêu cầu.
Đối với tôi, phải mất 1,5 giây trên một dòng rất nhanh - đó không phải là xa từ 8 giây.
Làm thế nào để tìm hiểu
Tôi sẽ hiển thị các lệnh tôi đã sử dụng để tìm hiểu:
Để làm cho các ví dụ gọn gàng hơn, chúng tôi sử dụng một biến cho URL:
$ u="https://www.youtube.com/watch?v=k4JGSAmu4lg"
Chúng tôi muốn đo thời lượng của các lệnh; Sử dụng lệnh timecần chú ý không trộn lẫn lệnh và shell dựng sẵn. Chúng tôi sử dụng một chức năng nhỏ để làm cho các dòng ngắn hơn:
$ t(){/usr/bin/time -f 'Time: %es' "$@";}
Lệnh của bạn ghi ra URL của tệp video (bị cắt thành 80 cột):
$ youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Hãy đo thời gian chạy trên máy tính của tôi:
$ t youtube-dl -g "$u"
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?signature=091F68E823
Time: 1.44s
Ok, một giây rưỡi. Nhanh hơn trong câu hỏi, nhưng không nhanh hơn nhiều. Nhưng làm thế nào là nó dành thời gian? Có lẽ nó tải xuống video theo một cách ẩn và loại bỏ nó? Video là 11 phút trong 360p. Chỉ cần tải xuống mà không có tùy chọn nào mất khoảng 13 giây - lâu hơn mười lần.
Cần xem xét kỹ hơn, với tùy chọn dài dòng -v:
$ t youtube-dl -v -g "$u"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', '-g', 'https://www.youtube.com/watch?v=k4J
[debug] Encodings: locale 'UTF-8', fs 'UTF-8', out 'UTF-8', pref: 'UTF-8'
[debug] youtube-dl version 2014.02.06
[debug] Python version 2.7.6 - Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14
[debug] Proxy map: {}
https://r20---sn-cxg7en7d.googlevideo.com/videoplayback?sparams=id%2Cinitcwn
Time: 1.40s
Ồ, có một số độ trễ trước khi dòng '[gỡ lỗi]' được in. Có vẻ như youtube-dldành một chút thời gian cho thiết lập cấu hình của riêng nó. Đó là một phần tư giây hoặc lâu hơn, không phải là sự chậm trễ mà chúng tôi đang tìm kiếm. Nhưng những gì chúng ta có thể học được từ nó là việc youtube-dlthực hiện có thể chậm.
Sau các tin nhắn, không có gì xảy ra cho đến khi URL kết quả được in. Vì vậy, chúng tôi vẫn không thấy phần thú vị.
Tùy chọn -glà "mô phỏng" tải xuống video theo nghĩa là phần phức tạp của việc tìm ra URL bán bí mật đó, in ra, nhưng cuối cùng lại bỏ qua phần tải xuống thực tế. Có một tùy chọn tương tự -skhông xuất URL và có vẻ tương tự khác. Chúng ta hãy giả sử nó đủ tương tự nếu mất khoảng thời gian đó; Chúng ta cần kiểm tra điều đó.
$ t youtube-dl -v -s "$u"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['-v', '-s', 'https://www.youtube.com/watch?v=k4J
[debug] Encodings: locale 'UTF-8', fs 'UTF-8', out 'UTF-8', pref: 'UTF-8'
[debug] youtube-dl version 2014.02.06
[debug] Python version 2.7.6 - Linux-3.13.0-24-generic-x86_64-with-Ubuntu-14
[debug] Proxy map: {}
[youtube] Setting language
[youtube] k4JGSAmu4lg: Downloading webpage
[youtube] k4JGSAmu4lg: Downloading video info webpage
[youtube] k4JGSAmu4lg: Extracting video information
Time: 1.45s
Ok, -smất cùng thời gian với -g, vì vậy bạn có thể thay thế chúng để thử nghiệm.
Thú vị hơn là chúng tôi có đầu ra nhiều hơn bây giờ. Và nó được in với một thời gian thú vị: Các dòng được in với độ trễ tương tự nhau, vì vậy có vẻ như chúng là về các hành động thực sự dành thời gian chúng ta tìm kiếm.
Từ các tin nhắn, ít nhất hai trang web được tải xuống. Nhưng chúng ta có thể giả sử rằng từ "trang" sẽ không có nghĩa là một yêu cầu HTTP và một tài liệu HTML duy nhất.
Chúng ta đã học được gì?
Điểm chính là, công việc của chương trình thực sự tốn thời gian, nó không chờ đợi một cái gì đó, hoặc treo.
Ngoài ra, chúng tôi thấy nhiều bước mất thời gian tương tự. Không có gì nhiều để tính toán, vì vậy, đó là cách làm tròn mạng theo một cách nào đó, cộng lại.
Điều đó có nghĩa là, độ trễ của kết nối của chúng tôi chỉ quan trọng ở đây. Thông lượng của kết nối chỉ là không liên quan.
Nếu bạn sẽ làm cho kết nối internet của mình nhanh hơn để nó có thể truyền dữ liệu với tốc độ gấp đôi - điều đó chẳng giúp ích gì cả. Nhưng nếu bạn có thể có được pingthời gian tốt hơn , điều đó sẽ làm cho nó nhanh hơn nhiều.
Tuy nhiên, đó không phải là về 'ping' cho nhà cung cấp dịch vụ internet của bạn; Thời gian ping tất cả các cách để YouTube là điều quan trọng - và có thể không thể thay đổi.
Thật thú vị, đối với bước tiếp theo, tải xuống video, các yêu cầu cho một đường truyền nhanh hoàn toàn ngược lại: độ trễ hoàn toàn không liên quan và thông lượng thực sự có vấn đề.
Chưa mệt à?
Bạn vẫn muốn biết thêm chi tiết để hiểu thời gian thực sự dành cho cái gì?
Bước tiếp theo sẽ là theo dõi kết nối HTTP; Tôi nghi ngờ rằng nó có thể hiển thị nhiều vòng tròn hơn hai, ví dụ như chuyển hướng. Bạn có thể sử dụng wiresharkhoặc proxy HTTP đăng nhập hoặc stracechỉ đếm các cuộc gọi hệ thống để kết nối hoặc viết.
Cho đến hôm nay, cả hai chúng tôi đã nhìn đủ sâu vào lỗ thỏ của mạng.