ThinkGeo.com    |     Documentation    |     Premium Support

Client & Server State

#21

Rob,  
  
 Glad to hear that you find out the problem. About the ViewState, we try our best to keep the minimum data for only synchronizing necessary states between client and server side. One possible enhancement is to compress the data before putting it in a ViewState but I’m not very sure whether the total performance will rise or not. 
  
 Thanks, 
  
 Ben 


#22

Clint, 
  
 I don’t have a comprehensive test for which part contributes most for the performance, but if I have a chance to set up a web server, I will buy a fast disk first. As first, getting data takes many I/O operations which are relatively slow; also as the image tiles can be cached on the disk, which means I don’t need to draw the data on the fly, instead just get the tiled image from the cache. A good fast disk is more valuable for that. 
  
 The Memory and CPU will not affect the performance too much; I think a mainstream quad-core CPU and 8G memory will be fine. Sure if the budget is enough, I will buy a better CPU, more memory … better stuff will always help :) 
  
 Ben 


#23

I have been playing around with using PageMethods instead of Callbacks to interact with the map.  
  
 In initial page_load, I setup my map and then save one of the dynamic overlays to Session. Then I am able to access the overlay within the static PageMethods by reading it from Session. From there, I can add and remove features from the layers within the overlay. 
  
 Everything works great so far, but I want to check with you guys if there is any reason I shouldn’t be doing this? It cuts my POST requests down from 32KB to less than 100B, as well as cuts out all the ViewState from the response. I realize I am killing ViewState, but the map is the only control on the page that has any sort of server state. 
  
 Also, If I’m storing an overlay or map in Session, is it storing a reference or the overlay/map itself?

#24

Rob, 
  
 Thanks very much for bringing this in our sight. We had a simple test following your description and so far haven’t find any problems. We will have more test in convenient time and maybe that method works fine. PageMethods is kind of a point to point connection, it is straightforward and has fewer overhead. Callback will experience most part of a web page’s Life Circle, which has more overhead. I didn’t tried using PageMethod only for the map, please keep me updated how it works in your project. :)  
  
 I’m not very sure about “storing a reference or the overlay/map itself”, I think the 2 are the same, both means the overlay/map itself. I think there only has difference between by Reference and By Value. 
  
 Thanks again for pointing this out. 
  
 Ben. 
  
  


#25

Ben, 
  
 Yeah, Reference or Value is what I meant. Does a reference or a copy of the value get stored in Session? shallow or deep copy? Would this prevent me from being able to use SQL server for session state? 
  
 -Rob

#26

Rob,



It stores a reference of the value in Session, and it doesn’t prevent you from using SQL Server for session state as I tested.



One thing you need to beware of is the object which has event handler can’t be stored into SQL Server; for example, the following object can’t store into SQL Server.ShapeFileFeatureLayer shapeFileLayer = new ShapeFileFeatureLayer(@"c\DonotExistFile\cntry02.shp");
((ShapeFileFeatureSource)shapeFileLayer.FeatureSource).StreamLoading += new EventHandler<StreamLoadingEventArgs>(LoadAMapFromStreams_StreamLoading);
If you have any questions please let me know.



Thanks,



Howard



#27

Howard, 
  
 Thanks for the info and the heads up. This looks very promising as a replacement to callbacks! I’ll keep the forum updated if I run into anything 
  
 -Rob

#28

Rob, 
  
 Thanks for this new idea; hope you enjoy it. 
  
 If you have more questions please let me know. 
  
 Thanks, 
 Howard