How does Xojo Web handle bursty request loads?

Targets Web
1

Hi all,

I’m considering Xojo Web as a framework for an upcoming project, but I wonder if anyone has any experience in this kind of use case.

I’m a DJ in broadcast radio and do a national radio show. The website I’m building is for contesting, giving away prizes realtime on the radio. Typically the way these sites work is they get a fairly low traffic load until I mention them on the radio, then thousands of requests come flooding in all at once, then things die down again until the next mention. It’s effectively a DDOS once or twice an hour.

What we discovered in the past is that things like Wordpress crumble under these loads unless you set it up with a fairly exotic load-balancing configuration, and that gets real expensive real fast. Like, too expensive to justify.

I’m wondering since Xojo web apps are compiled to native code and don’t have the overhead of the PHP interpreter if they may stand up better to such bursty request loads.

Does anyone have any experience with this?

Cheers

2

Hi Christian.

I’ve had a lot of success with Xojo Web apps that get heavy traffic - sometimes sustained, and sometimes in bursts. I think the reason for that success has been a combination of things.

First, as you mentioned, Xojo Web apps are compiled, which can give them an advantage over other Web technologies that require code to be interpreted.

Also, I’ve used a combination of load-balancing and rate-limiting, and I think that’s going to be important regardless of what Web technology you choose. If you run your Xojo Web apps behind something like nginx, then both load-balancing and rate-limiting are fairly easy to implement, and inexpensive, too.

I hope this helps.

