2013-06-12 60 views
1

我的git push操作在25-30秒左右完成,而不是(或多或少)立即返回。 我使用的是相當長後接收(bash)的腳本,I`ve在這裏找到:https://raw.github.com/zma/usefulscripts/master/script/post-receivegit push post-receive slow

一些細節:

  • 我的遠程倉庫是一個局域網服務器,在那裏我們有大約70MB的/ (這看起來不錯)
  • 這是一個新鮮的存儲庫,其中只有一個單一的測試文件
  • 我使用git bash,由gitextension(git版本1.7.11.msysgit.1)安裝,
  • 我也用gitgui測試了一個push操作,但是th延遲是相同的。所以我認爲它與我正在使用的前端無關。
  • 如果我刪除後收到腳本,推操作工作好(無延時的話)

我做了一些測試,如果後收到腳本中含有大約70線即都被註釋掉了(所以該腳本不做任何事),推遲大約5秒鐘。

這是正常的嗎? 還是有加快推動的方法嗎? 或者我必須戲劇性地縮小腳本大小?

更新: 它提到這一點很重要:

  • 我使用windows7的
  • 遠程信息庫託管在Linux服務器上,可達通過Samba

回答

1

git hooks page清楚地提到關於post-receive掛鉤:

此腳本無法停止推送過程,但客戶端在完成之前不會斷開連接;所以,當你嘗試做任何可能需要很長時間的事情時要小心。

這意味着,你的情況,你需要切換到一個異步的方式(除非你能解決什麼需要時間,像Sqeezeranswer,upvoted,似乎建議):

  • 製作你的腳本在文件中寫入它應該做的事情(發送電子郵件)
  • 讓一個cron作業接收該文件並每隔幾分鐘執行一次冗長的任務。

這樣,後收到鉤子返回儘可能快地,不阻止客戶端(從推已啓動,其中下游回購)

+0

這也是一個很好的提示,但我也測試過這個(或類似的東西):我修改了腳本以跳過郵件發送過程(也跳過電子郵件正文的臨時文件創建),然後收集信息(誰在什麼分支上做了什麼),延遲大約是15-20秒。但是我有一種感覺,沒有郵件發送的速度變得更快的真正原因是腳本中的行數不足以處理,而不是因爲腳本本身的事情少。 – user2448122

+0

@ user2448122,所以你可以按照這個提示,用一行鉤子腳本收集信息並將其寫入文件,而cron作業腳本包含該過程的大部分;) – VonC

1

從腳本描述

# An example hook script to mail out commit update information. This hook 
# sends emails listing new revisions to the repository introduced by the 
# change being reported. The rule is that (for branch updates) each commit 
# will appear on one email and one email only. 

然後看看腳本的底部。它說:

# Note: change the smtp server to yours 
     cat $email_tmp_file | mailx -S smtp="smtp://smtp.cse.ust.hk" -s "$emailsubject" -r $senderemail $recipients 

我相信你還沒有配置SMTP服務器,因此你的腳本正在等待smtp.cse.ust.hk進行連接,然後只是超時斷開。

+0

+1。比我自己的回答更實用的方法。 – VonC

+0

好的提示,但幸運的是我也閱讀說明:)。所以在我開始測試之前,我已經改變了我們自己的smtp服務器配置。再一次,如果腳本中沒有任何內容只是註釋掉了這些行,那麼推遲會延遲~5秒。所以它必須是解析post-receive腳本文本的東西。 – user2448122

+0

我不認爲腳本本身存在這個問題,因爲它只是bash腳本,它在Unix平臺上有公平的性能。你有沒有試過用命令行手動運行腳本? – Sqeezer

2

一個有趣的後續: 我測試過另一臺PC上的腳本,它工作正常。根本沒有延遲。所以我的電腦上有一些關於如何處理遠程腳本的問題。

遠程存儲庫位於samba共享上。我花了Wireshark的痕跡有2種情況:

  1. 只是在git的慶典
  2. 做了real混帳推

結果(沒有太多的技術細節)執行cat <path_to_the_script>\post-receive命令:

  1. 讀取AndX請求,FID:0x228f,偏移量爲0的1024字節(始終爲1024字節)
  2. Re廣告和X請求,FID:0x21c9,1個字節偏移量0(1字節,總是)

結論: 混帳推命令讀取1字節塊

+0

如果您自己回答了問題,請務必將其標記爲已回答! – RyPeck

+0

我的回覆不是答案,因爲我仍然不知道爲什麼git會緩慢處理接收後腳本。我只是將它添加爲'answer'而不是'comment',因爲您無法在'comment'中執行正常格式。 – user2448122

1

的,收到後腳本原來的samba共享配置爲不使用機會鎖與在smb.conf以下選項:

  • 機會鎖=否
  • level2的機會鎖=否

從共享配置中刪除這些條目減少了接收後執行的延遲時間大約4-5秒,這是合理的,我認爲。

+0

非常好。 +1。很高興知道。那麼我就不需要在我的答案中提到的「異步」方法。 – VonC