Let’s say you have a WebImageView and you are going to load a selected image into it.
Does it make any difference on the server workload if you load it from a URL on the server the app runs on, load it from a URL on a different file server, or if you embed the image into the project and load it?
The image embedded into the project seems to load faster (but, it could be my imagination), but if you have 1000 images, the size of the binary is quite large and I would assume it takes much more RAM to load the app.
I’m just trying to figure out the most efficient method before I increase the number of users.
Embedding into the project is way slower, and taxes app resources (memory, CPU), because the app has to do all the shoveling.
The fastest is to have the pictures on the same server as the app, and load them as URL. When used as aURL, a picture requires almost no resource from the app. The work is done by the host. And Apache or Windows Server are extremely fast.
On a different host, if it is not local, you will compound the transfer time between that host and yours, plus what it takes from your host to the client. With a mediocre connection at, say, 160 ms, it will take more than 1/3rd a second for each picture to reach the client, not counting the transfer time for the data.
Also, make sure to reduce the size of your pictures to a minimum. Make them exactly the size of the ImageViewer. In Photoshop, the option “save for web” makes pictures extremely small. Otherwise, there are tools to reduce the size of png, although not as efficient, but still much better than raw. On Mac, I use PNG Mini, but there are also for Windows, as well as online.
[quote=314814:@Michel Bujardet]The fastest is to have the pictures on the same server as the app, and load them as URL. When used as aURL, a picture requires almost no resource from the app. The work is done by the host. And Apache or Windows Server are extremely fast.
On a different host, if it is not local, you will compound the transfer time between that host and yours, plus what it takes from your host to the client. With a mediocre connection at, say, 160 ms, it will take more than 1/3rd a second for each picture to reach the client, not counting the transfer time for the data.[/quote]
This isn’t necessarily true. The image in a WebImageView is downloaded by the browser, so it could be that another server is closer to the client, has better outgoing bandwidth, etc. Being on the same server still does tax the resources of the machine that your app is running on.
That said, if your images are completely static I’d suggest putting them on a CDN somewhere. Chances are that they’ll end up being closer to the client in the long run anyway.
If that’s not possible, my next suggestion is to put them on the server, but not in your app.
Last resort is to put them in your app.
Keep in mind though… if the images are small (less than ~16K) none of this really matters. The time it takes to load an image and send that off is pretty much negligible.
There are lots of details we haven’t considered in this discussion so far…
of CPU cores makes a huge difference in this discussion because if your app and Apache run on the same core, they both affect one another. The more cores there are, the less likely this is to happen.
Memory. Most managed VPS configs I’ve seen which In the price range that people want have only 1 or 2 GB of ram. Again, your apps and Apache are fighting for resources.
Bandwidth. Your apps and Apache are vying for the total amount of bandwidth at any given time.
All that said, most web apps have a lot of idle time unless there’s a lot of background Threads running, so delivering small images from within the app won’t be as much of a hit. Browsers will cache the images that don’t change, so it’s important to use a WebPicture whenever possible because they return caching headers.
Generally when users are having speed issues, the first thing I suggest is moving downloadable resources out of the app to be delivered by a web server or CDN. It gets you the most bang for the buck, but is not without a cost whether it be $ or making the process more complicated.
Mine is a little peculiar in that is a quad-core but runs four copies of the app in a distributed format. As the number of users increases, I have very little impact on average processor usage, but my free -m memory decreases. I’m trying to figure out everything I can do to speed things up and reduce memory usage.
If you use a 4GB Xojo server, is it possible to have the server RAM upgraded?
I hope somebody here can share some technical information and specs on how to deal with the much larger amount of user simultaneously logged-in.
I mean, what if we have expecting 100,000.00 users simultaneously logged into the system. what type of computer hosting specification are we needing to support this kind of requirement?
You are in multiple dedicated server territory if you are trying to service 100k users at the same time. Generally only a small percentage of your population is using the app at any given moment in time. So if you have 100k potential customers its maybe 5000 max at any given time? Of course if its like a time clock application then everyone tries to clock in at the same time on the hour. You have to look at your usage requirements and plan accordingly.
I am assuming there are 2M users with 100,000 currently logged on simultaneously.
I am thinking about nationwide school enrollment which will be using xojo as the registration system.
Any reference that I can read on how to setup infrastructure to cater this huge amount of user?
Honest opinion: Seek out a managed hosting partner and have an adequate budget and do lots of testing. Any managed hosted provider should be able to give you some numbers.
The key here from a DevOps angle is how you operate and load balance several Xojo processes simultaneously. You will also need to choose a scalable database server.
This would be a very large project for any host as there are some unknowns:
How much memory will your process consume?
How many simultaneous users can a single process handle reliably?
How many simultaneous users will be online so we can determine number of processes?
Based on number of processes what kind of hardware is required?
For all of the above based on your numbers is A LOT.
Depending on graphics, recordset size, codebase, etc., I have found that I am far more likely to run out of memory than I am processor capability. I will occasionally have CPU spikes during complex queries of 60-80% for a few seconds, but that is rare. Typically, it seems to hover around 3-10% CPU usage.
I’ve had to learn a good bit about evaluating ‘free -m’ and ‘TOP’ to tell the difference between memory that is used for cache and memory that is actually being used, and I’m getting a lot of illumination about resource usage on this forum.
The point is–make sure that you don’t lock up resources and keep everything as small as possible.
Also, the geniuses as Xojo also setup a system for me that runs four copies on the software simultaneously on a four-core processor and distributes users to each app. For hundreds of thousands of users, I would think you would need something like that capable of distributing your app to many servers.