P.S. I love some of those DJ mixes on your site, especially the 80’s Cheese Mix (Part 2) (https://www.christianwheel.com/post/80-s-cheese-mix-part-2).

3

Unfortunately a lot of scale type questions depend on the use case, in my experience with Xojo Web 1 (I’ve had limited experience of Web 2), above about 20 users for our use case was too much, so we needed to load balance based on 15 concurrent.

4

As @Tim_Dietrich suggested, the burden will actually be upstream from the app. This really isn’t a Xojo problem per se, but a general web serving issue. You should have load balancers and multiple instances/servers that you can spin up if the need arises.

5

I wanted to add my 2¢ that I don’t think in this case rate limiting would be a good method of load relief. The bursts aren’t coming from a coordinated DDOS, but rather a surge in actual users.

One thing I know about users who are experiencing issues is that they refresh the page. If you start rate-limiting these users, you’ll be blocking legitimate actual listeners who are already frustrated that your page isn’t loading.

6

Like calling the radio station repeatedly on Friday night in an attempt to win White Zombie tickets. I tried so hard to win those tickets. Anyway, just wanted to make the connection between the two industries represented here.

As for the original question, Xojo Web can be really robust on its own with a good load balancer, but I’d also mix in a fair bit of client-side JavaScript when possible to offload activity and only report back to the server when needed. How you implement this and for what features varies wildly depending on what your application does, but reducing the overall communication with the server is one way to optimize performance in any web application, whether it be built in Xojo or not. Try to keep the number of control event handlers you implement to only what you need.

7

You can read some about it in this thread: Multi-user web app with a great many simultaneous users

Long story short:

  • Xojo servers are SINGLE THREADED, so in order to serve many users you need a LOT of instances and load balancing
  • Being “compiled” it is kind of a bad thing here, it means you requiere more ram and cpu to run each instance (more expensive)
1 Like
8

Thanks everyone for your answers. Based on prior experience, at least in a case like the project I’m currently looking at, you go from around 5-10 simultaneous users to between 3000-5000 simultaneous users pretty much instantly, and within 5 minutes you’re back down to under 100 users. We quite literally were not able to spin up new server instances in time to meet the load before it dissipated, which means you just need to leave them running during the entire show window.

Serving static pages seemed to be no problem, especially with CloudFlare caching.

But dynamic pages really became a difficult issue to solve, and since I’m now doing it on my own without the benefit of a major broadcasting company’s infrastructure it might be more expensive than I can take on at the moment.

@Ivan_Tellez those are some great points, thank you for that.

@Anthony_G_Cyphers The key thing to remember when trying to win those contests is to sound really excited when they answer the phone. Things are different these days, but in the old days, if caller #100 didn’t have enough energy to sound like a good winner on the air, they were ahem more likely to experience a problem with a dropped call. It’s definitely not right, but I’ve seen it done many times. These days a lot of it is automated and there’s a lot more corporate oversight to ensure compliance with contest rules, so that’s an overall better experience for the listener.

@Tim_Parnell Spot on. People will spam F5 if the page doesn’t load for them. And then you’ll get complaints that the site wasn’t working and a few of those will complain to the FCC that your contest is unfair.

@Adam_Charlton Thanks for your experience with that. Load balancing based on 15 concurrent users when I’m expecting thousands is going to massively exceed what I’m capable of doing. From what I’ve read Web 2.0 is better in this regard but I’ll have to conduct some stress tests to see what I’m looking at.

@Tim_Dietrich Thanks for your comment. Load balancing is going to be key, and as @Greg_O mentioned, probably will be true no matter what I use if it’s not able to be cached by Cloudflare. Also thanks for the nice words about the mixes! One of the radio shows I do is in the same format as those 80’s mixes, we do 5 hours of that a week. Depending on your location it might be available to you locally, feel free to send me a private message and I can check if we have an affiliated station in your area.

2 Likes
9

If you’re using something like CloudFlare, then make sure static assets (js, css or any custom font you use) are being served from there.

Captura de pantalla 2023-09-07 a las 9.26.53
Captura de pantalla 2023-09-07 a las 9.26.53834×1062 58.8 KB

Play with those settings, it helps a lot.

3 Likes
10

Oooh CloudFlare! I think you have a subject here for the next time you need to do a blogpost or video. It would be interesting to see what kind of performance increases, someone with Xojo’s intimate knowledge of the framework gets and how they get it.

2 Likes
11

The catch with Cloudflare is that if you do any custom javascript or css work in your site in external files, every time you push an update you’ll need to log in to cloudflare and flush your site’s cache otherwise those changes won’t show up and could break your site. And even then, users whose browser cache TTL has not yet expired may still get a broken site.

I’ve also had issues with some CMS (specifically Wix) where turning on Cloudflare caching effectively breaks the site, because what should theoretically be static content really isn’t all that static. So test everything thoroughly when you use it.

3 Likes
12

We should be able to to help with cache invalidation for static assets, at a framework level. I’ll take a look to see if there is already a Feature Request for that :eyes:.

2 Likes
13

@Ricardo_Cruz please also see an older discussion Xojo Web 2.0 FastStart about some ideas for speeding up the startup process for a web app.

3 Likes
14

Zurück zum Thema.

Meine persönliche Erfahrung mit schwer beladenen, aber kurzlebigen Anforderungen ist, dass es nicht wirklich ein Problem der verwendeten Technologie ist, sondern wie man den ganzen Stapel zusammenstellt und kombiniert.

Was Ihr Problem ist:

  • In der Lage zu sein, 3K oder mehr gleichzeitige Benutzer zu bedienen,
  • die in Sekundenschnelle auftauchen
  • und die nicht sehr behutsam mit der Seite umgehen und definitiv nicht geduldig sind.

Was Sie brauchen:

  • eine robuste Website (= zuverlässige Technologie),
  • die bei Bedarf in die Luft gehen kann (= schnelle Skalierung),
  • die dann mit Tausenden von Nutzern umgehen kann (= Ausgewogenheit),
  • die nicht viel kostet, wenn sie nicht wirklich genutzt wird (= intelligente Einrichtung, automatische Skalierung)

Ich würde sagen, das ist Ihre Lösung:

  • Das sieht aus wie der typische Anwendungsfall für Kubernetes.
  • Dies ist die branchenführende Technologie für Skalierung, Lastausgleich und Anwendungsorchestrierung.
  • Sie containerisieren Ihre Software/Website (“Deployment”) und sagen K8s, wie es damit umgehen soll.
  • Sie bestimmen, wie viele Ressourcen ein Container erhält und wann es Zeit ist, neue Container zu erzeugen.
  • Ein Load Balancer (“Ingress”) innerhalb von K8s verteilt dann die Last auf alle Instanzen (“Pods”) Ihres Containers.
  • Je mehr Last das System sieht, desto mehr Pods werden erzeugt.
  • Wenn der Container die Grenzen des jeweiligen Servers überschreitet, kann er sogar einen weiteren Server starten und die Pods auf mehrere Server verteilen.
  • Wenn die Anzahl der Anfragen oder der Ressourcenverbrauch sinkt, werden die Pods und Server auf ein Minimum reduziert.

Das Problem dabei ist:
Die Einrichtung eines solchen Systems ist sehr komplex. Es ist nicht so, dass man hier und dort klicken kann. Es ist alles Code und man braucht zumindest ein wenig Erfahrung, um es einzurichten. Außerdem kann es sehr teuer werden, je nachdem, welchen Dienst Sie nutzen (GoogleCloud, AWS usw.) und wie Ihre Konfiguration funktioniert.

Meine Schlussfolgerung:
Ihr Problem ist nicht eine Frage der verwendeten Programmiersprache, sondern der verwendeten Umgebung, in die Sie den Dienst stellen. Ich persönlich würde Xojo aus vielen Gründen nicht für ein solches System verwenden, aber mit dem richtigen Setup können Xojo-Webapps für diesen speziellen Anwendungsfall eingesetzt werden, genau wie jede andere Webtechnologie.

So your best bet is to build a load balancer, directing the load between multiple servers, which you can turn on and shut down manually when your show runs and which only produces costs when they run.

15

@Lars_Lehmann 我們要么都用英文寫，要么用中文寫

16

We have had a community member flag raised about this topic so I wanted to request that you keep your replies to English. If you’d like to carry the discussion in another language, please see the International categories here for discussion in your native language.

2 Likes
17

@Dana_Brown
I find your request not consistent. Many times there are questions / replies in Spanish / Portuguese / Italian /… and no requests were done to those persons to have their questions / replies in English. Now all of a sudden a German reply (not my native language) is requested to reply in English. Please be consistent and ask all persons that do not reply in English to do so.

1 Like
18

It looks like her request has come from member flags; Dana just forwarded the request, I’d think.

5 Likes
19

This means: “We either write in English or in Chinese.” So you can guess who it was.

1 Like
20

That’s correct. To be clear, it’s not a forum policy but a flag was raised with the request so I posted it on their behalf. Perhaps this user didn’t want to reply themselves with the request.

2 Likes