PDA

View Full Version : [CLOSED] [#364] CDN Subjects/Comments/Questions.



michaeld
Jun 20, 2013, 7:03 AM
Why isn't CDN turned off automatically by resource manager when Request.IsSecureConnection? I have to do this myself.

Feature request maybe?

michaeld
Jun 20, 2013, 7:12 AM
While I'm at the topic of features related to cdn? Is it possible to only cdn from the extjs js and resources? and not the Ext.Net js and resources? The reason I ask is I have to stay on the ext.net trunk for the latest fixes which includes extjs overrides.

I am assuming also there's probably no way to cdn from ext.net also and only post updates since the last build. ;)

michaeld
Jun 20, 2013, 7:29 AM
Also, a speed test tool has reported that the cdn (speed.ext.net) does not gzip it's content. Is that something that can be addressed? I realize the CDNs will bring content faster to the user based on high bandwidth and localized availability, but it would even be faster if compressed.

michaeld
Jun 20, 2013, 7:45 AM
I have found also that the ux js on the cdn is not minified even with min mode set.

michaeld
Jun 20, 2013, 12:31 PM
In ResourceManager_Globals.cs - I will understand if you opt not to consider adding this shortcut, but it works with low footprint...


using System.Diagnostics;
using System.Reflection;


#if ISPRO


/// <summary>
///
/// </summary>
internal static string CDNPath
{
get
{
if( string.IsNullOrEmpty( CDNPlusVer ) ) {
var ver = FileVersionInfo.GetVersionInfo( Assembly.GetExecutingAssembly().Location );
CDNPlusVer = string.Format("http://speed.ext.net/ext.net/{0}.{1}.{2}", ver.ProductMajorPart, ver.ProductMinorPart, ver.ProductBuildPart );
}
return CDNPlusVer;
}
}
private static string CDNPlusVer = null;
#endif

Daniil
Jun 20, 2013, 1:23 PM
Hi @michaeld,

1. SSL CDN

Yes, currently, CDN doesn't support SSL to request the resources with "https".

So, you need to turn CDN off to avoid a security warning because of requesting the resources with insecure "http", is that correct?

2. Getting ExtJS resources from CDN, but not Ext.NET

Generally, it is not correct to organize the things such a way. Ext.NET scripts tightly depends on ExtJS scripts. They must be the same version.

3. GZip

Thank you for the report. Seems the main ExtJS script comes not gzipped from CDN. All the rest resources seems to be gzipped. We are investigating.

4. UX not minified

Yes, we have no minified versions for UXs. We have some thoughts and plans on this, but no concrete time frames at the moment. But anyway, it won't provide much benefit since the UX resources are very small.

5. CDNPath

Thank you for the suggestion. We will consider.

Daniil
Jun 20, 2013, 2:55 PM
4. UX not minified

Yes, we have no minified versions for UXs. We have some thoughts and plans on this, but no concrete time frames at the moment. But anyway, it won't provide much benefit since the UX resources are very small.


Created an Issue:
https://github.com/extnet/Ext.NET/issues/279



5. CDNPath

Thank you for the suggestion. We will consider.

A nice suggestion. Added to SVN trunk. Thank you again.

michaeld
Jun 21, 2013, 12:29 AM
Hi @michaeld,

1. SSL CDN

Yes, currently, CDN doesn't support SSL to request the resources with "https".


Presently I have to do the following:


rm.RenderScripts = Request.IsSecureConnection ? ResourceLocationType.File : ResourceLocationType.CDN;
rm.RenderStyles = Request.IsSecureConnection ? ResourceLocationType.File : ResourceLocationType.CDN;


It just makes sense to me that this logic should be moved inside of the ResourceManager rendering. A check for IsSecureConnection, and if so, override back to default. Anyway, it's just a thought since this can cause an issue for clients who have secure pages since your cdn doesn't support secure. It's actually kind of frustrating this is the case because https already causes otherwise cached pages to be slow because the different port causes a full load (thus slowing this page more than the rest of the website).


So, you need to turn CDN off to avoid a security warning because of requesting the resources with insecure "http", is that correct?

Effectively, yes. It's a shame this is the case since there is nothing insecure about the contents.


2. Getting ExtJS resources from CDN, but not Ext.NET
Generally, it is not correct to organize the things such a way. Ext.NET scripts tightly depends on ExtJS scripts. They must be the same version.


If we keep this feature request very basic, this comes down to breaking out /extjs which includes 2 files [js & css] from /extnet/ which includes 2-3 files depending on resource manager config. The extjs js file is the largest component of the entire application.

We understand that extjs resources version separately from extnet, and extnet is always based on a specific version of extjs. So nothing about your statement changes. You're still tightly bound to an extjs version because the trunk code is bound to a specific version of extjs on the cdn until you decide to upload something new on the cdn or reversion the trunk.

The most important aspect about this cdn feature request is it makes your clients able to offload downloading the largest file from your application from the cdn if they need a latest fix only available from the trunk. I may actually be inclined enough to code this myself since my site has limited bandwidth and resources at launch.




3. GZip
Thank you for the report. Seems the main ExtJS script comes not gzipped from CDN. All the rest resources seems to be gzipped. We are investigating.

To me this is kind of a big deal because extjs-all is huge. It makes no sense to use the CDN if theoretically you can bounce a smaller file to your client's browser as fast at the same speed as the CDN can at full-size. ;)


4. UX not minified
Created an Issue:
https://github.com/extnet/Ext.NET/issues/279

Cool

5. CDNPath
A nice suggestion. Added to SVN trunk. Thank you again.

If you consider my feature request in 2, this would still work..

Daniil
Jun 21, 2013, 3:42 PM
Presently I have to do the following:


rm.RenderScripts = Request.IsSecureConnection ? ResourceLocationType.File : ResourceLocationType.CDN;
rm.RenderStyles = Request.IsSecureConnection ? ResourceLocationType.File : ResourceLocationType.CDN;


It just makes sense to me that this logic should be moved inside of the ResourceManager rendering. A check for IsSecureConnection, and if so, override back to default. Anyway, it's just a thought since this can cause an issue for clients who have secure pages since your cdn doesn't support secure. It's actually kind of frustrating this is the case because https already causes otherwise cached pages to be slow because the different port causes a full load (thus slowing this page more than the rest of the website).


We are going to switch to Embedded resources if "CDN && IsSecureConnection" as the most common option. Do you mind?




If we keep this feature request very basic, this comes down to breaking out /extjs which includes 2 files [js & css] from /extnet/ which includes 2-3 files depending on resource manager config. The extjs js file is the largest component of the entire application.

We understand that extjs resources version separately from extnet, and extnet is always based on a specific version of extjs. So nothing about your statement changes. You're still tightly bound to an extjs version because the trunk code is bound to a specific version of extjs on the cdn until you decide to upload something new on the cdn or reversion the trunk.

The most important aspect about this cdn feature request is it makes your clients able to offload downloading the largest file from your application from the cdn if they need a latest fix only available from the trunk. I may actually be inclined enough to code this myself since my site has limited bandwidth and resources at launch.


Well, we are uploading the resources to CDN on releases only. Sorry, probably, I misunderstand something, but do you still want to load Ext.NET resources from the SVN trunk (sure, beforehand downloaded from there) and load ExtJS resources from CDN?



To me this is kind of a big deal because extjs-all is huge. It makes no sense to use the CDN if theoretically you can bounce a smaller file to your client's browser as fast at the same speed as the CDN can at full-size. ;)


Sure, fair enough. It should be fixed.

michaeld
Jun 21, 2013, 8:30 PM
We are going to switch to Embedded resources if "CDN && IsSecureConnection" as the most common option. Do you mind?

Hmmm. Embedded would not be the ideal but you mean only embedded for the resources? and the javascript would be file?



Well, we are uploading the resources to CDN on releases only. Sorry, probably, I misunderstand something, but do you still want to load Ext.NET resources from the SVN trunk (sure, beforehand downloaded from there) and load ExtJS resources from CDN?

Yes.

I understand that CDN resources are release ONLY. The trunk drifts from release only for extnet js and resources. Typically the trunk stays on the same extjs version.

However, I did check and notice that sometimes the trunk advances to the next extjs release version (which would not correspond to a release version posted to your cdn). In this case, we'd be out of luck. So maybe that's where we are disconnecting and why you don't see the value. Like for instance, I think the trunk is using extjs 4.2.1 now and /extjs/extjs-all-js on cdn is 4.2.

So yeah, your point is there's no advantage here.

So maybe the simplest solution I can suggest is create another property for the ResourceManager.UseSenchaCDN = true that loads extjs appropriate cdn as listed from here http://senchaexamples.com/sencha-cdn/ instead of from your cdn. The correct path would have to be hardcoded each time you guys advance versions in the trunk.

Then we're back to my perfect world where extnet customers can publish trunk extnet code to our production environments and still benefit from at least partial cdn. More importantly, sencha does cdn https so you could hard code to handle this case too. ;) I realize this is a lot of permutations but still a best of all worlds type of request.

Thanks for discussing.

michaeld
Jun 23, 2013, 4:35 AM
Ran some numbers...

Filesize: 1.4mb
http://cdn.sencha.io/ext/gpl/4.2.1/ext-all.js ~750ms
https://extjs.cachefly.net/ext/gpl/4.2.1/ext-all.js ~650ms
http://speed.ext.net/ext.net/2.2.0/extjs/ext-all.js ~1.5-3.5 seconds
http://www.myserver.com/ (http://www.scenecalendar.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808)extjs/ext-all-js/ext.axd?v=39808 (http://www.scenecalendar.com/extjs/ext-all-js/ext.axd?v=39808) ~11-15seconds

Filesize: 284kb
http://cdn.sencha.com/ext/gpl/4.2.1/resources/ext-theme-gray/ext-theme-gray-all.css ~120ms
https://extjs.cachefly.net/ext/gpl/4.2.1/resources/ext-theme-gray/ext-theme-gray-all.css ~140-300ms
http://speed.ext.net/ext.net/2.2.0/extjs/resources/ext-theme-gray/ext-theme-gray-all.css (http://speed.ext.net/ext.net/2.2.0/extjs/resources/ext-theme-gray/ext-theme-gray-all.css) ~200ms
http://www.myserver.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808 (http://www.scenecalendar.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808) ~300ms-1.6sec

As you can see, cdn helps my website first-time load performance SIGNIFICANTLY if I can stream even this one major component. Bandwidth throttling has a massive consequence on my server's simultaneous load times. Cutting down the single file, ext-all.js, reduces my website load times from 15+seconds to <= 3 seconds. Of course, I can't cdn if I use anything from the trunk per current cdn strategy.

Part of the very high load of the ext-all.js from ext.net's cdn is from the lack of gzip streaming (as was previously noted as being currently addressed, as not yet). However the first time cache hit is pretty heavy still which means even after compression may still run the risk of > 1s load times first time. Not really a major deal but still noting for the basis argument.

I'm sure different users will have different experiences depending on their location and the effect of time and load on cached servers. Also speed.ext.net and https cachefly servers seem to have a first time lag whereas the cdn.sencha.com servers do not. I'm guessing this is probably related to frequency of use. Sencha resources are probably in higher demand which makes them cache more.

Anyway, another argument to justify loading from the sencha cdn is greater parallelization. Most browsers are limited to how many resources can be simultaneously loaded from the same domain. Separation would increase browser parallelization opportunities. That is, browsers more often may be able to load the larger extjs and extnet resources at the same time this way. Older browsers limit at 2 at a time and extnet resources will load at minimum 4 resources, 5 if linking, upwards from there if ux controls or images are loaded. So you can see where I'm going with the importance of this.

Daniil
Jun 24, 2013, 6:49 AM
Hmmm. Embedded would not be the ideal but you mean only embedded for the resources? and the javascript would be file?


Why should we make File for JavaScript resources? We would like to cover the most common case. I.e. a developer uses RenderScripts="CDN" and/or RenderStyles="CDN". Currently, it is OK with insecure pages, but it stops working with secure pages. Well, as you stated. A common developer would like it continues working without any additional efforts from his side. So, switching to Embedded looks the best option for that. Supposably, we are switching to File and a page breaks anyway, because a common developer would not attach resources as files.



However, I did check and notice that sometimes the trunk advances to the next extjs release version (which would not correspond to a release version posted to your cdn). In this case, we'd be out of luck. So maybe that's where we are disconnecting and why you don't see the value. Like for instance, I think the trunk is using extjs 4.2.1 now and /extjs/extjs-all-js on cdn is 4.2.

So yeah, your point is there's no advantage here.


Yes, that is exactly my point.



So maybe the simplest solution I can suggest is create another property for the ResourceManager.UseSenchaCDN = true that loads extjs appropriate cdn as listed from here http://senchaexamples.com/sencha-cdn/ instead of from your cdn. The correct path would have to be hardcoded each time you guys advance versions in the trunk.


I am afraid that Sencha uploads to CDN only released versions as well.


Ran some numbers...

Filesize: 1.4mb
http://cdn.sencha.io/ext/gpl/4.2.1/ext-all.js ~750ms
https://extjs.cachefly.net/ext/gpl/4.2.1/ext-all.js ~650ms
http://speed.ext.net/ext.net/2.2.0/extjs/ext-all.js ~1.5-3.5 seconds
http://www.myserver.com/ (http://www.scenecalendar.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808)extjs/ext-all-js/ext.axd?v=39808 (http://www.scenecalendar.com/extjs/ext-all-js/ext.axd?v=39808) ~11-15seconds

Filesize: 284kb
http://cdn.sencha.com/ext/gpl/4.2.1/resources/ext-theme-gray/ext-theme-gray-all.css ~120ms
https://extjs.cachefly.net/ext/gpl/4.2.1/resources/ext-theme-gray/ext-theme-gray-all.css ~140-300ms
http://speed.ext.net/ext.net/2.2.0/extjs/resources/ext-theme-gray/ext-theme-gray-all.css (http://speed.ext.net/ext.net/2.2.0/extjs/resources/ext-theme-gray/ext-theme-gray-all.css) ~200ms
http://www.myserver.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808 (http://www.scenecalendar.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808) ~300ms-1.6sec

As you can see, cdn helps my website first-time load performance SIGNIFICANTLY if I can stream even this one major component. Bandwidth throttling has a massive consequence on my server's simultaneous load times. Cutting down the single file, ext-all.js, reduces my website load times from 15+seconds to <= 3 seconds. Of course, I can't cdn if I use anything from the trunk per current cdn strategy.

Part of the very high load of the ext-all.js from ext.net's cdn is from the lack of gzip streaming (as was previously noted as being currently addressed, as not yet). However the first time cache hit is pretty heavy still which means even after compression may still run the risk of > 1s load times first time. Not really a major deal but still noting for the basis argument.

I'm sure different users will have different experiences depending on their location and the effect of time and load on cached servers. Also speed.ext.net and https cachefly servers seem to have a first time lag whereas the cdn.sencha.com servers do not. I'm guessing this is probably related to frequency of use. Sencha resources are probably in higher demand which makes them cache more.

Anyway, another argument to justify loading from the sencha cdn is greater parallelization. Most browsers are limited to how many resources can be simultaneously loaded from the same domain. Separation would increase browser parallelization opportunities. That is, browsers more often may be able to load the larger extjs and extnet resources at the same time this way. Older browsers limit at 2 at a time and extnet resources will load at minimum 4 resources, 5 if linking, upwards from there if ux controls or images are loaded. So you can see where I'm going with the importance of this.

Thank you for this investigation!

Yes, when we fix the Gzip issue, the situation with loading ext-all.js from our CDN should be improved.

Re: parallelization

Interesting. Well, I am not sure about using Sencha CDN. I have to redirect this question to our manager.

michaeld
Jun 25, 2013, 2:30 AM
I am afraid that Sencha uploads to CDN only released versions as well.

Is the trunk ever drawing from a non-release extjs version? If you noticed, I found 4.2.1 on their cdn and they only have published information up to 4.2.0. Ext.net trunk is using 4.2.1 as far as I can tell.



Filesize: 1.4mb
http://cdn.sencha.com/ext/gpl/4.2.1/ext-all.js (http://cdn.sencha.io/ext/gpl/4.2.1/ext-all.js) ~750ms
https://extjs.cachefly.net/ext/gpl/4.2.1/ext-all.js ~650ms
http://speed.ext.net/ext.net/2.2.0/extjs/ext-all.js ~1.5-3.5 seconds
http://www.myserver.com/ (http://www.scenecalendar.com/extjs/resources/ext_theme_gray/ext-theme-gray-all-embedded-css/ext.axd?v=39808)extjs/ext-all-js/ext.axd?v=39808 (http://www.scenecalendar.com/extjs/ext-all-js/ext.axd?v=39808) ~11-15seconds
...
Cutting down the single file, ext-all.js, reduces my website load times from 15+seconds to <= 3 seconds


Anyway, this isn't optional for me anymore until I can get to a higher bandwith provider. As you can see first time loads for my new users is absolutely unacceptable. They hit heavy load times twice as a first time user - first when they hit the website and second when they hit a secure page to create a new user account. Not great for a first impression. I'll be branching some kind of solution when I launch later this month. I need to at least load the ext-all.js from a cdn if one is vailid and available (as happens to be case at this juncture now).

Daniil
Jun 25, 2013, 5:15 AM
I am afraid that Sencha uploads to CDN only released versions as well.


Is the trunk ever drawing from a non-release extjs version? If you noticed, I found 4.2.1 on their cdn and they only have published information up to 4.2.0. Ext.net trunk is using 4.2.1 as far as I can tell.


Yes, you are right, we have never used a non-release ExtJS version. I am not sure why I worried about the fact that Sencha uploads to CDN only release versions:) Generally, it is what we need. Currently, we still hope to fix the GZip issue with our CDN.

