Good Morning. I'm in a very strange situation. Progress 11.7.1 64 bits running on a Linux Red Hat 7. 192GB of memory 32 colors On this server run the databases. I configured apache to use webspeed. a simple ping on the page (no databases connected, nothing). http: //server/cgi-bin/wspd_cgi.sh/WService=wsbroker1/ping It takes more than 12 seconds. Databases are out in this test. I can not tell because of the delay.
Firewall on linux disabled, selinux disabled, iptables disabled
Do you have the configuration in same or different machine ? i.e. webserver (+cgi) and WebSpeed running in same machine or different machine. If they are in different machine network delay would have impact on slow performance.
Also you need to check the maximum concurrent client execution on webspeed server. Sometimes if all the active agent are busy to execute other request, then a new request will take time ,because webspeed broker spawns a separate agent process to execute the current request. I hope this will helpful.
Thanks,
Arun
Arun, nothing running in this server, only webspeed (no db connectd on webspeed, for testiing only).
Running 2 agents webspeed.
On other machine (102B version) runnig very well
You might try the WSMAdmin commands (documentation.progress.com/.../ to try to narrow down the problem. This will let you get a feel for how long each of the steps in the request take (browser to messenger, browser to nameserver, browser to broker). That could give you a clue as to where to start looking.
I assume an OS ping between the same two boxes is normal(?).
Are you using NFS?
If you place the working directory for your CGI script on a slow mount you can get some pretty erratic behavior. But the problem could be anywhere in the stack.
Check apache logs (may need to adjust configs to add request time to the logs) to confirm if the time is spent server side or network side to server.
If all else fails... since the CGI is persisting on the server for ~12 seconds, you might consider tracing the CGI, apache, and/or the child procs. A detailed trace isolated to the time of the request may point to specific system calls and file descriptors which would tend to isolate the extra time. (i.e. strace -p [PID] -Tf -o [filename]) This should be in isolation unless you want a bunch of noise and a giant file. Interpreting the result will be the interesting part.