strange G-WAN response speed differences

Question

I had just implement G-WAN web server and test for my code, however, it is very strange that my server response very fast sometimes (20 ms), and sometimes over few seconds (6–7 s) or even timeout...

I try to simplify my code, and return a string to clients, the problem still occurs... Beside, I had log the time consume by my code, it never over 1 sec, so what cause the problem?!

I guess this cause by network delay, and test the network speed of the same server, it very fast, any idea? (Will the problem caused by include some 3rd party library like MySQL?)

Here is my G-WAN log:

*------------------------------------------------  
*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.  

Answer 1

If I use -g mode, and increase the number of workers up to the number of CPUs of the server, this problem seem to be resolved

Then, it seems to be a CPU detection issue. Please dump the relevant part of your gwan.log file header (CPU detection) so ew can have a look.

When G-WAN has to re-compile a servlet using external libraires that must be searched and linked, this may take time (especially if there's only one worker and other requests are pending).

---

UPDATE: following your gwan.log file dump, here is what's important:

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  

The Intel E5506 is a 4-Core CPU... but the Xen Hypervisor is reporting 1 CPU and 0 Cores (and hyperthreading enabled, which makes no sense without any CPU Core).

Why Xen finds it a priority to corrupt the genuine and correct information about the CPU with complete nonsense is beyond the purpose of this discussion.

All I can say is that this is the cause of the issue experienced by 'moriya' (hence the 'fix' with ./gwan -g -w 4 to bypass the wrong information reported by the corrupted Linux kernel /proc and the CPUID instruction).

I can only suggest to avoid using brain-damaged hypervisors which prevent multicore software (like G-WAN) from running correctly by sabotaging the two standard ways to detect CPU topologies: the Linux kernel /proc structure and the CPUID instruction.