• If the problem is clearly related to Web Custom Controls, please contact me directly and do not contact Real Software or file a feedback report. I don’t want Real Software staff to have to sort through problems that are part of my toolkit and are therefore my responsibility to fix. If the problem is ultimately due to a Realbasic issue, I can confirm it and file a feedback report.
• If the problem appears to be unrelated to Web Custom Controls, please verify this before contacting Real Software or filing a feedback report. You can do this by creating a separate test project which does not include Web Custom Controls and replicating the problem there. You should have such a test project for a feedback report any way as it helps Real Software staff to quickly identify the problem. Once you have this, go ahead and contact Real Software. If you don’t have time to do this, please contact me first so that I can evaluate whether or not the problem has anything to do with Web Custom Controls.

I don’t consider this a major problem, but it has come to my attention that a user reported a bug to Real Software that should have come to me. I want to make sure this does not happen in the future as it wastes their time and delays the fix.

Update: Hat tip to Jay Madren for pointing out that you can quit an app on Linux by name using pkill. Check out his other tips below.

Most WE users who are deploying CGI apps to a VPS are no doubt deploying them to web hosts that use Linux servers. When you sign up for a VPS your web host will provide you with a SSH account which you can use to login and run commands. You do not require root access to find and quit your app. Any CGIs or apps that launch on your VPS should launch under your account. (If you have a Windows or Mac VPS or stand alone server then you should be able to remote into the full GUI and use the normal tools to find and quit any process.)

The command to quit your app is kill and it requires the process identifier, or PID, of your app. There are two ways to find the PID.

• Type the command: pidof MyAppName
• Type the command: top

The first will return the PID of your app. The second will return the top processes. Look for your app in the far right column, and find its PID in the far left column.

Once you have the PID simply type: kill PID

Now you can install your update. Note that it is possible that a user could launch your app again while you start transferring files, so you might have to kill the process again (it will have a new PID) or perform the update at a different time when your site has no traffic.

• WE loads multiple pages at startup, including any ImplicitInstance pages or pages you create in App.Open. Of course this results in very fast page switching once things are running.
• WE shows a startup screen. A simple, single page site doesn’t necessarily take longer to load then a PHP page, but the startup screen carries a psychological factor. We’re used to seeing pages draw onto our screen. But a progress bar makes us think “Oh great, I’m waiting.”
• CGI deployments often have to launch the WE application.

That last point is in bold for a reason. The default behavior with a CGI app is for the app to quit once the last Session closes. So if a user finished with your site 15 minutes ago, and a new user comes along, that new user has to wait for the app to launch. Even on a dedicated server the delay is quite noticeable.

The solution? For dedicated servers and VPS accounts, add this line to your App.Open event:

Self.AutoQuit = False

Now your app will stay open even when there are no Sessions. For obvious reasons you shouldn’t do this with a shared hosting account. And even with a server or VPS you should keep an eye on your app to catch any memory leaks. But if your app is solid and your hosting situation allows for it, this one change can significantly improve the perception of speed.

Keep in mind when you do this that you will have to kill the running application process any time you update the application file on the server. You normally have to do this any way. Here’s how.