Hi Serge, On Thu, May 22, 2008 at 1:09 PM, Serge Lages <[EMAIL PROTECTED]> wrote: > We've made lots of performances tests from 1 thread with a curl multi > handler to 20 threads with single handlers. Let's say that the version with > only one multi handler thread is finally the better one as having lots of > threads brought us lot of other problems.
Currently the SVN curl plugin only uses easy_curl, but does provide a mechinism for one easy_curl handle per calling thread. This allows the DatabasePager to run multiple http threads at one time. This seems to work stable at my end, but needs lots of testing. One thing that isn't yet handled is provision for http timeout, as right now if the easy_curl call is made is halt the thread indefinitely if the server isn't responding. I'm not yet familiar enough with libcurl to know whether we can do this with just easy_curl. It might be that we need to move on to using multi interface in libcurl. You probably have more experience with this than I, so thoughts/suggestions? > One thing we never test is multiple http threads with each multi handlers, I > don't know if it can really boost the performances. I expect it'll be a bit of double edge sword. Multiple http threads will mean that loads are started sooner in the multi-threaded case, but the bandwidth will be more contended so tiles will take loaded to read. If one thread can't make full use of the available bandwidth then perhaps have two or more threads might be a real boon. It has to be tested on real data of course, profiling it is an awkward part. My guess is that we'll need to add some specific profiling of the http RequestQueue's DatabaseRequest to see how long they take to get processed on average, then up the number of threads to see if this time goes down. > But from our experience, with http request, the most important to have a > fluid experience is to request the right nodes at the right moment, and > really try to minimize the useless calls. I even though to a system to be > able to request nodes even if there parents nodes are not still loaded (I am > not sure but I think Google Earth use this system). Agreed on the fluidity of the experience being critical. The changes made over the last week to DatbasePager are all about this aim, and from tests at my suggest things are certainly better. However, http requests are still way too slow on standard VPB built databases as the tiles are still pretty large. W.r.t better algorithms for pre fetching tiles, this is an interesting one. Right now the DatabasePager/ PagedLOD/ VPB are all built around a strict top down hierarchy, where you have to load the parent before you even know what children it has that are needed to be loaded. However, in the current rev of VPB the tile hierarchy is more formalised so it should be possible to compute the names and positions of the possible tiles that might be need at a given viewing position. However, just knowing what tiles might be needed won't solve everything as the scene graph needs somewhere to put all this loaded data i.e. a child has to be added to its parent, and if you don't know even what the parent point is yet, then you won't know up front where to add it. DatabasePager would need to be evolved to cope with this. The other possibility is to decouple the terrain and imagery from the scene graph, and preload more of an empty scene graph, or perhaps automatically generate this empty scene graph, that when you traverse it you on demand fill in the blanks (i.e. the missing subgraphs that do the rendering of the terrain). Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
