亚洲国产精品无码久久大片,亚洲AV无码乱码麻豆精品国产,亚洲品质自拍网站,少妇伦子伦精品无码STYLES,国产精久久久久久久

　　前言
　　在開(kāi)始之前，想說(shuō)下抱歉，如果是抱著(zhù)解決問(wèn)題的看法進(jìn)來(lái)的話(huà)，對不起，讓你沮喪了，本文不會(huì )講解如何解決這問(wèn)題，因為研制說(shuō)不處理了，但本文會(huì )介紹是怎樣一街過(guò)來(lái)的，如果還感興趣，請繼續看~
　　上幾篇文章有介紹到，jb在負責一個(gè)seo的項目，關(guān)于seo是哪些，請點(diǎn)擊這兒查看;
　　自從項目上線(xiàn)后，一波三折，遇到不少坑，其中在前面那篇文章里提到到，這里就不說(shuō)明了；
　　某三天，運營(yíng)老大貼了如此一張圖：
　　(把日期打碼了，問(wèn)題不大)
　　從這個(gè)截圖數據上看，爬取歷時(shí)平均值932ms，最小值106ms，怎么看都認為合理，只是那種最大值300s的，看上去好別扭。。
　　接著(zhù)，我們用里面的內容辯解說(shuō)，平均值看上去很正常，應該沒(méi)啥問(wèn)題吧？
　　運營(yíng)老大說(shuō)，但是我們愈加關(guān)心最大值，以前的產(chǎn)品都沒(méi)有這些情況的，最大值都不超過(guò)1000的，基本都是500-1000ms;
　　從這時(shí)起，開(kāi)始get不同技能了~
　　網(wǎng)站介紹
　　百度數據
　　因為這個(gè)爬蟲(chóng)是百度的，而這個(gè)爬取歷時(shí)的數據，也是百度提供的，理所當然要瞧瞧，這個(gè)值是如何算下來(lái)的，遺憾的是，百度的平臺沒(méi)有任何與爬取歷時(shí)有關(guān)的信息;
　　既然這么，那就Google，內容為：百度爬蟲(chóng)歷時(shí)太長(cháng)，在搜索的結果上面有很多百度爬蟲(chóng)的介紹，但是并沒(méi)有任何一條有直接講解到這個(gè)百度爬蟲(chóng)歷時(shí)是如何算的~
　　問(wèn)了好多同學(xué)，甚至是百度內容朋友，都不清楚，所以，這塊數據對于開(kāi)發(fā)者來(lái)說(shuō)，是一個(gè)全黑盒的玩意兒;
　　既然這么，我們就先假定，這個(gè)時(shí)間是指發(fā)起懇求后，到獲取響應且渲染完內容的時(shí)間；
　　后端日志
　　拿到問(wèn)題，第一反應就是使前端的朋友查下日志，看是不是真的出現300+s的情況， 但實(shí)際查詢(xún)后發(fā)覺(jué)，并沒(méi)有出現此類(lèi)情況，后端的日志顯示插口返回都很快，基本是ms級別，秒都談不上，更何況300s?
　　既然前端沒(méi)有問(wèn)題，那就肯定是后端了；
　　前端
　　既然懷疑是后端問(wèn)題，那我們就嘗試再現下吧，
　　直接用Chrome按F12步入開(kāi)發(fā)者模式， 直接刷新試試，手動(dòng)重復幾十次，基本都是2這個(gè)區間內，而且首頁(yè)資源非常多，如果首頁(yè)都沒(méi)問(wèn)題，其他頁(yè)面就更不會(huì )有問(wèn)題了；
　?。ㄊ謩?dòng)重試中） 突然會(huì )發(fā)覺(jué)一次歷時(shí)比較久的，長(cháng)達10s，看了下時(shí)間的占比，如下：
　　咦，一個(gè)圖片用了3s？什么鬼？ 而且會(huì )發(fā)覺(jué)，有些圖片size會(huì )高達4M?
　　瞬間把端倪之前了資源這塊，為了驗證我們的看法，使用了webpagetest工具來(lái)驗證下網(wǎng)頁(yè)的歷時(shí)，這個(gè)工具是個(gè)網(wǎng)頁(yè)，直接打開(kāi)輸入須要測試的網(wǎng)址即可；
　　先來(lái)一次結果：
　　直接看底部的截圖，嚶嚶嚶，fully loaded time竟然去到16S了，這肯定有問(wèn)題，接著(zhù)繼續看：
　　嘖嘖嘖，一個(gè)圖片的下載用了8S，這性能不太行啊，而且有些圖片的size的確很大，所以第一反應是，圖片壓縮，減少size，另外，網(wǎng)站本身會(huì )時(shí)常出現404，這塊本身都會(huì )影響到seo的收錄早已爬取，在這些情況，不得不懷疑任何一切相關(guān)的，因此就擼起衣袖開(kāi)始干了：
　　1）資源壓縮，部分業(yè)務(wù)邏輯合并，減少懇求數目，緩存機制
　　2）出現404的緣由是，當初設計時(shí)，如果諸多插口里某一插口異常，前端直接判斷偉404，因此把這塊邏輯更改下，接口異常不會(huì )造成后端跳404，最多是數據不展示；
　　開(kāi)發(fā)、測試、上線(xiàn)、絕望，一潑熱水澆出來(lái)百度爬蟲(chóng)日志，大家都萎了；
　　幾個(gè)臭皮匠一起討論了半天，也沒(méi)個(gè)推論，此時(shí)百度爬蟲(chóng)日志，部分朋友認為這是個(gè)費力不討好的工作，慢慢的開(kāi)始淡出這個(gè)工作了，有點(diǎn)所謂的選擇性失盲了；
　　再次剖析
　　即使營(yíng)運老大、老板天天問(wèn)，但是仍然沒(méi)有任何進(jìn)展，這問(wèn)題，就如此坑人？
　　此時(shí)，某拍毛片朋友(php)主動(dòng)（被迫）出來(lái)跟進(jìn)這個(gè)問(wèn)題;
　　啪啪啪好幾天過(guò)去了，突然某三天，釘釘群了，該拍毛片朋友給出一個(gè)方向，
　　這個(gè)問(wèn)題有初步懷疑點(diǎn)了，那就是服務(wù)器帶寬問(wèn)題引起的，解決方案就是臨時(shí)擴充帶寬；
　　怎么剖析的？
　　既然能給出這樣的推論，肯定是有數據支撐他的，那我們就來(lái)瞧瞧，是哪些支撐他這個(gè)推論；
　　依舊是先剖析后臺日志，過(guò)濾百度過(guò)來(lái)的懇求，
　　某一條有40幾個(gè)，然后再按照插口響應超過(guò)10S的方法進(jìn)行過(guò)來(lái)，發(fā)現剩下2條日志：
　　從日志上看，基本歷時(shí)都在18S，也讀是百度爬蟲(chóng)那過(guò)來(lái)的；
　　既然都有日志了，那就模擬下瞧瞧是不是真要那么久，這里的模擬爬蟲(chóng)用的是百度熊掌號自帶的工具：
　　輸入出現問(wèn)題的地址，結果如下：
　　只須要關(guān)注最下邊的下載時(shí)長(cháng)：0.166s，重復多幾次，依然這么;
　　這個(gè)后臺的日志不一樣，那就說(shuō)明，這個(gè)問(wèn)題不是必現的，而且有特定場(chǎng)景引起的；
　　從后臺的日志上看，剛爬了幾次的日志，也的確跟百度上顯示的類(lèi)似，那說(shuō)明百度上的時(shí)長(cháng)是可信的：
　　從上圖可看出，最大一次也不超過(guò)3S，與一開(kāi)始反饋的300S相差甚遠；
　　此時(shí)再去看下服務(wù)器的情況：
　　服務(wù)器是5M的帶寬，從日志上看，的確有部份時(shí)間段是超過(guò)了5M，而且出現爬取比較慢的時(shí)間正好對的上服務(wù)器超過(guò)5M的時(shí)間；
　　因此該朋友才敢說(shuō)，懷疑是因為帶寬，雖然聽(tīng)起來(lái)有點(diǎn)巧合，但是在萬(wàn)般無(wú)策的情況下，只能相信是這些巧合了；
　　然后就調整帶寬，觀(guān)察幾天，畢竟爬蟲(chóng)這些東西是靠他人的，心急不來(lái)，在等待的期間，做了4件事：
　　1） 資料查詢(xún)借鑒
　　導致抓取時(shí)間達到幾十萬(wàn)的情況
　　1.2） 抓取該頁(yè)面的時(shí)侯部份圖片未能抓取到；
　　1.3） 鏈接超時(shí)；
　　1.4） 百度內部調整造成；
　　從結果看，個(gè)人傾向1、2可能性大；
　　2）跟后端朋友溝通下，后端返回的18S，是如何的標準？
　　回到文章頂部，有提到到這個(gè)網(wǎng)站架構是node+nginx+php,那這18S， 按照理解，應該就是Php返回到nginx的時(shí)間，那nginx到node中間傳輸會(huì )不會(huì )也有耗損，比如跟網(wǎng)速有關(guān)系、服務(wù)器性能等，都有可能有折損，然后node接收后，再渲染顯示，等渲染完成，爬蟲(chóng)才覺(jué)得整個(gè)過(guò)程完畢？（前面提到到，這里默認爬蟲(chóng)規則是開(kāi)始懇求到渲染完畢，但實(shí)際未知）
　　當時(shí)提及一個(gè)疑惑，假如說(shuō)，node或則nginx有問(wèn)題了，那是不是都會(huì )出現歷時(shí)太長(cháng)的情況？
　　但當時(shí)由于沒(méi)數據支撐，大家都認為，嗯，有這些可能，這種看法一閃而過(guò)，但是有哪些緣由造成node或則nginx有問(wèn)題，真沒(méi)想到；
　　事實(shí)回頭看，猜對了，的確是node出問(wèn)題引起；
　　當也由于當時(shí)沒(méi)想到，后面才更好的梳理了；
　　3）影響網(wǎng)路傳輸的緣由有什么？ 找到一個(gè)答案，不知道對不對，僅參考：
　　最重要的兩點(diǎn)就是帶寬，并發(fā)數，帶寬驗證是沒(méi)影響，那這個(gè)會(huì )跟并發(fā)數有關(guān)嗎？
　　再次梳理
　　回到正文，上線(xiàn)幾天后發(fā)覺(jué)，還是不行，依然有問(wèn)題，說(shuō)明帶寬不是問(wèn)題點(diǎn)，那如何辦？
　　上面提到到，既然帶寬不是問(wèn)題，那就可能跟并發(fā)數有關(guān)系了，而且爬蟲(chóng)過(guò)來(lái)肯定也是并發(fā)如此過(guò)，所以就把端倪對準并發(fā)了；
　　但是在實(shí)際去看并發(fā)之前，還是把邏輯梳理了一遍：
　　根據前面的信息，現在從前端nginx可以get到的是，PHP和前端處理時(shí)間特別快，基本在0.1-0.5之間；
　　從流程上來(lái)看，前端負責接收和返回前端的是nojs,所以有理由懷疑，異常發(fā)生的誘因是在node層，結合前面的并發(fā)可能性，有可能是多并發(fā)，導致nojs進(jìn)程cpu占用負載，導致處理時(shí)間加長(cháng)。
　　這樣也能挺好地解釋?zhuān)瑸槭裁从械臅r(shí)侯，抓取的時(shí)間只須要0.1到0.5，但是有時(shí)卻須要消耗歷時(shí)20萬(wàn)毫秒；
　　既然有所懷疑，那就開(kāi)始干吧~
　　實(shí)驗
　　本次的實(shí)驗目的很簡(jiǎn)單，就是在高并發(fā)的環(huán)境下，進(jìn)行百度爬取的行為，看看數據是不是正常；
　　工具的選擇，不苦惱，壓測用apache ab，原因命令行，便捷，爬蟲(chóng)就直接用百度自帶的；
　　分3組數據：
　　1）不使用并發(fā)，直接使用百度爬取
　　2）針對具體某一新聞頁(yè)進(jìn)行并發(fā)，并且爬取這條新聞頁(yè)，鏈接
　　并發(fā)命令：
　　結果發(fā)覺(jué)，嘗試多次，第三種情況下總算出現了抓起失敗的情況??！撒花~
　　ok，雖然不是百分百能再現，但起碼再現到一次了，也就說(shuō)明的確有問(wèn)題的；
　　下面是點(diǎn)擊百度上的查看幫助里的內容：
　　Ok,拿著(zhù)這個(gè)去跟后端反饋，結果后端負責人是如此回答的：
　　會(huì )處理；
　　嗯，這個(gè)問(wèn)題就這樣算是有個(gè)交待了；
　　小結
　　總結下此次遇見(jiàn)的問(wèn)題吧 ；
　　收到問(wèn)題->尋求數據怎么統計->分析前端日志->壓縮圖片size及處理404問(wèn)題->再次剖析，懷疑跟帶寬有關(guān)系->重新梳理流程->懷疑并發(fā)->驗證->重現問(wèn)題;
　　其實(shí)從里面的流程來(lái)說(shuō)，貌似沒(méi)太多的問(wèn)題，在不了解或則不熟悉的業(yè)務(wù)上，也只能不停的去排查來(lái)驗證表象；
　　但有個(gè)最大的問(wèn)題是，像這類(lèi)問(wèn)題，理應第一時(shí)間想到并發(fā)跟帶寬，但是在此次卻是最后才想到，由此可見(jiàn)敏感度不夠，無(wú)論是測試還是研制，對這些問(wèn)題跟進(jìn)能力比較缺乏，后面須要強化這類(lèi)問(wèn)題的敏感度；
　　上面提到到的壓縮圖片size和處理404的問(wèn)題，即使沒(méi)有此次的反饋，從網(wǎng)頁(yè)本身考慮，本身就是須要去做的事情；
　　apache ab介紹
　　對于網(wǎng)站而言，壓測是必須要做的工作，那壓測的工具有很多，jmeter，loadrunner，ab，那為何會(huì )選擇ab？
　　個(gè)人認為主要的緣由是邊界，命令行，windows\Linux\mac都支持使用；
　　下載安裝
　　因博主筆記本是win10，所以是以windows的下載來(lái)述說(shuō)，請了解；
　　2)打開(kāi)鏈接后，點(diǎn)擊紅框的Files for microsoft windows
　　3)打開(kāi)后，點(diǎn)擊紅框的ApacheHaus
　　4）向下滑動(dòng)，鼠標點(diǎn)擊曉紅框里的內容，就會(huì )手動(dòng)進(jìn)行下載
　　但是試過(guò)好幾次可能是網(wǎng)路緣由，下載太慢，而且可能會(huì )斷掉，因為剖析一個(gè)2.3.4.3版本的zip包，需要的朋友自?。?br /> 　　下載完就解壓，使用Windows下的cmd命令行，去到剛解壓的目錄下的bin目錄;
　　然后輸入ab，如果不報錯，則說(shuō)明是成功了；
　　當然，有朋友認為每次都進(jìn)來(lái)這個(gè)目錄很麻煩，那可以把Apache24\bin這個(gè)路徑配置到環(huán)境變量，后續就可以直接ab使用了，具體Windows下環(huán)境變量如何配置，網(wǎng)上搜索下，很多的~
　　直接壓測網(wǎng)站
　　執行后，就會(huì )有右圖的結果輸出：
　　壓測就是如此簡(jiǎn)單，但是要剖析上圖的內容，才有價(jià)值 這一陀看不懂？沒(méi)關(guān)系，下面教你如何看
　　ab命令參數說(shuō)明
　　第一次使用ab命令時(shí)，不知道有哪些參數，可以輸入ab -help，然后才會(huì )彈出如此一坨東西：
　　一般常用的參數就下邊幾個(gè)：
　　更加多詳盡參數說(shuō)明：
　　實(shí)例
　　ab -n 3000 -c 3000
　　ab -t 60 -c 100
　　帶參數的的懇求
　　ab -t 60 -c 100 -T "application/x-www-form-urlencoded" p p.txt
　　參數中的三種方式
　　結果剖析
　　執行完后，會(huì )有如此一坨東西：
　　下面就來(lái)講解，到底是哪些意思：
　　使用ab常見(jiàn)的問(wèn)題
　　1）ab命令在通常系統里面做測試時(shí)侯，一般并發(fā)不能超過(guò)1024個(gè)，其實(shí)是因為由于系統限制每位進(jìn)程打開(kāi)的最大文件數為1024，可以用ulimit -a來(lái)查看;
　　2)-n 可以指定最大懇求數，但是不能超過(guò)50000個(gè); 查看全部