As for separating resources (ExtJS from CDN; Ext.NET from the trunk, i.e. Embedded or File), I am still reluctant to do it. Well, I have to think more about it. Anyway, you could implement such the behavior manually. Setting up RenderScripts="None" and RenderStyles="None" and attach all the resources manually. It should not be a problem.

michaeld
Jun 25, 2013, 6:42 AM
You know? I'm realizing my Item #1 code was wrong. You were right all along. Embedded is what I meant for default all along.



rm.RenderScripts = Request.IsSecureConnection ? ResourceLocationType.Embedded : ResourceLocationType.CDN;
rm.RenderStyles = Request.IsSecureConnection ? ResourceLocationType.Embedded : ResourceLocationType.CDN;

You're still going to internalize this code, right?



As for separating resources (ExtJS from CDN; Ext.NET from the trunk, i.e. Embedded or File), I am still reluctant to do it. Well, I have to think more about it. Anyway, you could implement such the behavior manually. Setting up RenderScripts="None" and RenderStyles="None" and attach all the resources manually. It should not be a problem.

Somehow I think I'd lose a lot of rendering functionality by manually including the extnet resources, or would I? Do I need to worry about the number v=####? or is there a way I can constract that reference number by calling a utility function? I'll have to create the permutations for all the Dev/Debug/Release etc. Will it still correctly include additional ux resources or would I have to do that as well?

