奇怪的G-WAN響應速度差異

我剛剛實現了G-WAN web服務器並測試了我的代碼，但是，很奇怪我的服務器響應速度很快（20毫秒），有時超過幾秒鐘-7秒）甚至超時...奇怪的G-WAN響應速度差異

我試圖簡化我的代碼，並返回一個字符串給客戶端，問題仍然存在... 除此之外，我有記錄我的代碼消耗的時間，它從來沒有超過1秒，那麼是什麼原因引發了這個問題呢？

我想這是由網絡延遲引起的，並測試同一臺服務器的網絡速度，它非常快，有什麼想法？（會不會造成問題包括一些第三方庫像MySQL？）

這裏是我的G-WAN日誌：

*------------------------------------------------ 
*G-WAN 4.3.14 64-bit (Mar 14 2013 07:33:12) 
* ------------------------------------------------ 
* Local Time: Mon, 29 Jul 2013 10:09:05 GMT+8 
* RAM: (918.46 MiB free + 0 shared + 222.81 MiB buffers)/1.10 GiB total 
* Physical Pages: 918.46 MiB/1.10 GiB 
* DISK: 3.27 GiB free/6.46 GiB total 
* Filesystem Type Size Used Avail Use% Mounted on 
* /dev/mapper/vg_centos6-root 
*    ext4 6.5G 3.2G 3.0G 52%/ 
* tmpfs  tmpfs 1004M 8.2M 995M 1% /dev/shm 
* /dev/xvda1 ext4 485M 129M 331M 28% /boot 
* 105 processes, including pid:10874 '/opt/gwan/gwan' 
* Page-size:4,096 Child-max:65,535 Stream-max:16 
* CPU: 1x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 
* 0 id: 0  0 
* Cores: possible:0-14 present:0 online:0 
* L1d cache: 32K line:64  0 
* L1i cache: 32K line:64  0 
* L2 cache: 256K line:64  0 
* L3 cache: 4096K line:64  0 
* NUMA node #1 0 
* CPU(s):1, Core(s)/CPU:0, Thread(s)/Core:2 
* Bogomips: 4,256.14 
* Hypervisor: XenVMMXenVMM 
* using 1 workers 0[1]0 
* among 2 threads 0[]1 
* 64-bit little-endian (least significant byte first) 
* CentOS release 6.3 (Final) (3.5.5-1.) 64-bit 
* user: root (uid:0), group: root (uid:0) 
* system fd_max: 65,535 
* program fd_max: 65,535 
* updated fd_max: 500,000 
* Available network interfaces (3): 
* 127.0.0.1 
* 192.168.0.1 
* xxx.xxx.xxx.xxx 
* memory footprint: 1.39 MiB. 
* Host /opt/gwan/0.0.0.0_8080/#0.0.0.0 
* loaded index.c      3.46 MiB MD5:afb6c263-791c706a-598cc77b-e0873517 
* memory footprint: 3.40 MiB.

來源

2013-07-29 moriya

這個問題似乎是脫離主題，因爲它是針對[網站管理員]（http://webmasters.stackexchange.com/） –

最後，我嘗試使用-g模式，增加工人達到CPU的數量服務器，問題似乎被解決，誰能告訴我是什麼原因造成的問題？ – moriya

@Rowland：這是一個（servlet）編程，也可能是一個編譯問題，所以它對於程序員問答似乎相當重要。從問題中刪除[SQL]和[C]標籤是不公平的。 – Gil

如果我使用-g模式，並增加了工人的數量到服務器的CPU數量，這個問題似乎得到解決

然後，它似乎是一個CPU檢測問題。請轉儲您的gwan.log文件標題（CPU檢測）的相關部分，以便ew可以看看。

當G-WAN必須使用必須搜索和鏈接的外部庫管理器重新編譯servlet時，可能需要一些時間（特別是如果只有一個工作人員和其他請求未決）。

UPDATE：按照你gwan.log文件轉儲，這裏是什麼是重要的：

CPU: 1x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 
    0 id: 0  0 
Cores: possible:0-14 present:0 online:0 
CPU(s):1, Core(s)/CPU:0, Thread(s)/Core:2 
Hypervisor: XenVMMXenVMM 
    using 1 workers 0[1]0 
    among 2 threads 0[]1

英特爾E5506是一款4核心CPU ...但Xen Hypervisor正在報告1個CPU和0核心（並啓用超線程，這是沒有任何CPU核心沒有意義）。

爲什麼Xen發現它是一個優先事項，腐敗的真正和正確的CPU信息完全廢話超出了這個討論的目的。

我可以說的是，這是由「守也」有經驗的（因此「修復」與./gwan -g -w 4繞過被破壞的Linux內核/proc和CPUID指令所報告的錯誤信息）的問題的原因。

我只能建議避免使用腦損壞的虛擬機管理程序，通過破壞兩種檢測CPU拓撲的標準方法來防止多核軟件（如G-WAN）正常運行：Linux內核/ proc結構和CPUID指令。

來源

2013-07-29 13:40:55 Gil

非常感謝你，我試圖改變到另一臺服務器，實際上有3個核心，但gwan仍然只使用1，我需要使用-g選項來覆蓋它...無論如何，感謝您的幫助！ – moriya

@Gil http://www.ovh.co.uk/dedicated_servers/kimsufi.xml具有1個內核的微型Atom服務器能夠運行G-WAN嗎？ – Nagi

@Nagi我認爲G-WAN不在原子CPU上運行......但是如果你看一下http://gwan.ch/faq#cpus，Gil會確認 – solisoft

奇怪的G-WAN響應速度差異

回答

相關問題