Disastrous experience with Xojo Cloud

Targets Web
1

I have a really simple application - a page with 6 text areas that are initially disabled.

Clicking the “Start” button enables those 6 text areas for 10 min - a built-in stop watch is counting time.

The stopwatch design is very simple - the “Start” button gets the StartTime as microseconds, calculates exact time to finish by adding 10 min to the StartTime, and keeps watching CurrentTime using a timer. When CurrentTime is larger or equal to the FinishTime, the stopwatch stops.

When the stopwatch stops, all 6 text areas become disabled.

The “Download” button reads text in all 6 text areas, compiles them into one text file, and then downloads it.

It is very simple and tested yesterday a dozen of times by me and 4 other people. It worked stable, the stopwatch was accurate, there were no problem with downloads.

This morning running this application by 13-15 people simultaneously was a disaster.

  1. Some people including myself could not run it at all.
  2. Other people had a very sluggish performance.
  3. Others’ had their stopwatch showing 6 min of lapsed time on the built-in stopwatch while actually 11 min had lapsed already
  4. Getting into my XOJO Cloud account I found a message that I did not have any apps on my XOJO server in San Francisco.

We are using this app for medical students to practice patient’s notes within 10 min time constraints. One of their board exam requires writing a patient’s note within 10 min, and it is quite a challenge for the students.

TODAY EVERY SINGLE STUDENT OUT OF 15 HAD A PROBLEM WITH THIS APP.

Again, yesterday it was working perfectly well.

Now, at 21:30 before going to bed I decided to give this app another try - THE SAME PROBLEM - browser cannot connect to the server

I start the XOJO project, go to the XOJO Cloud in the left bottom part of the IDE, and then click Show Statistics button in the Inspector.

Guess what?! Server San-Francisco: Request Timed Out. Contacting Server … this messages sits there indefinitely.

I could understand that server can run out of RAM when there are multiple users use it simultaneously. I tested the app before with 20 users using it at the same time - CPU usage was less than 1% and RAM usage was 24% - 26%.

Right now I am the only one who attempts to use it - and THE BROWSER CANNOT CONNECT TO THE SERVER!

It might get back to working in an hour or so, and then it will die again.

Jason recommended to restart the server from the XOJO Cloud account. I just have done it.

Restarting the server over and over again reminds me a glitchy Windows ME that used to freeze all the time and needed to be restarted every 30 min.

I have ended up returning back to the desktop version of this software which works like a clockwork.

I had high expectations for XOJO Cloud and have got so far only frustration and disappointment.

2

As per Jason’s recommendation, to ensure that the application is not set to Aqutoquit=False, I’ve added the following code to the App.Open event


App.AutoQuit = True

Then I restarted the server, and started the application. The application loaded now … in the firs tab.

Then I opened 16 tabs with the app. The Server Stats shows 16 sessions running, CPU=6%, and memory usage < 1%.

Only 8 out 16 tabs are running the app. The reset are spinning in an attempt to load the app.

3

Is your site being blocked by the xojo firewall due to so many connections coming from the same IP so quickly?

If you’re on a static IP it might be worth asking xojo to add your IP as an exclusion?

4

@Val Kozmenko — I’m sorry you’re having trouble with Xojo Cloud.

I worked on your server earlier today and there were two big problems going on:

  1. Your app is not quitting properly. This was the reason Jason asked you to make sure AutoQuit was enabled, but if that’s not helping, the next most likely scenario is that you have a memory leak somewhere that is preventing Sessions from being closed. When that happens, the app will never quit even when all of the users have disconnected. Typically this is caused by a circular reference somewhere in your code or by having properties to hold things like the Session itself or other web controls. Remember, sessions have references to all WebPages that have Implicit Instance turned on and Pages and Dialogs have references to every control they contain. Make sure your code doesn’t create references in the other direction. I also suggest that you put some code in the UnhandledException events on both Session and App which log the exceptions to a file and see if you’ve got a critical issue which may be causing the app to become unresponsive.
  2. There were ~80 instances of your app running with about 60MB of free RAM left when I got to it today, most likely caused by what I described above. When available memory gets that low, the OS automatically starts shutting things down to conserve.

Another thing that concerns me is your note about opening 16 tabs. Xojo Web apps will actually only run a single instance in each browser on a particular machine. By opening multiple tabs, you are actually causing other instances to quit. If you want to test multiple sessions, you’ll need to use multiple computers (or VMs) and multiple browsers on each to get an accurate read on this.

5

Hi, Julian,

Thank you for your reply. I just tried to see how much CPU and RAM 15-20 sessions would consume.

Right now I am trying to narrow down the source of the problem:

  1. inefficient code
  2. insufficient RAM on the server.

If the problem was with the amount of RAM, I would consider to upgrade it.