Again, if I could set just extjs resources to none, I could call it a day. I've begun to code ForceExtjsCDN=true branch in my code that I'll maintain.

Daniil
Jun 25, 2013, 7:38 AM
You know? I'm realizing my Item #1 code was wrong. You were right all along. Embedded is what I meant for default all along.



rm.RenderScripts = Request.IsSecureConnection ? ResourceLocationType.Embedded : ResourceLocationType.CDN;
rm.RenderStyles = Request.IsSecureConnection ? ResourceLocationType.Embedded : ResourceLocationType.CDN;

You're still going to internalize this code, right?


Yes, we are still going to implement it. Just it was put off for clarifying the best option. So, finally, since you agree with the Embedded option, we will add it shortly.



Somehow I think I'd lose a lot of rendering functionality by manually including the extnet resources, or would I? Do I need to worry about the number v=####? or is there a way I can constract that reference number by calling a utility function? I'll have to create the permutations for all the Dev/Debug/Release etc. Will it still correctly include additional ux resources or would I have to do that as well?

Again, if I could set just extjs resources to none, I could call it a day. I've begun to code ForceExtjsCDN=true branch in my code that I'll maintain.

Yes, it requires some efforts. Well, we are still considering how it is worth and possible to implement such an option. I will notify you about any solution.

