摘要:不過(guò)好消息是,在事件發(fā)生的二十四小時(shí)以后,我發(fā)現(xiàn)我的賬號(hào)解禁了,哈哈哈哈。
本文最初發(fā)布于我的個(gè)人博客:咀嚼之味
從昨天凌晨四點(diǎn)起,我的 Leetcode 賬號(hào)就無(wú)法提交任何代碼了,于是我意識(shí)到我的賬號(hào)大概是被封了……
起因我和我的同學(xué) @xidui 正在維護(hù)一個(gè)項(xiàng)目 xidui/algorithm-training。其實(shí)就是收錄一些算法題的解答,目前主要對(duì)象就是 Leetcode。我前幾天正好做到 #17 Letter Combinations of a Phone Number。題目也蠻簡(jiǎn)單的,我寫(xiě)好以后提交了一下,發(fā)現(xiàn)跑出來(lái)的結(jié)果是 152 ms —— “哇哦,你打敗了 2.44% 的提交”。好差!!我瞬間滿臉黑線。而之前提到的項(xiàng)目中正好有另一個(gè)同學(xué)寫(xiě)的關(guān)于這一題的解答,我趕緊去參考了一下,感覺(jué)空間復(fù)雜度比我小很多,但時(shí)間復(fù)雜度應(yīng)該差不多呀,然后注釋中有這么一句:
I think this is an O(n^3) solution, but still runs faster than 100% submissions
不信邪的我把這位同學(xué)的代碼復(fù)制過(guò)來(lái)提交了一下,得到的結(jié)果是 —— 160ms...“哇哦,你打敗了 2.44% 的提交哦!” ╮(╯_╰)╭
看了看 Discuss 里的解法,感覺(jué)復(fù)雜度似乎也差不多,于是我決定研 (Zuo) 究 (Si) 一下 Leetcode OJ 服務(wù)的穩(wěn)定性如何。
過(guò)程打開(kāi) Chrome 的開(kāi)發(fā)者工具,發(fā)現(xiàn)只有 submit 和 check 兩種 ajax 請(qǐng)求,response 內(nèi)容大概是這樣的:
// `submit` response { "submission_id": 46823974 } // first `check` response { "state": "STARTED" } // second `check` response { "lang": "javascript", "total_testcases": 25, "status_code": 10, "status_runtime": "152 ms", "run_success": true, "state": "SUCCESS", "total_correct": 25, "question_id": "17" }
所以只要先模擬一個(gè) submit 的 POST 請(qǐng)求,拿到 submission_id 后,再用這個(gè) id 模擬 check 的 GET 請(qǐng)求,直到拿到最終的結(jié)果。
我直接把之前發(fā)送的兩個(gè) ajax 請(qǐng)求用 Curl 的形式保存下來(lái):(感謝 Chrome ╰( ̄▽ ̄)╮)
然后我寫(xiě)了個(gè) Nodejs 的小程序,每隔一分鐘調(diào)用上面保存的兩個(gè)腳本來(lái)進(jìn)行一次提交,并把當(dāng)次的執(zhí)行速度保存到 Mongodb 中。代碼我就不貼啦,有興趣的話可以到 zry656565/Leetcode-Benchmark 看看。
結(jié)果這個(gè)程序大概是在十一點(diǎn)左右的時(shí)候開(kāi)始運(yùn)行的。本以為一分鐘一次的頻率并不高,結(jié)果第二天起來(lái)一看,從凌晨四點(diǎn)多開(kāi)始就沒(méi)有數(shù)據(jù)了,自此我這個(gè)賬號(hào)就提交不了代碼了。。
當(dāng)然啦,采集到了 300 多條數(shù)據(jù)也不能白費(fèi)了,畫(huà)個(gè)圖出來(lái)看看吧。任意一個(gè)節(jié)點(diǎn)所提交的程序片段都是同一個(gè),大概最終的結(jié)果是這樣的:
(⊙o⊙)…本來(lái)想著是不是能找到某個(gè) Leetcode 的服務(wù)器稍微穩(wěn)定一點(diǎn)的時(shí)刻,不過(guò)似乎并不存在這樣的時(shí)刻呢。呵呵,然并卵。不過(guò)好消息是,在事件發(fā)生的二十四小時(shí)以后,我發(fā)現(xiàn)我的賬號(hào)解禁了,哈哈哈哈。
完。文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/78195.html
摘要:今天作了一波,解決過(guò)程還是比較曲折的,特此記錄一下。第一次體驗(yàn)到了設(shè)置的好處,只需修改一點(diǎn)就好了還是啟動(dòng)不了的程序本以為配置完環(huán)境應(yīng)該就完事大吉了。 今天作了一波,解決過(guò)程還是比較曲折的,特此記錄一下。 作死行為 今天下午一時(shí)興起,改了一下硬盤(pán)名,當(dāng)時(shí)想著應(yīng)該不會(huì)有問(wèn)題,畢竟以前該磁盤(pán)的掛載點(diǎn)是一堆亂七八糟的字符,和那個(gè)1TB卷(這名字看著真不得勁)的硬盤(pán)名看著毫無(wú)關(guān)系。 (以下為修改...
從事 Android 開(kāi)發(fā)工作要滿 5 年了,雖然明白自己技術(shù)很一般,但是也總是期望能夠有機(jī)會(huì)進(jìn)入更好的平臺(tái)發(fā)展。這不,因?yàn)闄C(jī)緣巧合有了一次 Booking 的面試邀請(qǐng)(是在 hackerrank 上),然后開(kāi)始臨時(shí)抱佛腳 (leetcode 走起),最終選擇了一個(gè)周末去完成線上測(cè)試,結(jié)果我完全沒(méi)預(yù)料到。本以為會(huì)被某道題的邏輯繞昏,結(jié)果哪知道被標(biāo)準(zhǔn)輸入這個(gè)東西卡得死死的,現(xiàn)在就記錄一下這次非常糟...
摘要:相關(guān)環(huán)境由于是一個(gè)幾年前的項(xiàng)目,所以使用的是這樣的。一些小提示本次優(yōu)化筆記,并不會(huì)有什么文件的展示。將異步改為了串行,喪失了作為異步事件流的優(yōu)勢(shì)。 這兩天針對(duì)一個(gè)Node項(xiàng)目進(jìn)行了一波代碼層面的優(yōu)化,從響應(yīng)時(shí)間上看,是一次很顯著的提升。 一個(gè)純粹給客戶端提供接口的服務(wù),沒(méi)有涉及到頁(yè)面渲染相關(guān)。 背景 首先這個(gè)項(xiàng)目是一個(gè)幾年前的項(xiàng)目了,期間一直在新增需求,導(dǎo)致代碼邏輯變得也比較復(fù)雜,接...
摘要:正確的思路是等概率隨機(jī)只取出共個(gè)數(shù),每個(gè)數(shù)出現(xiàn)的概率也是相等的隨機(jī)輸出把一段代碼改成,并增加單元測(cè)試。代碼本身很簡(jiǎn)單,即使沒(méi)學(xué)過(guò)也能看懂,改后的代碼如下但是對(duì)于單元測(cè)試則僅限于聽(tīng)過(guò)的地步,需要用到,好像也有別的模塊。 在拉勾上投了十幾個(gè)公司,大部分都被標(biāo)記為不合適,有兩個(gè)給了面試機(jī)會(huì),其中一個(gè)自己覺(jué)得肯定不會(huì)去的,也就沒(méi)有去面試,另一個(gè)經(jīng)歷了一輪電話面加一輪現(xiàn)場(chǎng)筆試和面試,在此記錄一下...
閱讀 1183·2021-10-20 13:48
閱讀 2226·2021-09-30 09:47
閱讀 3117·2021-09-28 09:36
閱讀 2361·2019-08-30 15:56
閱讀 1212·2019-08-30 15:52
閱讀 2031·2019-08-30 10:48
閱讀 622·2019-08-29 15:04
閱讀 582·2019-08-29 12:54