We carried out some recent bandwidth testing on our system, we had a device positioned between our 'server' and our remote 'WebClients'.
we noticed that once a panel was loaded there was not any noticable difference, we started at 2mb (our site speed) and went down to 64k.
The only noticeable difference was the loading of the pages into the 'cache', although even at 64k this was acceptable. Overall the system was very good with an ideal speed for us at around 512k, mainly for when we are loading/transffering documents/pdfs into the 'cache' etc.
A number of tests were carried out but 2 issues arose that we need to resolve.
1. When we introduced latency in our tests, even at 1 second, this caused considerable delays when starting a webclient.? any thoughts on this?
2. It may be an option on slower connection speeds to not check panels/folders for changes and load each time but to change this to load on an event basis. ie. once a day. is this possible?
Regards
Jason
http webserver bandwidth test
- mkoller
- Posts:741
- Joined: Fri Sep 17, 2010 9:03 am
Re: http webserver bandwidth test
> 1. When we introduced latency in our tests, even at 1 second, this caused considerable delays when starting a webclient.? any thoughts on this?
Don't know how you introduced the latency, but when each and every TCP package is being delayed by 1 second, than clearly the communication will be very slow.
Depending on the size of your project - or to be precise - the size of your DpTypeContainer (number of DpTypes, number of DpElements and their names) and the size of the DpIdentification(!) (number of Datapoint names, description texts(!), alias names), which need to be downloaded from the Data Manager each time the WebClient (any Ui Manager) starts up, this can take a considerable amount of time.
> 2. It may be an option on slower connection speeds to not check panels/folders for changes and load each time but to change this to load on an event basis. ie. once a day. is this possible?
Currently the WebClient checks for newer files always on the first request of a file (after WebClient startup), and after this only if 5 minutes have elapsed since the last request for a specific file. If during these 5 minutes the file is requested again, and it is already in the cache, no HTTP communication will occur.
The 5 minutes timeout can be configured ([ui] cacheTimeoutSecs = ....) and can even be set to 0, which means that the
WebClient will never(!) try to refresh the file (no HTTP traffic) if the file is already in the cache.
However, there is currently no mechanism built in, which allows to trigger a refresh.
I can imagine that this could be done via an extension to the _Ui internal datapoint.
Note: there was a problem with the check for newer files on Windoze:
"On Windows, the WebClient sends - sometimes - a wrong If-Modified-Since timestamp in the HTTP request message to the server (-3600 seconds to correct time), which leads to the server sending the file again, despite it has not changed.
Analysis shows: A file with a timestamp in summertime (e.g. 29.June 2010) works, where a file with a time in wintertime (e.g. 26.March 2010) does not work."
This has been fixed with Patch 029 (ask the support)
Don't know how you introduced the latency, but when each and every TCP package is being delayed by 1 second, than clearly the communication will be very slow.
Depending on the size of your project - or to be precise - the size of your DpTypeContainer (number of DpTypes, number of DpElements and their names) and the size of the DpIdentification(!) (number of Datapoint names, description texts(!), alias names), which need to be downloaded from the Data Manager each time the WebClient (any Ui Manager) starts up, this can take a considerable amount of time.
> 2. It may be an option on slower connection speeds to not check panels/folders for changes and load each time but to change this to load on an event basis. ie. once a day. is this possible?
Currently the WebClient checks for newer files always on the first request of a file (after WebClient startup), and after this only if 5 minutes have elapsed since the last request for a specific file. If during these 5 minutes the file is requested again, and it is already in the cache, no HTTP communication will occur.
The 5 minutes timeout can be configured ([ui] cacheTimeoutSecs = ....) and can even be set to 0, which means that the
WebClient will never(!) try to refresh the file (no HTTP traffic) if the file is already in the cache.
However, there is currently no mechanism built in, which allows to trigger a refresh.
I can imagine that this could be done via an extension to the _Ui internal datapoint.
Note: there was a problem with the check for newer files on Windoze:
"On Windows, the WebClient sends - sometimes - a wrong If-Modified-Since timestamp in the HTTP request message to the server (-3600 seconds to correct time), which leads to the server sending the file again, despite it has not changed.
Analysis shows: A file with a timestamp in summertime (e.g. 29.June 2010) works, where a file with a time in wintertime (e.g. 26.March 2010) does not work."
This has been fixed with Patch 029 (ask the support)