ThinkGeo.com    |     Documentation    |     Premium Support

Caching script resources

#1

Hello,


Mapsuite first time loading is too slow on some machines which has slower network connection.  i observed the http data by  fiddler2 and have realized that it takes approximately 10 seconds to fetch opl_GeoResource.axd which throws 580k of js file to the browser and it content's "Cache-Control" header is presented "private".   i decided to use caching for script resources and set all the script managers ScriptMode are "Release" and marked <compilation debug="false"> "<compilation debug=false>" in web.config and append <deployment retail="true"></deployment> "<deployment retail="true"> into machine.config file.  But nothing is changed.  </compilation>


<compilation debug="false">Is there any solution to cache these scripts?

</compilation>


Thank you so much.



#2

Hi Bora,  
  
 You did give us a great suggestion!  We checked the requests from the map and find the JavaScript library is not cached, we’ll add it in the upcoming version. Also, I tried your idea, but as the JavaScript is registered by hard code, it can’t be cached even using your method.  
  
 I made another test: I delete the hard coded JavaScript registering, add the requests into script manager and mark the script mode to “Release”, all the requests are cached fine. 
  
 It’ll be fixed in the upcoming version, but I’m afraid we can’t work it around in the existing version. 
  
 Thanks for reporting, please let me know if you have more questions, 
  
 Howard 


#3

Thank you Howard.  


#4

Hello Howard,


Bora is my senior developer and normally he is doing the map development. I just wanted to inform you that, this issue is quite important to us.


A significant portion of our customers are using low bandwith connections and we are getting a lot of customer complaints regarding the first loading time. 


We are using 3.1.16 and I would like to know the approximate release time of this fix.


Thanks,


Hakan.



#5

Hi Bora, Hakan, 
  
 The upcoming version will be released around the middle of next month, we can send you a temporary release version which have this issue fixed but not fully tested, please tell us if you want to use this temporary version before the public release. 
  
 Any questions please let me know. 
  
 Thanks, 
  
 Howard 


#6

Hello Howard,


We would be glad to have the temporary release with this fix as soon as possible and use it until the official release. 


How can we get it ?


Thanks,


Hakan



#7

Hi Howard,


I have encountered the same problem too and would like to use the temporary fix for the time being.


Please let me know where can I get the temporary fix.


Thanks.


Best Regards,


YV



#8

Hi Hakan, YV 
  
 We’ll send you the temporary version tomorrow. 
  
 In the new version, the JavaScript library’s Cache-Control is public by default; on the other hand, you can disable the default JavaScript reference, please see the code below. In this way, you need to register the JavaScript library manually, but you can use the release script mode in script manager you mentioned. 
  
     Map1.IsDefaultJavascriptLibraryDisabled = true; 
  
 Thanks, 
  
 Howard

#9

Hello Howard,


Thank you for the swift response and very very quick solution. 


This is not the first time that I'm very glad that, I've chosen ThinkGeo as the mapping solution provider for my company. You really give a meaning to customer support. Well done guys :)


Best regards,


Hakan



#10

Hi Howard,


After I apply the temporary fix, a javascript syntax error in opl_GeoResource.axd has been encountered in my application.


It seems like that this temporary fix doesn't work with InMemoryMarkerOverlay with CustomMarkerStyle (I use ValueMarkerStyle to create different marker image and popup based on different feature column value). If I use DefaultMarkerstyle (same image for all markers), then the javascript error will go away.


Is there any workaround that I can use to make this temporary fix work with CustomMarkerstyle?


Thanks.


Best Regards,


YV



#11

 


Hi Hakan,
 
It’s my pleasure to fix your issue. Your support is the source of our impetus, and with your suggestions, our product can be more and more powerful.
 
Any more queries please let me know,
 
Thanks,
 
Howard

#12

Hi YV, 
  
 We tested and recreate your issue, it’s a bug in this temporary version. We’ll let you know when we fix it. 
  
 Thanks for reporting. 
  
 Howard

#13

Can we get an option to minify (crockford.com/javascript/jsmin.html) and combine (and cache!) all the script resource files when in release mode? It can really cut down on overall filesize and request overhead to have a single minified file. It looks like the only thing that is minified right now is OpenLayers. 
  
 Speaking of caching, it doesn’t look like client side google tiles are getting cached. Or am I missing something? 
  
 Also, how do I make sure all the OpenLayer theme images get cached? 
  
 If i forgot anything…how do you cache it too?

#14

Rob, 