michaeld
Jun 25, 2013, 11:14 AM
Index: C:/Users/Michael/Documents/Visual Studio 2012/Projects/Ext.Net/Ext.Net/MyExtensions.cs
================================================== =================
--- C:/Users/Michael/Documents/Visual Studio 2012/Projects/Ext.Net/Ext.Net/MyExtensions.cs (revision 0)
+++ C:/Users/Michael/Documents/Visual Studio 2012/Projects/Ext.Net/Ext.Net/MyExtensions.cs (working copy)
@@ -0,0 +1,73 @@
+using System;
+using System.Collections.Generic;
+using System.ComponentModel;
+using System.Configuration;
+using System.Linq;
+using System.Text;
+using System.Web;
+
+namespace Ext.Net {
+
+ public partial class GlobalConfig : ConfigurationSection {
+
+ /// <summary>
+ ///
+ /// </summary>
+ [ConfigurationProperty( "forceExtjsCDN", DefaultValue = false, IsRequired = false )]
+ [Description( "" )]
+ public bool ForceExtjsCDN {
+ get {
+ return (bool)this["forceExtjsCDN"];
+ }
+ }
+
+ }
+
+
+ public partial class ResourceManager {
+
+ public const string ExtjsCDN = "http://cdn.sencha.com/ext/gpl/4.2.1";// Current bound extjs version to Ext.net 2.2.0
+ public const string SecExtjsCDN = "https://extjs.cachefly.net/ext/gpl/4.2.1";// Extjs secure server
+
+
+ private bool? forceExtjsCDN;
+
+ /// <summary>
+ /// Determines if you want to force CDN loading from Extjs CDN. Can be set at Page level in ResourceManager, Session[\"Ext.Net.ForceExtjsCDN\"], Application[\"Ext.Net.ForceExtjsCDN\"] and web.config.
+ /// </summary>
+ [Category( "Config Options" )]
+ [DefaultValue( true )]
+ [Description( "Determines if you want to force CDN loading from Extjs CDN. Can be set at Page level in ResourceManager, Session[\"Ext.Net.ForceExtjsCDN\"], Application[\"Ext.Net.ForceExtjsCDN\"] and web.config." )]
+ public virtual bool ForceExtjsCDN {
+ get {
+ if( this.forceExtjsCDN != null ) {
+ return (bool)this.forceExtjsCDN;
+ }
+
+ if( this.DesignMode ) {
+ return false;
+ }
+
+ if( HttpContext.Current != null ) {
+ string token = "Ext.Net.ForceExtjsCDN";
+
+ object obj = HttpContext.Current.Application[token];
+
+ if( obj == null ) {
+ obj = Session( token );
+ }
+
+ if( obj != null && obj is bool ) {
+ return (bool)obj;
+ }
+ }
+
+ return GlobalConfig.Settings.ForceExtjsCDN;
+ }
+ set {
+ this.forceExtjsCDN = value;
+ }
+ }
+
+ }
+}


