WebApp behind SSL via Apache?

I’m having performance trouble with a WebApp which I now believe might be caused by running the WebApp in standalone mode with SSL (see https://forum.xojo.com/30191-webapp-struggling-under-load for discussion).

This is running on an OS X server which already has Apache running with a SSL certificate, so maybe I don’t really need or want the WebApp to do its own SSL.

Question 1: is there an easy way to have Apache handle the SSL for a Xojo standalone web-app running in regular (HTTP) mode? Is this where one would need a reverse-proxy?

Question 2: would there be any advantage to running this app in CGI mode? Does CGI mode fire up one instance of the app Per HTTP request? Or Per Session? Or just one instance total? I’m familiar with old-school CGI in which case every HTTP request starts then exists the app (which sounds bad to me).

Precisely that Apache would carry out SSL for you. Also, it starts/restarts automatically, hence you can use App.autoquit so when there is no session the app quits, then restarts as soon as a user hits the cgi.

A standalone app completely bypasses Apache.

It doesn’t have to. You can run the Apache mod_proxy module to do a reverse proxy if you want.

Greg, can you clarify what you are replying to?

I think he was saying that apache can proxy requests to the app and let the app handle everything in standalone mode vs running as cgi. Not that one is necessarily better than the other just that you have the option.

Personally I like running through haproxy. It’s a fantabulous piece of code.

Thanks - is it true that no matter what, there’s always just one instance of the app running?

Or can one with reverse-proxy end up with 2+ instances running? (That could be seen as good or bad, depending on the situation).

Greg is responding to the comment about standalone bypasses Apache.

mod_proxy is easy to setup and since you are already running Apache it is worth looking into. The configuration parameter is ProxyPass /PathToProxy/ http://127.0.0.1:8080/.

You can deliberately run on multiple instances on different ports and then proxy each in your Apache config. Accidentally starting up multiple instances would be difficult since they all would try to start on the same port.

I posted this in your other thread - just putting it here for reference as well.

I know you are asking about Apache but HAproxy is a far more configurable load-balancer and is great for balancing multiple instances of Xojo apps along with SSL termination. You can still mix in Apache and serve static content - all routing through HAproxy.

Start here http://john-joyce.com/xojo-and-load-balancing-with-haproxy/
There are links in there that have more info as well.

Also search for HAproxy in the forum and you will find the conversations. You may have to dig around.
https://forum.xojo.com/conversations/all?search=haproxy

Let me know if I can help.

Michael,
You have two posts related to this issue. I feel you aught to at least narrow down your problem by addressing these from your other post:

[quote]I’m pretty sure this used to work just fine, but then something changed. Of course, I changed a few things at once:

New version of Xojo
Using SSL rather than not
New version of OS X (10.9 -> 10.10)[/quote]

I know it must be frustrating, and we have all been there, but take a step back an isolate the problem before looking for the solution.

[quote=248257:@David Andrews]Michael,
You have two posts related to this issue.[/quote]

The other post is speculating on cause(s).

This one is more about how to do a specific configuration either to test or workaround the issue.

I would like to both understand the root cause so as to submit a feedback report, AND I’d like to have a quick & dirty solution available in case there is no easy workaround right away.

There isn’t any Xojo issue here that I’m aware of- SSL overhead has a cost, it always has. You can run behind HAProxy if you like, but turning on SSL via your own app or a server in front will always increase your CPU workload. The nice thing about putting SSL separately via something like HAProxy is that an entirely different core- or if you like- an entirely different server can be taking that hit instead of your app.

My testing suggests there is not a simple degradation in performance, but rather what looks like a bug: threads (sessions?) get stuck burning CPU even after all connections are gone. Comments on that topic should probably go here: https://forum.xojo.com/30191-webapp-struggling-under-load/last