It’s a good suggestion; JavaScript library is not compressed because it’s easy for user who want to find or report the bug easily, on the other hand it enlarge the size of the library. We’ll update it for the next release.



Here Cache we are talking about is client cache which is managed by web browser such as IE and Firefox. 



I’m sure both Google tiles and OpenLayers Theme images are cached. 



Please click the Internet Options of IEà Settings à View Files to open the temporary file folder. You can find the cached images in that folder. The following images show the cached images of Google tiles and OpenLayers theme images. Cached file always has the high priority to be loaded by IE. The following picuture is the cached files on my machine.






If you have more questions please let me know.



Thanks,



Howard



#15

Howard,



I was mistaken about the OpenLayers theme images. When I check it out in Firebug I can see that they are getting 304 Not Modified. The Google Maps tiles are not coming from cache though.





Also, while digging around in Firebug, I found that when using a GoogleOverlays GoogleMapType of Physical, both Normal and Physical tiles are getting loaded. The Normal ones are never visible, but that is a lot of extra stuff to load for nothing.



-Rob

#16

Rob, 
  
 There are two methods to refresh a HTML page on IE; one is click the refresh button while the other one is to enter the URI in the address input. The first method refreshes all the requests no matter the address is cached or not while the other method loads from cache which is cached. I guess you use the first method to debug your cache. 
  
 I’m not very sure the meaning of your scenario. I guess you have two GoogleOverlay (Normal and Physical Type), and you can switch them by OverlaySwitcher on the upper right corner. When you load this page (Physical as default), both types requests are sending although Normal type is invisible. 
  
 Technically, the two overlays are added on the server side and it doesn’t render both of the overlays on the client side. It only renders by the time you switch it; in the meantime it becomes a DOM tree node in the HTML page. 
  
 As I tested, I can’t find other tile requests which are invisible. 
  
 Maybe I misunderstand your scenario, could you please explain it concreter.  
  
 If you have any questions please let me know. 
  
 Thanks, 
 Howard

#17

Howard,



I finally looked at things with a packet sniffer (Wireshark) and can see that the Google Map tiles are indeed coming from cache. Maybe Firebug gets confused since the tiles only differ by querystring.



Looking at the traffic confirms that both Physical and Normal tiles are getting pulled down though (only on initial page load). 

I first see a request for 

mt3.google.com/mt/v=ap.95&hl=en&x=0&y=0&z=0&s=  (Normal)

and then a request for

mt3.google.com/mt/v=app.87&hl=en&x=0&y=0&z=0&s=  (Physical)



To duplicate the problem, make a simple page with the following code


Map1.MapUnit = GeographyUnit.Meter;
GoogleOverlay googleMap = new GoogleOverlay(("GoogleOverlay"), GoogleMapType.Physical);
googleMap.JavaScriptLibraryUri = new Uri(ConfigurationManager.AppSettings["GoogleUri"]);
Map1.CustomOverlays.Add(googleMap);

-Rob

#18

Hi Rob,



We can’t handle it much for it causes by Google’s library. I even tested use Google’s API only and the issue still exists.



If you are interesting in this, please try the following script using Google map directly.function initialize() {
    if (GBrowserIsCompatible()) {
    var map = new GMap2(document.getElementById("map_canvas"));
    map.setCenter(new GLatLng(39.917, 116.397), 14);
    map.setMapType(G_PHYSICAL_MAP);     
    }
}
Sorry for the inconvenient, and if you have more questions please let me know.



Thanks,

Howard



#19

Howard, 
  
 I played around with the above code, and found that the problem is calling map.setCenter() before map.setMapType(). If you switch those 2 around, the normal images are no longer requested. When you call map.setCenter(), it is actually starting to download the tiles (before it knows that you want G_PHYSICAL_MAP type). 
  
 Can you change how you call those in the next version? Is there anything I can do in the mean time to work around the bug? 
  
 -Rob

#20

Rob,



You are right that it works fine when I switching these two lines of code and you can have this issue fixed in the next release. 

The following script can fix this issue temporary.
var OnMapCreating = function(map) {
    OpenLayers.Layer.Google = OpenLayers.Class(OpenLayers.Layer.Google, {
        setMap: function(map) {
            OpenLayers.Layer.EventPane.prototype.setMap.apply(this, arguments);
            if (this.type != null) {
                this.mapObject.setMapType(this.type);
                this.map.events.register("moveend", this, this.setMapType);
            }
        }
    });
}
If you have any questions please let me know.



Thanks,

Howard