Index: C:/Users/Michael/Documents/Visual Studio 2012/Projects/Ext.Net/Ext.Net/Core/ResourceManager/ResourceManager.cs
================================================== =================
--- C:/Users/Michael/Documents/Visual Studio 2012/Projects/Ext.Net/Ext.Net/Core/ResourceManager/ResourceManager.cs (revision 5218)
+++ C:/Users/Michael/Documents/Visual Studio 2012/Projects/Ext.Net/Ext.Net/Core/ResourceManager/ResourceManager.cs (working copy)
@@ -1075,10 +1075,15 @@
break;
}

- items.Add(".extjs.ext-all" + (this.RTL ? ("-rtl" + ext) : ext));
+ string extjsall = ".extjs.ext-all" + (this.RTL ? ("-rtl" + ext) : ext);
+ if(!this.ForceExtjsCDN)
+ items.Add(extjsall);
+ else
+ source.Append( string.Format( ResourceManager.ScriptIncludeTemplate, this.ConvertToCDN( ResourceManager.ASSEMBLYSLUG + extjsall, true ) ) );
+
if (this.Theme == Ext.Net.Theme.Neptune)
{
items.Add(".extjs.ext-theme-neptune.js");
}
items.Add(".extnet.extnet-all" + (this.ScriptMode == Ext.Net.ScriptMode.Development ? "-debug.js" : ext));
}
@@ -2031,13 +2036,25 @@
return url;
}
#if ISPRO
private string ConvertToCDN( string resourceName )
+ {
+ return ConvertToCDN( resourceName, false );
+ }
+ private string ConvertToCDN(string resourceName, bool forceExtjsCDN)
{
string url = resourceName;

if (resourceName.StartsWith(ResourceManager.ASSEMBLYS LUG))
{
- url = this.ResolveUrlLink(ResourceManager.CDNPath + "/" + resourceName.Replace(ResourceManager.ASSEMBLYSLUG + ".", "").Replace("-embedded", "").Replace(".", "/").ReplaceLastInstanceOf("/", "."));
+ resourceName = resourceName.Substring( ResourceManager.ASSEMBLYSLUG.Length + 1 );
+ string cdnPath;
+ if( forceExtjsCDN && resourceName.StartsWith( "extjs." ) )
+ {
+ cdnPath = HttpContext.Current.Request.IsSecureConnection ? ResourceManager.SecExtjsCDN : ResourceManager.ExtjsCDN;
+ resourceName = resourceName.Substring( 6 );
+ } else
+ cdnPath = ResourceManager.CDNPath;
+ url = this.ResolveUrlLink( cdnPath + "/" + resourceName.Replace( "-embedded", "" ).Replace( ".", "/" ).ReplaceLastInstanceOf( "/", "." ) );
}

return url;
}




