We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi All,
In the Net_config.c of KEIL Http_demo program, Number of simultaneously active HTTP Sessions is defined. (You can find HTTP_demo program in C:\Keil\ARM\Boards\Actel\SmartFusion\RL\TCPnet\Http_demo folder).
// <o>Number of HTTP Sessions <1-10> // Number of simultaneously active HTTP Sessions. // Default: 3 #define HTTP_NUMSESS 6
I cannot understand exactly what this number means. I thought it should be the limit how many computer can access the web server. I did the experiements, but it is not. Can anybody explain to me in detail so that I can know what number should be set in my application?
Thanks and Regards,
Lillian
What do you mean by "can access"?
Note that a HTTP request can be performed by open a connection to the server, send a request, receive an answer and close. But depending on bandwidth, that is not a zero-time operation. So while that happens, another web browser can connect and try to retrieve some information - or post something.
So the server needs to be able to have multiple, concurrent connections. A server that can have 10 concurrent connections aren't limited to 10 visitors. Just 10 people with a connect open at the same time.
Have you also browsed through the manual pages? Like: www.keil.com/.../rlarm_http_get_session.htm
Hi Per Westermark,
Thank you for your info.
My meaning is to open the web browser and access the web server.
My understanding from your info is I can access the web server with different computers that is no more than the HTTP Session number at the same time.
Can you confirm if my understanding is correct?
Thank you very much for your time.
The number relates to how many unique HTTP requests, where each simultaneous HTTP request corresponds to a separate TCP connection, the web server can handle simultaneously.
From this number, it is difficult to give a straight answer about how many different computers can practically visit the web site simultaneously. The reason for this is because when a web browser loads a web site from a web server, it typically opens several concurrent HTTP connections to the web server, so that individual component files of the website (.htm files, image files, script files, CSS files and so forth) can be fetched simultaneously, which gives a speed benefit over networks. (Furthermore, a given HTTP connection, if persistent (as is default with HTTP/1.1) could be used for several HTTP requests before being torn down.)
This means that, just as an example, your web browser will most certainly have opened up several HTTP connections to the server at http://www.keil.com to load the page you're looking at now. If you're using Firefox, install a plug-in called Firebug and look at the 'Net' tab. This will show you all individual HTTP connections that take place. (Similar diagnostic tools exist in other browsers too.)
HTTP connections, whether they're 'persistent' or not, are eventually explicitly closed by the browser or server, or time out. So, to load a web page, three or four simultaneous HTTP connections will initially open up to load the .htm source and other components, and then after a few seconds they'll have all shut down.
So, if even just two different devices' browsers try to load your embedded site at exactly the same time, you can see that even with just four HTTP connections available (for example), one browser may struggle to open up any connections and may show you an incomplete page (perhaps because it wasn't able to load the images or .css for example) or just show you an error. In reality the chance of someone requesting a page refresh at exactly the same time as someone else might be slim, so many different users could potentially occasionally visit your website without perceiving any issue.
On the other hand, if your web pages make use of Ajax to periodically refresh web page information with an update frequency in the order of seconds, then the browser will usually keep one or more persistent HTTP connections open to the site that never time out. This would then impact on the number of HTTP / TCP connections available to serve another browser in the meantime.
Hi Trevor,
Thank you so much for your explanation. I have a better picture now for HTTP session number.
Thanks again.
Glad to help. Just a bit more I missed from the last post:
So, the answer really comes down to the design of your embedded website, particularly in terms of how many other resources (images, etc.) need to be fetched alongside the HTML files, and whether or not you use Ajax (or other automated refreshing technique) that results in the browser making continuous requests to the server.
As a rule of thumb, I would consider 4 or 5 concurrent HTTP connections suitable for just one person to access at a time, assuming it's a moderately complex design (with many images and scripts, etc.) and makes use of Ajax for frequent real-time updates. If it's nothing but a simple text page with no other resources to load, then practically you'd probably be fine having several users visit it at once, even if it does use Ajax.
The Keil HTTP server does implement the correct headers to allow browser caching of non-dynamically-generated 'ROM' files (.htm, .js, .css, etc.) which helps minimise the amount of data a browser needs to fetch on subsequent visits. It is good to design an embedded site so that no page calls for too many other resources to be loaded in with it. A good trick, for example, is if your main page requires several images and script files, then you could pre-load some of those resources in your simple login page that is loaded first. The browser will cache them and therefore won't have to make so many requests for the main page that follows.