What you may be seeing are hackers probing your app to look for vulnerabilities. They usually don’t stay long but unfortunately start a session every time. Keep in mind that 90 is probably the maximum number of users that a web app can handle at once by default.
You can help this by adding code to the App.HandleUrl event which checks the User-Agent header when the url is blank and just return True when it isn’t a browser.
We don’t do this automatically any more because:
A. It’s very easy to spoof a valid user-agent (but still not every hacker does so)
B. There’s no way for us to keep up with the number of browsers and browser signatures out there today.
C. There is some overhead in doing this technique.
Now, if you want to do it at the system level, hackers usually probe more than one port when trying these things… so using an adaptive firewall (like we do on Xojo Cloud) would catch them before they ever got to your app.
FWIW, when you just installed a new instance of your server somewhere, your IP might still get “used” by the former owner and/or its users. For instance because they forgot to change their IP somewhere … so usually “it is normal” that you are seeing “a lot of unusual traffic” for the first hours / days.
Nevertheless everyone should take care to protect their environment. It is the internet, and a lot of crazy people out there. But I only wanted to drop one(!) reason of many(!) why you might see unusual traffic. This a benign one, but unfortunately there are others too. For me that’s my major strength of Xojo Cloud and worth the price, unfortunately my customers have a different view on this .
I read John’s post and learned from that thread while building Lifeboat. I ended up selecting nginx because of how simple it is to configure. I was able to automate a lot of the monotony to make deployment a snap.
With nginx load balancing, as Xojo users we need to use the ip_hash directive to keep user requests directed at a consistent web app instance. I do use the round robin directive on a project that is a Web 2.0 REST API as there’s no session persistence needed there.
I can confirm that with ip_hash (or better yet, Lifeboat!) the Xojo session system operates successfully.
If you have any more questions about deploying web apps please don’t hesitate to ask! I would love to tell you more about Lifeboat too, feel free to reach out privately with your specific needs and I’ll help you figure out if my app can help
Hey there @NatP - I sent you a direct message on this as well.
No that is not normal. When you access the haproxy frontend of your app, does the app function normally or do you get errors or connection difficulty?
HAproxy will not automagically manage session affinity for you, you have to set it up for that. I find the easiest way to do that is with cookie injection. If you google “haproxy maintain session with cookie injection” you will find lots of info on how to do this. It is quite easy, just a couple lines in the config.
I have had very little issues running HAproxy as a front end for Xojo web apps for like 4-5 years now I think. It helps considerably in my experience and makes the whole thing much more scaleable.
Here is what I would do to test your situation:
Access the web app directly on the port it is running on and verify the behavior you are seeing does not occur. (If it DOES, there is potentially some issue with your server configuration or app iteself)
Set up HAproxy with just the one app instance as backend and verify behavior does not occur when you access through HAproxy. (if it does, experiment with different default timeouts)
I use these settings and they work fine for me:
timeout server 90s
timeout client 15s
timeout connect 15s
Configure cookie injection, increase number of backend app instances and try through HAproxy again. If you still have issues check that the cookie you are injecting is present in the response headers and it is NOT changing between requests. If it is not present you have not configured it properly. If it is changing, could be an issue with your browser(?) or possibly misconfiguration/typo in HAproxy.cfg.
Start with the most bare-bones haproxy.cfg you can and gradually add and tweak setting/rules one at a time. It can be difficult to troubleshoot if you have a lot of rules.
Obviously you have to have app instances running and listening on ports 8081, 8082, 8083 for this to work. HAproxy does not launch any app instances, you have to configure them to be running and listening on the appropriate ports separately. I assume you are tracking here but wanted to clarify just in case.
You can setup a custom url in your app for the httpchk that doesn’t create a session. That can also allow you to do some other sanity checking in your app or servers if needed. I’ve not done this in Web 2.0, so I am assuming it would work without testing it myself.