Please Tell me.
I found it hard to reach it that a i5 CPU, 8G DDR3, + 500G HDD Mac Mini Server can reach this performance.
How to optimize XOJO Web app?
And I found when open a XOJO Web page then close, when you open and close serveral, then you re-open it, found it becomes very slow.
Please discuss it.
Is this a CGI or stand-alone deployment?
I would always try to balance. Running 4 instances at least so you benefit from multi core CPU
Ju, if you open and close the webapp in your browser fast after each other then probably your browser is the problem for the slowdown. Each time if you open the webapp again fast the previous session isn’t probably not jet closed and the browser hasn’t released it fully.
Please try this: open say 7 or 8 new windows with your app in your browser and then try switching from one to the other and test the speed. After that to compare try the same in 7 or 8 tabs and you will see that then the app will be incredibly slow.
Then try this with 3 or 4 different brands of browsers and you will see that each have a limit of about 5 to 7or 8 tabs to get a serious slowdown. However if you open in each 5 to 8 windows with your app everything will be reasonably responsive.
BUT ofcourse if your webapp puts a high demand on the cpu power (heavy calculations or picture resizing etc) it will be slow and only faster hardware can help.
I’ve run a stand-alone on a system not as up-to-par as that, and have had several hundred connections at once with no problems. Something else is going on that’s causing your issues (code related, using CGI instead of stand-alone?)
Another possibility: if you’re using Apache+WE CGI you have to make sure that you are using a persistent form of Perl (i.e. mod_perl). If Apache launches a Perl interpreter on every CGI call it kills performance.
actually simultaneously? impressive. 
What type of application?
This limit of about 20 to 50 concurrent users often returns.
Obviously, each web app is different, each server is different, every client is different. But now that there are many users who have experience with Xojo WE would be good to start a thread with for each:
For one instance, before any load balancing
And of course the number of concurrent users before the application to slow down.
or if you think that all this information is confidential,
only the type of application, the type of server, and the number of concurrent users you think?
(or write in the xojo pro channel?)
Someone could start the thread? my english is terrible.
[quote=93804:@olivier vidal]actually simultaneously? impressive. 
What type of application?[/quote]
It was a rate calculator for various underwriters in the mortgage title insurance industry. It only had one small image (a logo) on the page. The rest was form objects. The submits would call an external console application to pass the arguments to handle all of the calls, then return the calculations into StdOut… which the web application CGI captured and returned. Not sure why everybody seems to be having issues with simultaneous connectivity. Perhaps external applications handling most of the non-related processes helped me out, or the fact that I wasn’t using a lot of graphical content? Anyhow, even during stress testing the site… I believe it was the 10MB pipe that ultimately slowed it down for me when too many connections occurred. I think with the right optimizations and coding techniques, you should be fine with most anything you wanted to used XOJO WE for.
Thank you Eric! I understand better now. This is a lightweight web app and at the same time well optimized.
Perhaps due to more complex applications? (accounting …)
many loads of pages or containers, many database operations …
Unfortunately i wasn’t able to find a mod_perl for an Apache server on Windows, do you have a link to such module?
I know i asked this before but even with your answer then, i wasn’t able to find it. I would be very gratefull if you could give me a direct link.
Anyway thanks for taken the efforts.
What is good with the return of Eric’s experience is that we know that a xojo web app (Standalone), simple, on a dedicated server, without apparently database, and calculations on a deported app, can handle hundreds of connections (Eric stated 500 in another thread).
This gives us an average upper limit. it would be nice to have a feedback for a lower limit, with a complicated web app, making many calls to a database, without load balancing and deported app.
Put a tight loop in your app, and I bet you could get it down to 1.
I hoped the maximum number of users with a very demanding application, a large database, on a single core (without deported app), without load balancing.
[quote=94142:@olivier vidal]
I hoped the maximum number of users with a very demanding application, a large database, on a single core (without deported app), without load balancing.[/quote]
I know what you’re asking for and there isn’t a hard and fast rule. It depends on a lot of things including which database server you are using, how close it is (is it on the same computer, in the same datacenter, in another city or another country for that matter), how far the users are from where the app is located, but mostly it depends on what your app does when a user event comes in. If you query a database and send 10,000 rows to a listbox without a thread, the app will bog down if several users do that at the same time. Highly interactive apps (those that require a lot of input from users) are going to require more server resources than one where the users do a lot of viewing/reading between clicks.
My apps typically have a small number of users, but uptime is paramount so I host the app on multiple servers. I have several small utility apps hosted on each server so I’ve not been too concerned with trying to load balance an app…but I have to wonder…how do normally do this? Sure I can start several instances of my app… but they can’t all be listening on the same port number right? So to run four instances…I’d need to have compiled my app for four different port numbers (assuming stand-alone deployment) .
Don’t know how could guarantee that the program would run on a different core each time (except that starting the app on a core makes it more likely a different core will be selected for the next core…but that’s not a given right?
Can you clarify that you are saying here that if we need to do this then the querying the database part should be in a thread and store the presents in a property and then send the result of said property back to the browser outside the thread, this that correct as I understand that a thread cannot directly interact with the UI?
Threads in a web app can update the UI. It’s very different than a desktop app. However
Can you clarify that you are saying here that if we need to do this then the querying the database part should be in a thread [/quote]
You shouldn’t do this at all. You shouldn’t even do this in a desktop app. Page the data in.
Thanks Tim, ah I didnt realise that threads could update a web app ui, that makes a big difference to how I am currently doing things. So would you have a thread that reads the database and updates the listbox UI and a timer to check when the thread had finished?
Regarding the 10,000, this was simple concept to imply a volume of data, I appreciate that it should be paged, thanks.
You really should follow the thread ui rule on the web too. It translates better if you ever need to spin the process off into a separate app. Use a thread to retrieve the data and a timer to periodically grab 50 or100 rows and send them to the browser. You’ll be much happier in the long run.