My question is related to @David_Cox presentation of the benefits of moving from Web 1.0 to 2.0
First of all congrats David. Nice and clear presentation.
It was mentioined, as one of the benefits that Web 2.0 supports a lager number of simultaneous users.
In Web 1.0 the number that people used to say one instance of a web app support is upto 50.
How many users are possible to have simultaneous in a Web 2.0 application ? Any had tested and have this number for sure ?
Thanks
There were a few changes in web 2 to support this claim (this was before I left soâŠ)
- All of the html rendering was moved to the client. In web 1, it was not uncommon for html to be rendered on the server and delivered to the browser as a simple insertion. In web 2, all data is sent as simple JSON structures and the html generation is done in the browser.
- The server in the back end was updated to be http/1.1 compliant. It doesnât sound like much, but with that came a bunch of optimizations which allowed it to create less sockets per session. This meant less overhead.
- We eliminated some high frequency client events. I know this is a contentious change, but we eliminated KeyDown which sent the entire content of a textfield or text area on every keystroke. The more data, the bigger packet size. That was especially hard on the server for the number of developers that truly needed it and we encouraged them make WebSDK controls that handle that requirement in the browser.
These all translate to the server being able to handle more sessions simultaneously, but thereâs no hard number (the 50 user limit in web 1 was for a very simple example). The number of users is highly dependent on how complex your app is and how much back and forth traffic there is.
One other change that was made was to convert the WebListBox to be âon-demandâ. That is, it requests pages of data from the server instead of sending it all at once. It makes showing hundreds or thousands of rows more server friendly as the only rows that are sent are the ones that the users are actually looking at.
1 Like
Thanks @Greg_O
No hard comparison available from Xojo ?
I supposed that a limitation that could justify the costs of such migration, or for new projects could involve a possible desition to use or not one language lile Xojo or other, and was mentioned as a benefit, that benefit was already measured by Cojo engineers
May be some one who alreafy migrate from Web 1.0 to 2.0 could share his experience at this particular point.
I understand that depends on the complexity and the resourse each applicatiin required, but for the same application it could be a reference of this supposed benefit that in theory, as Greg said it might be seen.
Theyâre in XDC London or on their way back from there. It might take a few days for them to recover.
I am back from XDC but still recovering!
Please note that the opinions I expressed are mine and not Xojo Inc. Also, please see my presentation as a guide, rather than a fixed consultation.
I have no research on the number of simultaneous users. My opinion was based on previous forum discussions (more than a year ago).
2 Likes
So you are doing an official presentation based on forum discussion which is not by any Xojo representative. What a pathetic situation. Now on what basis we will watch the XDC videos. How will i believe that your claims are tru or false as you havenât tested it by yourself.
3 Likes
Fact check false. My presentation, as I mentioned above, was not an official Xojo presentation, but by a regular Pro user who is in no way affiliated with Xojo, nor a MVP or representative. I have used Xojo Web 1.0 and 2.0 since their inception, and still maintain both Web 1.0 and 2.0 sites for professional clients, and so have both some knowledge of their usage and I have some âskin in the gameâ regarding my sites working efficiently. As mentioned above, my statements are based on forum comments of real, bona fide officials (see @Greg_O 's comments above).
I must assume your personal attack on my presentation (âWhat a pathetic situationâ) was either sarcastic, or a language issue, as normally this type of ad hominem comment is unwelcome in this Xojo forum.
3 Likes
BUT presented in an official Xojo event and whitout a disclaimer about the source of the claims being just a compilation of user comments.
You even quoted the SITUATION word but choose to make the coment about you. 
The translation makes it sound harsher tha it is but he is right in his comment about the SITUATION. Statements based just on âuser commentsâ make the even look lousy. No matter if it was not by a xojo team but it was presented in the oficial event (it is now in the oficial youtube channel also).
Guys, I donât want that a simple question that could be answer like:
âNo official tests had been doneâ,
and that could also be followed by a proposal of doing all together (Xojo engineers included) an stress test in order to have what I believe is a very important figure/number that could define in future projects if XOJO could be a choice or not for them,
generates such a discussion that has no sense at all.
I do appreciate and consider very valuable the presentation of @David_Cox at XDC.
It is also well known by most of us, that many of the speakers are experienced developers, like most of us, sharing their own experiences, and that it is a very importatn source of knowledge that could for all of us.
I also appreciate XOJOâs decision to share at no cost all the videos, and comments like the ones above do not contribute to the fact that in future XDCs XOJO continue sharing videos.
Returning to my original concern, is it possible to do some stress test in order to get a number and a comparison of possible simultaneous session for a Web 1.0 and a Web 2.0 Apps ? Make sense for someone else to spend time on this particular point and get an official number/comparison ?
4 Likes
Thatâs not a personal attack against you. What i meant is when you do a presentation on an official forum, you should be absolutely sure by testing by yourself and not by words heard.
As Iâve said many times before, any stress test for these optimizations will only be good for that one app.
- Yes, the back end is better at handling more connections
- yes, the amount of data transferred has been cut significantly
- instead of sending different versions of the framework for each Xojo app, all of the framework is sent in the first connection. Compressed, itâs a huge win for returning users.
All of this makes the data transfer much faster, but the reality is that itâs only a part of the story. What your code does and how it does it could easily negate all of these improvements if you havenât been careful. Using synchronous calls when async calls will block all other sessions while it waits. Long running processes should either be put into a thread which is set up to yield time or even better put into a console app and run on a separate core.
I had this discussion with many people over the years and usually the conversation goes like this:
Customer: I donât believe you
Me: you should try it
Customer: you need to prove it
Me: you really should try it.
Customer: canât you give me something concrete???
Me: no. Please do some comparisons yourself
âŠwait a few daysâŠ
Customer: Wow! My app is so much faster!
Me: who would have thought (shaking head)
2 Likes
Another thing to consider though. Web 2 is the way forward. It is based on modern frameworks, uses modern technologies, was designed to be extended (web 1 SDK was basically a hack), and designed to be easily upgraded.
Web 1 is not coming back. It has outdated technology and is going to be obsolete at some point. Heck, the back end uses HTTP/1.0. It wouldnât surprise me if support for that is removed from Apache and/or Nginx at some point, at which time it will be completely dead.
Sure, HTTP/1.0 is obsolete, but HTTP/1.1 was released on 1997 so using the âmodernâ card is kind of weird.
Just imagine that sales pitch from any other vendor
Customer: But how many HP has the car?
You: you should try it
Customer: you need to have something as reference
You: you really should try it, it depends on what road are you driving.
Customer: canât you give me something concrete???
You: No. Please build a Speedway to do some comparisons yourself
Maybe someone will buy it and be surprized, some others will not want to insvest the time to replicate functionality of their apps just to do some tests.
1 Like
Fine, Iâll use your car analogy⊠except that the customer said:
"I need to know how fast the car is going to go if Iâm towing a trailer with 20 or 30 cows in it. "
P.S. I have to keep reminding myself that you like goading people into fights instead of actually helping. Iâll go back to ignoring you again. Thanks for the reminder.
5 Likes
I donât know if there are services that could simulate client activity on x number of browsers. We see so many amazing things these days.
For example, we open the web app in a browser, we try to do some usual customer operations for 5 minutes. The service records what we did. And can then repeat these operations autonomously (not so easy, it should know to wait, etc.).
We do the same thing for three types of usage for example: low intensity, medium intensity, high intensity (time consuming and computationally intensive queries on the database, generation of large PDF or zip documents on the server, computationally intensive operations in Xojo, etc.).
We just have to ask it to do the same thing on 10 clients, then 20, 40, etc., also modulating the distribution of our clients (low and high intensity, etc.), bandwidth, speed, desktop or mobile, etc. The service would then show the response time of the server in each situation. And on the server side, we can also test with larger or smaller databases. This can also allow us to spot bottlenecks, operations that we forgot to thread, etc.
Of course, this would still be very approximate and we wouldnât be able to test every situation, but it would be better than nothing already. And if someone has done roughly the same app in Web 1 and 2, it would also help to see the rate of improvement.
I supposed that @Greg_O may be the new user of @Greg_O_Lone
Greg OâLone in the following post:
https://forum.xojo.com/t/cgi-many-connected-users
said on Aug-2020:
"By default, a CGI app should be able to handle about 50 concurrent users if the app isnât too busy. Itâs a tricky number to nail down because it has a lot to do with the other things that your app does.
You can increase this number to some extent by modifying the args array in the app.Open event like this:
args.Add(âMaxSockets=300â)`
The number of sessions is about that number divided by 4. So 300 would be roughly 75 sessions."
As at that time Greg was a Xojo Engineer, that means that it was an official affirmation and probably it was based on tests Xojoâs technical people had done.
Based on that, by that time, I had developed a Xojo WebApp in order to evaluate students. A simple 10 questions multiple choice examination.
It was an stand alone WebApp running in a Windows server machine with enough resourses to support many more than 50 simultaneous users.
With up to 30 simultaneous students works quite acceptable, but more than that start loosing connections.
When I assist to Davidâs XDC 2023 video, where it was said that Web 2.0 supports more simultaneous connections than Web 1.0, I asked my self and also here in this forum: How much connections ?
I insist that this would be a nice job for Xojo Engineers to take one particular WebApp (a multiple choice exam could be an easy and representative one) and established: for this particular WebApp, in this particular hardware, using Web 2.0 technology supports up to X simultaneous connections, while the same code, in the same hardware but using Web 1.0 technology supports only Y simultaneous connections.
Of course this will not be applicable to all WebApps and will depend on each particular WebApp, but it will give us an idea of how much improvement we could spect from Web 2.0 against its predecesor.
2 Likes
You are right. I think the same.
As an engineer, It is advisable to learn the limitations of everything you use. That includes the software and hardware. Itâs part of being professional.
Maybe you are not a specialist in SQL Server or PostgreSQL, but relevant to know how many records you can allow for a single table. Regardless of the memory space, it may occupy. Having an approximation is enough.
It is pertinent to know the maximum number of an integer type. The difference between using the small integer data type or another type depends on the language you use and the goal to fulfill.
Thanks to these details, an engineer knows that the limitation of the table is approximate. Of course, that depends on the number of columns and content of the database. With this information, you can decide whether to use MySql or PostgreSQL in an application. Maybe neither is enough and you decide on Mongo finally.
With this information, an engineer can give advice depending on the requirements and the goal. These are the ones worth hiring.
First of all, thank you @David_Cox for sharing your honest experiences while migrating to Web 2. Itâs been really nice meeting you in person!
@Mariano_Poli, I donât think there are extensive benchmarks to compare the amount of simultaneous users limit in Web 1 vs Web 2. With more modern servers, even Web 1 could be supporting more active sessions than it used to support. There is no hard limit other than CPU and Memory usage. The OS could be limiting also the amount of open sockets, but in real world apps I donât think youâll hit it, before hitting the CPU or Memory limits.
Still, yes, I believe Web 2 does a better job in that sense. Just to add a few more things to what @Greg_O already mentioned:
- Connection sockets are reused as much as possible in Web 2. Web 1 used to close the socket after writing the response, so any new communication had to open a new one.
- Web 2 uses EventSource for pushing new data to the browser, only when needed, instead of constantly polling for changes like in the previous framework. So in Web 1, if you had 1000 users connected at the same time, the server had to deal with 1000 requests every few seconds from the browsers, just asking if there are updates. This was generating more CPU usage and network traffic, while being just idle.
- As Web 2 is in active development, if we find anything that can be improved, weâll be able to improve it.
Other benefits:
- Sessions can be recovered now in Web 2, as David mentioned in his presentation, which is pretty handy when accessing the app from smartphones. In Web 1, whenever the connection was re-established, the browser had to refresh the whole page.
- Web 2 is also better at building APIs. Comparing a simple HandleURL in both versions youâll find Web 1 response time was between 50~250ms, while in Web 2 is between 20~30ms.
Initial version of Web 2 was released more than 3 years ago already, I wouldnât start any new project using Web 1 anymore.
9 Likes