If the problem is with the inefficient code, I would ask someone to take a look at it. I do not think the problem is with the code but who knows.

6

I would suggest you have someone experienced review the code. Another set of eyes helps on any project!

7

Hi, Greg,

Thank you for the reply. I have received your reply after answering Julian’s post.

Based on what you are saying, I can rule out insufficient server resources. So, the problem is in the code.

As I mentioned before, I’ve added an explicit App.AutoQuit=True as per Jason’s recommendation. I just do not know how to test it - I do not have 20-40 people to ask to run the app at the same time.

Hi, Tim, thank you for the reply, and for the help with the timers. I agree someone’s fresh look at the code would be helpful.

Thank you guys, at least I know that to solve the problem I need to clean the code rather than upgrade the server. It is 50% of the problem solved.

I appreciate your feedback, guys.

Talk to you later,

Val

8

Hello Val,

… I was reading your thread … if the consensus is coding issue, I’d start by checking your use of WebTimer (Note, WebTimer is a client side implementation).

I was waiting on a call, so I built a small example based on my general understanding of your goal (not your content).

I deployed it to Xojo Cloud here.

Happy to share the project file if it helps (although I’m not sure how to share) on forum.

Tip: when coding timed lessons, tests or quizzes, I reuse the Start button to implement a Pause/Resume feature (pause timer, disable data entry) as classroom sessions are inevitably interrupted. A Pause/Resume feature is implemented in my demo project (shared above).

Kind regards, Andrew

9

So if, as a trainer, I’m logged in as myself in a browser tab and I want to show another user how it works, I cannot just open another tab and log in again, as the second user — I must log myself out first?

10

You are using Web Timer? What is their resolution?

11

Sometimes the timers fire too rapidly maybe the system cant respond properly.

12

Right. The Xojo framework uses a temporary cookie to remember your session identifier. When you open that second tab, that cookie is sent to the app and it tries to “continue” from where it left off. It’s an easy way to get strange and inconsistent behavior.

13

Hello, all,

My web app is here

http://138.68.51.28/WEBNOTEWRITER_NO_VIDEO_10_min

EPNW

I can share the XOJO file with anyone who is interested to take a look at the code.

I can put it into a Dropbox and share.

Andrew, could you put your project into a DropBox shared folder.

Your app is doing exactly the same thing as mine. I would like to see your use of the timer.

Thank you very much to everyone.

Val

14

Just elaborating a little more, this is one of those “neither option is great” scenarios. The browser sends the cookie for all tabs, as there’s no such thing as a tab-specific cookie. Although private browsing would help to isolate them.

An alternative, which I believe was used at one point in Xojo’s lifetime, is to store the session id in the JavaScript memory while the user is on the page. While that “solves” the problem, it causes the new problem of starting a brand new session if the page is reloaded. That would be fine if the page is only reloaded intentionally, but it’s not, and there’s no way to determine the user’s intention.

So it is what it is. HTTP is stateless, cookies provide the state info needed, and the browser sends that info for all tabs.

15

[quote=488542:@Val Kozmenko]My web app is here

http://138.68.51.28/WEBNOTEWRITER_NO_VIDEO_10_min

EPNW

[/quote]
Just tried it here, worked fine with accurate timing.

16

Hi, Julia,

Thank you for testing the app. I have the same experience.

The problem arise when a significant number of people use the app at the same time.

I do not know how to test what affects the app’s performance.

Thank you again,

Val

17

Definitely your approach will not work here. Xojo is really bad with client side things. Your timer is not working on one side only, when your client side timer fires, it sends a message to the server and the server send a response.

You are making 100 requests each minute, multiply that by the number of clients. Maybe Xojo can’t handle that. Plus the messages to set the time display.

Options:

-Use a timer that fires only each 1, 2 even 5 seconds (not pretty on your display)
-Use a server side implementation to track time, send the messages to set the time display once each second.
-Create a user control with the sdk that display the remaining time client side only and send events each minute only.

18

Thank you, Ivan.

I am thinking how to overcome those limitations that you have mentioned.

I have a desktop application that does the same thing. The advantage of the web app is that the end-users do not need to install anything.

How about finding on the Internet a web-based timer and use it via an HTMLViewer? I am just brainstorming right now.

Val

19

Xojo needs client side only controls and client side only scripts, and from such client side only code and events we call manually remote (server side) methods. This way we can fine tune the traffic. A client side only timer writing the current elapsed time each second in a client side only Field costs zero, so we can count and set an “update the server” call sending the current time each 5 secs instead of 1. Not sure also how great is Xojo responding multiple connections without preemptive code and threading or at least “Isolates” spawning multi-processes with intercomm using shared memory/resources. But maybe this is conversation for a future API3. :smiley:

20

If someone is interested to take a look at the code, here is the link to the DropBox folder

XOJO project file

The web compiled and deployed from the link above is here

EPNW