Apparently, CGI has been optimized recently. it’s been awhile since I had not tried it, so I did a basic test. With my web app (intensive queries), I did a little comparison.
For me, CGI is always much slower. It has other benefits of course, but it is slow. With my web app, a request is an average of 70 ms. With CGI, it takes at least 200 ms. For example, when I click a button to scroll through pages of data, I sometimes have to wait a little with CGI, while in Standalone it’s almost instantaneous. If I quickly click 5 times, Standalone quickly display the 5 pages. With CGI, it will show two or three pages at best, and the user feels.
Importantly, this test was done with a single user on a powerful server. With the reverse proxy, I forgot to note, but it was close to Standalone, maybe 10% more.
example with CGI:
with Standalone:
Of course, all applications do not require the speed, but when it does, CGI is still a little slow. Especially as waiting times are cumulative.
[quote=127036:@olivier vidal]Apparently, CGI has been optimized recently. it’s been awhile since I had not tried it, so I did a basic test. With my web app (intensive queries), I did a little comparison.
[/quote]
Thank you for this benchmark results, Olivier. Very interesting.
You can see in my CGI example. At one point, the query takes 1 second, because when I click the button (and I’m sending a query), the browser has not yet received the results of one or two previous requests. It was at this point that requests take 700, 800, 1000ms (instead of 200-300), so I clicked much more slowly, and at the end, the requests down to 300ms. But in the meantime, so I had to slow down voluntarily, because the result was not satisfactory. (especially, these are ideal conditions: a large server, a single user).
The response code got some more love in 2014r2 and 2.1. Two things specifically:
GZipped responses no longer use a compression of 9 (maximum). We found that the savings was not worth the time involved.
All responses are now gzipped if the browser supports it. Previously we were compressing only framework files, but now, if a response is > ~256 bytes it is compressed.
Fixed some more places where we were not honoring the browser’s cache, so if the browser’s already got a current version of a framework file, we don’t send it again.
No comparison, CGI is considerably slower. I couldn’t figure out why Xojo was so defensive of this obvious fact except that Xojo Cloud uses CGI? You can load them side by side and you don’t even need the numbers to verify it. Standalone (even behind a load balancer) is significantly faster.
CGI is much simpler to use, though. No need to make sure it runs. But indeed the results of the test are good food for thoughts.
Phillip, at one point you mentioned using a php script to launch automatically a standalone if needed, and redirect the user to it. I had thought about doing that as well. Have you had time to think about it ?
I’m working on a dynamic load balancer that inherently understands Xojo apps. When the appropriate Xojo app is not found it forwards the request to Apache where it can serve anything and/or Xojo apps in CGI mode.
This is the current version. It’s really weird that Xojo persists in this direction for years, especially since it requires them to maintain several types of deployment.
Why?
it’s still very simple. You copy the web app on the server and you type a single line to start the service (on Windows). The service will restart the app automatically each time the computer reboots.
Of course, the app can quit, but there is no reason. Especially, if the application quits, it’s worth checking data integrity, etc., before restarting the app. And with one click, you restart the app.
You can also take a Windows server (ovh.com: less than $ 10 per month for a VPS, Windows server included). The host then sends you a password to use the remote desktop. You will see the desktop of your server on your screen, you can then work normally, without needing to know the SSH commands, powershell, etc.
And if you want to use the reverse proxy, it’s also very simple. IIS (web server) comes with Windows. Abyss webserver is even simpler, optimized for Xojo and easily usable, GUI, and a very good support. You install it, click on “reverse proxy”, specify the application port, and that’s it!
(I hope this is understandable, it is difficult for me in English)
I did some testing a with r2.1 a while ago. Have some cgi running at 1701, server here in NL (Ams) and same app as standalone on some machines. Both do quite good, I have a slight preference for standalone. For production you need more locations and an active loadbalancer I think, just to guarantee up time. But, in this thread I got to know Philip is working on it.
Don’t forget that a lot of users, although competent in Xojo, have extremely limited skills when it comes to web hosting. In you case you have a Windows box and launching the program is easy. Some other users over here have purchased VPS and do not really know how to use SSH, or worse, use hosted services that have no SSH access at all.
Note that I did not write cgi was better, just that it is easier. Most people are able to figure how to upload cgi to their site the way they would proceed with HTML. Although not awfully complex, standalone requires more doing.
Although I largely possess the knowledge to access SSH, when I decided to use Xojo last year to for instant software delivery, I simply did not know what standalone was. Xojo documentation was unclear and lacked a very simple step by step how to which Brad Hutching later posted in the forum. But when I was alone in front of my computer, as I said, cgi was way easier. Just as I had done since 1996 with Perl scripts, I uploaded the Xojo cgi, and was in business. Note that even 1/3 of a second is absolutely nothing for an application that delivers download. It would be different for a program that requires a more responsive UI.
That is why the benchmark above is extremely precious to make an informed decision.
If I had known the best response time I could get from a CGI app running on Xojo Cloud is 300 ms, I wouldn’t have considered Xojo Cloud. Simple is one thing. Responsiveness is another. Looks like we can’t get both with Xojo Cloud or CGI or both. Based on test above, it looks like it is worse than 300 ms if user tries to get another response before the prior response is complete. If user keeps clicking and clicking trying to get a response out of the app (further increasing the lag), then that will seem like a crash to the user.
I am working on optimizing right now but it feels like I am fighting a losing (and pointless) battle.
We need someone at Xojo to tell us things are not as bad as they seem. We also need some way to pinpoint the bottlenecks and cumulative slowdowns (via responses that are required faster than 300 ms or via many pages in the app). I have a feeling that the cumulative slowdowns are due to glitches that don’t manifest as errors. I need some answers very soon.
[quote=129468:@Ken Gish]If user keeps clicking and clicking trying to get a response out of the app (further increasing the lag), then that will seem like a crash to the user.
[/quote]
You must make sure such a loony behavior from a user is taken care of. In particular, disabling a button while an operation is not complete. Using some sort of visual confirmation such as a ProgressWheel is a good idea to prevent user panic and irrational clicks.
Unfortunately, standalone or cgi are never immune from crazy compulsive clickers
I do hide buttons for this very reason whenever I can. There are some instances where I can’t hide buttons (long story) but it doesn’t matter because I block button presses in code after the first successful press.
The problem is that the slowness is so bad that the user has to be in the habit of responding slowly which is unacceptable. When the interface is slower than normal human responsiveness, it doesn’t work.
I have had to disable audio feedback with button presses because it is just too slow (way worse than 300 ms, more like 5 seconds or longer). The feedback is useful because it lets people know their response has been registered so they will tend to be more patient.
I am now in the process of doing preloading of a bunch of images because near the end of the app it is always WAY too slow. No error messages but the app has effectively crashed.
[quote=129490:@Ken Gish]The problem is that the slowness is so bad that the user has to be in the habit of responding slowly which is unacceptable. When the interface is slower than normal human responsiveness, it doesn’t work.
[/quote]
Indeed Web apps are slow as compared to Desktop. But unfortunately, this is the nature of the Internet. Even super big companies the like of Facebook and Google do not have instant response.
I do not know of any easy and fast audio, but visual confirmation can be instant by using client side JavaScript instead of server side Xojo code. It is extremely easy to have an instant display of a picture, and animated GIF such as those available at this link make it great. http://mentalized.net/activity-indicators/
I know that some lags are inevitable. What I am talking about is significantly worse than typical acceptable lags. Delays on the order of 5 seconds or longer are not acceptable to most people.
It just took over 1 minute to load the final page of my app on Chrome (which is usually faster). It runs even slower on IE11. While this might point to local issue, I don’t believe that’s the case. I believe this is a server and/or a Xojo issue.
[quote=129498:@Ken Gish]I know that some lags are inevitable. What I am talking about is significantly worse than typical acceptable lags. Delays on the order of 5 seconds or longer are not acceptable to most people.
It just took over 1 minute to load the final page of my app on Chrome (which is usually faster). It runs even slower on IE11. While this might point to local issue, I don’t believe that’s the case. I believe this is a server and/or a Xojo issue.
Unacceptable.[/quote]
Back in the 80’s, IBM considered two seconds the limit of an acceptable response time. Since then, Internet went bravely into new frontiers of half a minute or more…
One minute is indeed much too long. But what is the time it takes in the IDE ?
Granted, each request takes 200 ms instead of 70 ms, but after that, the transfer time of pictures is only limited by the speed of your internet access. Five minutes would correspond to 300 requests. Do you have that many controls on your WebPage ?