If ForceExtjsCDN=true it will force cdn to sencha's cdn regardless of other cdn on or off settings.
This only does it for the largest ext-all.js file. I may try the css later.
As expected, first time-loads are now finally bareable when deploying trunk code.

Daniil
Jun 25, 2013, 3:57 PM
Thank you for sharing! I will review it closely later.

michaeld
Jul 04, 2013, 5:09 AM
Checking in on this item. I didn't see any new items on the github.

Daniil
Jul 04, 2013, 5:12 AM
Yes, no changes yet, but we are getting closer to a solution.

michaeld
Oct 11, 2013, 12:24 AM
The latest ResourceManager.cs changes broke my ForceExtJsCDN features so I have to rewrite them.

I have a feeling I should be using ResourceStrategy and overriding my own implementation. Can you give me insights on how?

michaeld
Oct 11, 2013, 1:31 AM
Nevermind. I figured it out. It's a nice strategy.


However, I have some comments on your implementation....

The descriptor.Resource is pretty obfuscated by the time it reaches GetUrl which means that the programmer needs to deconstruct it after you already constructed it (expensive).

The ideal would be that instead of obfuscating the resource name, instead have the parts as members of ResourceDescriptor so the user can construct it their-self.


Also, I wasn't able to set ResourcesStrategyType="MyNamespace.RMStrategy" inside the ResourceManager of the as?x resource. I had to instead do it in the codebehind as
ResourceManager1.ResourcesStrategyType = typeof( MyNamespace.ExtjsCDNAlwaysStrategy );

michaeld
Oct 11, 2013, 2:05 AM
Final solution... This will allow programmers to use ExtJS CDN regardless of CDN settings for extnet.


namespace MyNamespace {
public class ExtjsCDNAlwaysStrategy : ResourcesStrategy {
public const string ExtjsCDN = "//extjs.cachefly.net/ext/gpl/4.2.1/";// Extjs nonsecure & secure server


public override string GetUrl( ResourceDescriptor descriptor ) {
if( descriptor.Type == ResourceType.ExtJS && descriptor.Resource.StartsWith(ResourceManager.ASS EMBLYSLUG)) {
return descriptor.Manager.ResolveUrl( ExtjsCDN + descriptor.Resource.Substring( ResourceManager.ASSEMBLYSLUG.Length + 7 ).Replace( "-embedded", "" ).Replace( ".", "/" ).Replace( '_', '-' ).ReplaceLast( "/", "." ) );
}
return null;
}
}
}



