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
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.