When moving from standard Xojo Cloud to Cloud Pro, we found that the number of sessions given by App.SessionCount no longer gives the true total. Since Cloud Pro runs on several CPU’s, it will only give you the number of sessions running on the specific CPU.
This is not to say you shouldn’t upgrade to Pro (can actually recommend it), but you do need to implement an administration of sessions if you need the true total.
Did you forgot about the multiple instances?
Perhaps you have 2 or more vCPU and xojo has multiple instances of your Web App running, you’ll only see the information of one of them when browsing.
Yes, your Large server has 6 virtual cores whereas your Small server has only 1. This means that on the large server there are 6 instances of your app running in parallel. The load balancer will automatically distribute sessions so that the load will stay relatively even between them. What you are seeing is that each of your connected browsers is running by itself in its own app.
If you need to communicate between the instances, I suggest creating a sqlite database into which you store the session ids from each of the apps and whatever details you need to share with the others. If you need to communicate, you could create a message queue in the sqlite file which records the creation and expiration dates for each. Expiration dates would be used to purge the messages so the db doesn’t get huge, creation dates allow you to not send the messages to an instance that has just started up if you record when they launched last. You’ll need to keep track of the last message read by each app so they don’t read the same ones over and over.
Keep in mind that however unlikely it’s entirely possible that Session identifiers could be identical between the instances of your app, so make sure you store some other unique identifier for each instance, like app.port.