I'd still prefer a breakout of more of the parts in ResourceDescriptor to have more control.
Thank you. This version allows me to grab css and other resources from extjs whereas my old version only allowed js.

You're welcome to add this ResourceStrategy to your library if you'd like to give this and other controls to customers. Of course you'll have to maintain the extjs version in the path.

Daniil
Oct 15, 2013, 2:23 PM
The descriptor.Resource is pretty obfuscated by the time it reaches GetUrl which means that the programmer needs to deconstruct it after you already constructed it (expensive).

The ideal would be that instead of obfuscating the resource name, instead have the parts as members of ResourceDescriptor so the user can construct it their-self.


Yes, it would be nice to have more control here. Thank you for the suggestion. We will try to do something.



Also, I wasn't able to set ResourcesStrategyType="MyNamespace.RMStrategy" inside the ResourceManager of the as?x resource. I had to instead do it in the codebehind as
ResourceManager1.ResourcesStrategyType = typeof( MyNamespace.ExtjsCDNAlwaysStrategy );

We committed the fix. Now you can set up it via markup. However, please note that it expects the assembly-qualified name of the Type.

I.e., if the assembly is not signed, this should work.

ResourcesStrategyType="MyNamespace.RMStrategy, AssemblyName"

If signed, then:

"MyNamespace.ExtjsCDNAlwaysStrategy, AssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=..."

Please also note that you can set up it on the Web.config level:

<extnet resourcesStrategyType="MyNamespace.ExtjsCDNAlwaysStrategy, AssemblyName" />
or in the Application global object.



You're welcome to add this ResourceStrategy to your library if you'd like to give this and other controls to customers. Of course you'll have to maintain the extjs version in the path.

Thank you for the suggestion. At the moment we would prefer not to commit it leaving it under a developer's control.

michaeld
Oct 16, 2013, 1:15 AM
Thank you for the suggestion. At the moment we would prefer not to commit it leaving it under a developer's control.

Okay. Either way. They can find the option in this thread, as well, it's also an example of how to implement.

But you do realize by adding it to ext.net library, it would not mean it would take it out of the developer's control. It would just give them the opportunity to use what's already there. But I understand you might not wish to have to support it also.

Daniil
Oct 18, 2013, 4:58 AM
Yes, it makes sense. Maybe, we will add it one day. Again, thank you for the suggestion!

Do you mind we close the thread? Has everything been addressed here?

michaeld
Oct 22, 2013, 10:33 AM
Do you mind we close the thread? Has everything been addressed here?

Reviewing...


Hi @michaeld,

1. SSL CDN
Yes, currently, CDN doesn't support SSL to request the resources with "https".
So, you need to turn CDN off to avoid a security warning because of requesting the resources with insecure "http", is that correct?


What's the status on this? I still presently manually set resource to load embedded if secure.


2. Getting ExtJS resources from CDN, but not Ext.NET


Item addressed with ResourceStrategyType. Excellent job btw.


3. GZip
Thank you for the report. Seems the main ExtJS script comes not gzipped from CDN. All the rest resources seems to be gzipped. We are investigating.


Still outstanding. I don't know if you have any control over this ultimately, but it makes no sense for a cdn provider like speednet not to support gzip. That's like supporting the idea of performance but without providing maximum performance. If you review my comparison of the extjs timings, speednet is still still twice as long to load as extjs's cdn providers because of lack of gzip support. I can only assume the same translates for the extnet resources.


4. UX not minified
Yes, we have no minified versions for UXs. We have some thoughts and plans on this, but no concrete time frames at the moment. But anyway, it won't provide much benefit since the UX resources are very small.


Yes, you guys nailed this one.


5. CDNPath
Thank you for the suggestion. We will consider.

You indicated it was committed to SVN.

geoffrey.mcgill
Oct 22, 2013, 3:47 PM
Still outstanding. I don't know if you have any control over this ultimately, but it makes no sense for a cdn provider like speednet not to support gzip. That's like supporting the idea of performance but without providing maximum performance. If you review my comparison of the extjs timings, speednet is still still twice as long to load as extjs's cdn providers because of lack of gzip support. I can only assume the same translates for the extnet resources.

I'll be reviewing this functionality again. There was a maximum gzip size limit on objects at the CDN provider (I believe 1 meg). To work around this limit will take some investigation, although I do believe there is a solution.

Daniil
Oct 22, 2013, 5:23 PM
Thank you for the review.




Hi @michaeld,

1. SSL CDN
Yes, currently, CDN doesn't support SSL to request the resources with "https".
So, you need to turn CDN off to avoid a security warning because of requesting the resources with insecure "http", is that correct?


What's the status on this? I still presently manually set resource to load embedded if secure.

I am afraid it has been overlooked despite on the fact that it is in the thread's title:(

We will look into it again.

