Sep 23, 2013, 1:35 AM
[OPEN] [#356] Gzipped extnet static resources not persistanced
I guess this is more of a feature request, but it seems to me that the static ext.net resources call CompressionUtils.GZip on the static bytestream each time a resource is requested (when GZip="true"). It seems to me that it would be 20 times more efficient if the requested resources were already gzipped as a static file resource (part of build project) and transmitted directly instead of processed then transmitted. The second best option would allow the resources to persist to a writable physical location on the server the first time requested then transmitted. As extnet is already pretty heavy on the cpu given the number of transformations, this would significantly task the cpu less from a scalability standpoint.
I realize once-each client has cached the resource, it doesn't need to repeatedly process and transfer. I also verified that the processed output is server-side cached to prevent the zip being reprocessed again. However, as these fragments can be fairly large, I'm finding that my server is blowing away these cached resources frequently due to restricted access to memory. In other words, the server-side cache is more-often rendered null and void and has to reprocess again-and-again. Moreover, every worker thread keeps its own cached reference in memory. A different cache-provider might help but also add its own performance weight. This issue hasn't been one on my development environment, but I noticed the issue when I ran a trace on my production server. The short term answer would be make more memory available on my production environment, but the BEST solution of all worlds would be my original request for the resources to be static persisted files or resources like the other static ext.net content.
I realize once-each client has cached the resource, it doesn't need to repeatedly process and transfer. I also verified that the processed output is server-side cached to prevent the zip being reprocessed again. However, as these fragments can be fairly large, I'm finding that my server is blowing away these cached resources frequently due to restricted access to memory. In other words, the server-side cache is more-often rendered null and void and has to reprocess again-and-again. Moreover, every worker thread keeps its own cached reference in memory. A different cache-provider might help but also add its own performance weight. This issue hasn't been one on my development environment, but I noticed the issue when I ran a trace on my production server. The short term answer would be make more memory available on my production environment, but the BEST solution of all worlds would be my original request for the resources to be static persisted files or resources like the other static ext.net content.
Last edited by Daniil; Oct 15, 2013 at 11:55 AM.
Reason: [OPEN] [#356]