重要:此頁面會使用Cookie (cookies). 使用本網站不關閉瀏覽器中的cookie,即表示您同意使用它。
現在購買! 特點 下載

賺錢與我們聯繫!

如果您想要開始賺錢與貝特聯接 聯盟計畫。
12 12 最後Last
結果 11015

主題: 更多的負載問題

  1. #1
    高級會員
    註冊日期
    2010年2月
    帖子
    210

    Default 更多的負載問題

    好讓我做負荷測試。

    在為期 24小時我的負荷穩步上升到30.00的

    服務器重新啟動修復它的另一個 24小時。

    如果我禁用MOD我不明白這個問題。

    不要說與 MOD殘疾人有較少的交通,事實並非如此,谷歌仍然發送相同的交通with MOD殘疾人根據我的統計資料。

    請解釋,負載是推動我瘋了。

  2. #2
    高級會員
    註冊日期
    2009年12月
    帖子
    276

    Default

    聽起來像機器人都打到翻譯的頁面時,MOD上。你應該看看優化 Apache或服務器獲得更多的CPU資源。你運行 vboptimise或任何類型的緩存機制,Memcached的一樣?

  3. #3
    高級會員
    註冊日期
    2010年2月
    帖子
    210

    Default

    事實上,我的論壇每天有 3 萬個 unques ,如果我立即停用 pmod ,而 bot 和 users 仍在顯示頁面,所以仍要求伺服器電源,只是顯示翻譯的頁面使用的資源比一般資料庫的標準 vb 分頁使用的資源為 10x 。 寫的代碼不好,需要修正! 其他的人從來沒有這樣過,只是希望我永遠不會改變,但回去的時間已經太遲了。

  4. #4
    高級會員
    註冊日期
    2009年11月
    帖子
    168

    Default

    這真的聽起來像你的服務器上運行動力不足。我在8核Nehalem機器(所以我們期待在8個虛擬核心由於 HT,共計 16個)。我還廣泛地優化本機使用自己的技巧,以及指針從鄉親在vbulletin.com。

    vBET提出了我的負荷約 2.5至3.0-3.5,這取決於用戶數量,這明顯增長的基礎上,高速緩存的大小。不過,我不認為太壞事,因為我的用戶同時使用的範圍從一個相當高的800到一個更高的1200。

  5. #5
    米哈爾 Podbielski(vBET職員) vBET's Avatar
    註冊日期
    2009年10月
    帖子
    3,037

    Default

    您好 當然,翻譯必須採取一些資源 - 有沒有神奇。翻譯頁面的輸出結果和採取的手段改變它。因為,翻譯總是需要更長的時間比正常的頁面。

    我知道你是不是太高興有更多的服務器的負載,但請注意,vBET正在資源僅翻譯。對於正常的網頁它僅增加標誌。因此,所有這額外的負載來自額外交通翻譯的頁面。正如你說你的流量沒有下降後立即停用vBET(如果你有一段話,它會減少後禁用 - 信任我)和服務器負載較低 - 這是顯而易見的 - 爬行機器人仍然要翻譯的網頁網址,用戶仍然發現在谷歌鏈接到您的翻譯頁面。所以,你仍然有同樣的流量,但目前正在翻譯的聯繫僅僅是重複的內容 - 這是不正常的頁面翻譯。如果你想留殘疾 vBET我們強烈建議添加規則在。htaccess文件,將所有翻譯的頁面重定向到正常的,否則你可以鬆動你的SEO,因為重複的內容。

    請注意,我們已計劃支援其他快取系統,並即時最佳化我們的翻譯演算法。 我們剛剛發現,在使用大型字串工作時, PHP 效能會大幅降低,我們也修改了演算法。 它已在 vBET 4.2.0 中釋放,並具有其他配置選項。 我們也會將所有改進移至 vBET 3.x ,它仍受支援

    據我所知,在您看來,我們的代碼是微弱的。我不知道你是基於什麼你的期望。我們最快的翻譯模為 VB - 沒有什麼什麼更好的作品。翻譯需要一定的資源和我們的MOD需要它不到任何其他。你可以看到如何快速vBET可以在許多論壇。如果您的服務器上有問題,那麼請考慮配置更改或增加服務器資源。你不會把20升水成10升桶。

    我們的設計是: "我們有很多要改變 " 。 這就是為什麼我們在試驗,改變演算法,進行側寫,花費大量時間尋找需要更少資源的解決方案。 我們還不知道什麼是對 vBET 的競爭,而且還有一些其他的翻譯模式。 我們做了很多演算法的改變因為它們沒有幫助,在這個過程中我們也發現了很多的改進。 您可以根據伺服器問題來產生印象,但請考量您有任何更好的解決方案嗎? 你能給出一個暗示,也許 vBET 是一個錯誤的解決方案,因為它正在成千上萬的論壇上工作,也許你只是想把 20 公升的水放進 10 公升的桶裡。 不過 - 我們在優化部分有很多變化和偉大的 TODO 清單(約 70% 的實驗會有幫助或不幫忙) 而你是100%正確的 - 我們可以做的更好,我們將和我們正在做這一切的時候 只是等待,直到我們將所有的改善,我們實施期間 vBET4.x

    如果我可以給你一些提示 - 請檢查您如何優化 vBET: http://www.vbenterprisetranslator.co...rformance.html
    特別是考慮禁用某些語言和阻止不相關網頁被robots.txt

    什麼是響應時間為翻譯的頁面?什麼是您的CPU使用情況?什麼是你的內存使用情況?如果是可以接受的,那麼你有什麼可擔心的。人們往往害怕通過增加服務器的負載,甚至不知道什麼意思。 10倍以上的服務器負載不 意味著更多的資源使用10次。它只是意味著更多的線程在等待隊列中,什麼是完全正常的,因為現在你的線程必須等待谷歌的反應,如果一些翻譯不緩存呢。所以線程正在等待谷歌的反應,它不帶 CPU在所有在這段時間。因為您的服務器的負載會比較大,即使vBET可以採取任何資源,所有(什麼當然是不可能的)。

    關於你的服務器崩潰 - 這顯然是您的服務器的問題。它發生週期性。我也有類似的問題我的服務器上。這是由於一些Apache的bug,因此一個 Apache線程的成長和不斷增長的內存使用,直到整個內存被消耗ANS服務器緩存。只有一個線程的行為就像是 - 其他Apache線程是正常的。我打了Apache的配置和問題解決。我認為,阿帕奇只是有一些內存洩漏 - 我記得我把低價值的請求,可以容納一個線程。此外,還有其他的變化。我建議檢查內存使用情況和監視它一段時間。同時它可以幫助檢查內存使用量平均由一個 Apache線程,取得了一定的計算和設定適當的值最大線程的Apache。

    如果您有任何問題,請只問
    最後編輯者 vBET; 17-03-1000:53.

  6. #6
    米哈爾 Podbielski(vBET職員) vBET's Avatar
    註冊日期
    2009年10月
    帖子
    3,037

    Default

    嘿 - 我只是在你的論壇它轉換 ULTRA FAST ...那麼,你是否了解,為什麼這麼憤怒的態度有關 vBET,當你有超級快速的翻譯服務?...

    請考慮一下服務器負載的方法。了解它的意義可以有很大的幫助,了解發生了什麼,以及它如何在服務器上可以與線程在隊列中的等待不是因為你沒有資源,但正在等待響應來自其他服務器(谷歌在這種情況下)。

    在我看來你有超級快速的翻譯,你還有什麼可擔心的

  7. #7
    高級會員
    註冊日期
    2010年2月
    帖子
    210

    Default

    我一直在建築工地 10年來,我充分認識到10倍的負載並不意味著 10倍的資源,停止把我像一個白痴和勺子餵我垃圾。寒冷的事實與此MOD VS其他免費 MOD你的負載巨型。而在繁忙時間我的網站現在是緩慢,反應遲鈍。是的,網頁翻譯快速非高峰期,但在成本的降低服務器在當天晚些時候。我有一個四核心,RAID 15K SAS服務器,即優化得很好,它運行 0.50整天在此之前的大流量。這是VBET代碼,增加了負載,使服務器在高峰時間慢,這是一個事實,這不是增加流量,我有過同樣的流量和漫遊和服務器之前應付的罰款,這是翻譯的產物。期。快點解決它,我真的不想要支付300英鎊一個月另一個為服務器升級只是為了運行一個 MOD LOL。

  8. #8
    高級會員
    註冊日期
    2009年12月
    帖子
    276

    Default

    有多少種語言,你已經啟用?多少個職位,你呢?你有百度推廣和網站地圖生成器安裝?機器人是打多少網站,每天?

  9. #9
    高級會員
    註冊日期
    2010年2月
    帖子
    210

    Default

    嗨!

    32種語言啟用。

    10萬個職位。

    百度推廣和網站地圖安裝。

    地圖插件說每天爬100萬頁。


    事實是,如果我禁用MOD和重新啟動服務器,BOT和用戶打我的服務器仍然像以前一樣,同樣的頁面是在Google的索引中仍,所以我得到同樣的交通啟用。

    唯一不同的是,隨著 MOD殘疾人的機器人和谷歌搜索得到的英文頁面,所以,交通是相同的,唯一的區別是他們沒有看到翻譯的頁面,從而避免了MODS的數據庫問題。

    很明顯的一天我這個 mod已發布沒有適當的測試,並明確了所有者不感興趣解決的問題。

    失敗。

  10. #10
    高級會員
    註冊日期
    2010年2月
    帖子
    210

    Default

    邁克爾,你錯了,這負荷不增加造成的交通,它是造成閱讀和寫作翻譯到MySQL。

    如果百度推廣團隊可以讀取和寫入到MySQL與低負荷你為什麼不能?

    可憐的代碼我的朋友。

12 12 最後Last

標籤這個主題

發帖權限

  • 可能不會 發表新主題
  • 可能不會 發表回复
  • 可能不會 上傳附件
  • 可能不會 編輯您的文章
  •