michaeld
Oct 23, 2013, 2:31 AM
Thanks both of you. This one is may seem subtle, but bandwidth is the only control we have given how heavy server and client side run-times are.

michaeld
Oct 24, 2013, 2:43 AM
Geoffrey, could you mind keeping me posted so I know when to take a look?

michaeld
Oct 24, 2013, 6:27 AM
Nevermind. I just noticed that these files are now coming across gzipped. Great job. Major time improvements as well.

extnet-all.js shrinks from 400.9k to 96.2k and receives in 500ms instead of 1.5seconds.

Daniil
Oct 29, 2013, 11:56 AM
Nevermind. I just noticed that these files are now coming across gzipped. Great job. Major time improvements as well.

extnet-all.js shrinks from 400.9k to 96.2k and receives in 500ms instead of 1.5seconds.

I am afraid it is still an issue. The non-gzipped extnet-all.js is ~400 kB. It passed the size limit. The ext-all-debug.js is 700 kB. So, it passed as well. But the ExtJS scripts exceed the size limit, so, they still come non-gzipped.

Since you are using the Sencha CDN, it is not an issue for you.

However, it would be nice to fix ever. So, created an Issue for that.
https://github.com/extnet/Ext.NET/issues/364

geoffrey.mcgill
Nov 06, 2013, 5:50 PM
I can confirm gzipping is not occurring properly on ext-all.js. It's larger than the CDN providers file size limit.

I am investigating switching our CDN hosting to a new provider.

michaeld
Nov 07, 2013, 1:33 AM
I can confirm gzipping is not occurring properly on ext-all.js. It's larger than the CDN providers file size limit.

I am investigating switching our CDN hosting to a new provider.

While you're at it, are you looking for one that supports ssl?

geoffrey.mcgill
Nov 07, 2013, 1:57 AM
While you're at it, are you looking for one that supports ssl?

Yes. The feature request is being tracked with the following ticket.

https://github.com/extnet/Ext.NET/issues/370

geoffrey.mcgill
Nov 23, 2013, 5:51 PM
We have moved to a new DNS and CDN provider. All .js resources are now being .gzipped.

As well, SSL support is available and we will be adding this as a config option in the upcoming Ext.NET Pro 2.4 release.

Hope this helps.

Thanks for prompting us to make these changes.

geoffrey.mcgill
Nov 23, 2013, 5:54 PM
Here's a .js file on non-SSL and SSL CDN:

http://speed.ext.net/ext.net/2.3.1/ux/portal/portal.js

https://speed.ext.net/ext.net/2.3.1/ux/portal/portal.js

michaeld
Nov 23, 2013, 10:20 PM
Thanks for prompting us to make these changes.


The thanks is to you.

Daniil
Nov 26, 2013, 3:10 PM
We just committed the change in the trunk. Now "https" should be used in CDN paths if a secure connection.

@michaeld, we would appreciate if you can try it on your side and confirm it is working for you flawlessly or not.

michaeld
Nov 26, 2013, 11:13 PM
Tested. It's good, but there's no reason to test issecure. Change the code to the following:


CDNPlusVer = string.Format("//speed.ext.net/ext.net/{0}.{1}.{2}", ver.ProductMajorPart, ver.ProductMinorPart, ver.ProductBuildPart);

Daniil
Nov 27, 2013, 3:57 AM
Thank you for the suggestion.

Though:
http://www.paulirish.com/2010/the-protocol-relative-url/


Caveat: When used on a <link> or @import for a stylesheet, IE7 and IE8 download the file twice (http://www.stevesouders.com/blog/2010/02/10/5a-missing-schema-double-download/).

So, it looks better to set up it explicitly. What do you think?

michaeld
Nov 27, 2013, 9:29 AM
So, it looks better to set up it explicitly. What do you think?

Okay. No problem. I wasn't aware of that issue.

Johannes
Nov 27, 2013, 7:17 PM
You forgot all the old files on your new CDN!!! eg.
http://speed.ext.net/ext.net/2.2.0/extjs/ext-all.js --> 404

geoffrey.mcgill
Nov 27, 2013, 7:28 PM
You forgot all the old files on your new CDN!!! eg.
http://speed.ext.net/ext.net/2.2.0/extjs/ext-all.js --> 404

Fixed. Might take a few minutes before they're online.

Daniil
Dec 06, 2013, 5:57 AM
The descriptor.Resource is pretty obfuscated by the time it reaches GetUrl which means that the programmer needs to deconstruct it after you already constructed it (expensive).

The ideal would be that instead of obfuscating the resource name, instead have the parts as members of ResourceDescriptor so the user can construct it their-self.


Yes, it would be nice to have more control here. Thank you for the suggestion. We will try to do something.


It was improved. More details you can find in the blog post dedicated to the v2.4 release (it should appear very soon).
http://www.ext.net/blog/