CGI application causes high CPU on Linux

I am not seeing any reported errors and the application eventually performs the task requested but it runs very slow. The Linux server is Ubuntu 14.04 LTS (Virtual Machine), 4Gb RAM, 2 Cores. The server (VM) is local to me (not hosted). The app is built as a 64-bit app.

This is with just 2 of us accessing the app. One was just logged in not doing anything. The other entering data. The UPTIME shows an elevated CPU load.

22:26:59 up  1:05,  1 user,  load average: 7.86, 6.07, 3.04

Is there some required configuration I am missing?

Are you sure it’s the web app and not some other program causing this?

Instead of uptime try top to see which processes are causing load.

It seems the 2 Xojo CGI applications I have running on the web server are equally responsible for the high CPU utilization. No errors are reported for either application. TOP is reporting that each app has consumed over 4 hrs of CPU whereas all others are less than 1 hour.

Ok, so the next question… Does an empty web app built with the same parameters consume cpu like that?

If not, do you have any tight loops or threads that don’t yield?

I built the app as standalone 64-bit OS X and am running it on my iMAC. I spent 2-3 hours working in the application with no speed or latency issues. I now have 6 users on my LAN trying (keyword “trying”) to login and use the application. The app is now on its knees begging for mercy. If I restart the app and only allow 1 person to access the site, it works fine. I am not receiving anything on StdErr, nothing in the system log, and nothing in my internal logging to file.

Greg, to answer your questions…I haven’t build an empty web app yet (will try to get to it today) and no, I don’t have any tight loops and I don’t use threads.

Solved it! Since you have to use a WebTimer to allow enough time for the ProgressWheel to be made visible, I had put my Select Case statements in the WebTimer.Action event. I did a test or two with moving all code except 2 lines from the Action event. I didn’t see the CPU spike. I then did the same to a few key timers in my project. I experienced the same results. I have now moved all code from all timer.action events to an independent method. My app runs much more efficiently.
The 2 lines in the timer.action event are

ProgressWheel1.Visible = False Call ActionMethod()