Re: Webstar / WebCat - Persistent Setting

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 48839
interpreted = N
texte = Hello Kenneth and thanks for responding. I believe your response is getting CGI Persistent Connection and Connections Per Client, even though both are labeled under Persistent Connections mixed up.For starters, .css and .js files are not CGI files, and therefore are not affected by the CGI Persistent Connection option. It is, however, as you pointed out and like every other file served by the server (graphics, media, text, pdf, etc) ... Affected by the Connections Per Client settings, which I think you have zeroed in on.Having said that, using includes instead of directly serving .css and .js may be suitable if the .css and .js style / script text is short. If the style sheet or .js script is lengthy, then it may be more efficient to have it served by the server instead of WebCat includes. Why? The browser requesting the said files from the server, does it only once for the session / client and all other HTML files calling the same .css and .js files will not download it in subsequent web request, instead recalling it from client's cache. To WebCat include it, would be to increase the overall page file size for each and every HTML page requiring it, especially if the .css / .js script length is long. So, I guess there are trades as to when to use includes versus server handled .css and .js files.Another reason to have .css and .js as non-includes would be driven by the editing software one uses and the frequency of changes expected to the pages concerned via the editing software. Dreamweaver for example, allows one to work with .css files and .js files through its built-in library. Once you WebCat code include these files/content, you will not be able to work with the .css and .js files nor see the WYSIWYG presentation of content via the editor.Anyway ... Thanks for helping, just thought I throw in my views even though it is not related to my original question. So, anyone out there .... CGI Persistent Connection .... Not Persistent Connections Per Client ..... On or Off where WebCat is concerned for better performance?Cheers TDn=========From: Kenneth Grome ====== topic =======WebStar4.5, WebCat4.5 Plugin, OS9.2 ....Under the WebStar Admin entry, Connections tab, there is an option to turn on Use Persistent CGI Connection.Does WebCat / Server performance improve with this setting turned on or it makes no difference? According to WebStar docs, the plugin / cgi must have this capability before turning this feature on in WebStar.For the life of me, I cannot find it in WebCat docs if this feature should be enabled for WebStar servers. Anyone out there has any idea?I have tried it On as well as off but was not able to see any significant performance change (the box just serves HTML webcat files .... Graphics and other multimedia content are from a second dedicated server). It does makes a difference on the second dedicated graphics server, even though there is no cgi running other then the standard WebStar ones.====== response ========If you're only serving one html page at a time from your webdna server -- with all the images coming from a separate server -- there's no reason to have persistent connections turned on unless you're also serving .css or .js files from the same webdna server.But given the fact that you're using webdna, there's no reason to serve these files separately, since they can be served more efficiently by including them than by making the browser request them as separate files. So if you're serving these files separately, I would suggest that you [include] them instead from now on.Usually persistent connections is turned on when the images and html files come from the same server. When more than one file is served over the same connection to the same recipient, using persistent connections will reduce the overhead of building up and tearing down multiple connections, resulting in faster performance.But in your case you're not serving images from the save server, so I would suggest that you leave it off on the webdna server.The image server is a different story however, because in most cases your image server will be serving multiple images to the same recipient. In this case it definitely helps to have persistent connections turned on. -- Sincerely, Kenneth Grome ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: Webstar / WebCat - Persistent Setting (Terry Nair 2003)
  2. Re: Webstar / WebCat - Persistent Setting (Kenneth Grome 2003)
  3. Webstar / WebCat - Persistent Setting (Terry Nair 2003)
Hello Kenneth and thanks for responding. I believe your response is getting CGI Persistent Connection and Connections Per Client, even though both are labeled under Persistent Connections mixed up.For starters, .css and .js files are not CGI files, and therefore are not affected by the CGI Persistent Connection option. It is, however, as you pointed out and like every other file served by the server (graphics, media, text, pdf, etc) ... Affected by the Connections Per Client settings, which I think you have zeroed in on.Having said that, using includes instead of directly serving .css and .js may be suitable if the .css and .js style / script text is short. If the style sheet or .js script is lengthy, then it may be more efficient to have it served by the server instead of WebCat includes. Why? The browser requesting the said files from the server, does it only once for the session / client and all other HTML files calling the same .css and .js files will not download it in subsequent web request, instead recalling it from client's cache. To WebCat include it, would be to increase the overall page file size for each and every HTML page requiring it, especially if the .css / .js script length is long. So, I guess there are trades as to when to use includes versus server handled .css and .js files.Another reason to have .css and .js as non-includes would be driven by the editing software one uses and the frequency of changes expected to the pages concerned via the editing software. Dreamweaver for example, allows one to work with .css files and .js files through its built-in library. Once you WebCat code include these files/content, you will not be able to work with the .css and .js files nor see the WYSIWYG presentation of content via the editor.Anyway ... Thanks for helping, just thought I throw in my views even though it is not related to my original question. So, anyone out there .... CGI Persistent Connection .... Not Persistent Connections Per Client ..... On or Off where WebCat is concerned for better performance?Cheers TDn=========From: Kenneth Grome ====== topic =======WebStar4.5, WebCat4.5 Plugin, OS9.2 ....Under the WebStar Admin entry, Connections tab, there is an option to turn on Use Persistent CGI Connection.Does WebCat / Server performance improve with this setting turned on or it makes no difference? According to WebStar docs, the plugin / cgi must have this capability before turning this feature on in WebStar.For the life of me, I cannot find it in WebCat docs if this feature should be enabled for WebStar servers. Anyone out there has any idea?I have tried it On as well as off but was not able to see any significant performance change (the box just serves HTML webcat files .... Graphics and other multimedia content are from a second dedicated server). It does makes a difference on the second dedicated graphics server, even though there is no cgi running other then the standard WebStar ones.====== response ========If you're only serving one html page at a time from your webdna server -- with all the images coming from a separate server -- there's no reason to have persistent connections turned on unless you're also serving .css or .js files from the same webdna server.But given the fact that you're using webdna, there's no reason to serve these files separately, since they can be served more efficiently by including them than by making the browser request them as separate files. So if you're serving these files separately, I would suggest that you [include] them instead from now on.Usually persistent connections is turned on when the images and html files come from the same server. When more than one file is served over the same connection to the same recipient, using persistent connections will reduce the overhead of building up and tearing down multiple connections, resulting in faster performance.But in your case you're not serving images from the save server, so I would suggest that you leave it off on the webdna server.The image server is a different story however, because in most cases your image server will be serving multiple images to the same recipient. In this case it definitely helps to have persistent connections turned on. -- Sincerely, Kenneth Grome ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Terry Nair

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

What am I missing (1997) Shipping charges depending on tax rate? (1997) A dynamic database. (1997) [format xs] freeze (1997) taxTotal, too (1997) Summing a field full of numbers ... (1997) [ot] Still Interested In Acquiring Hosting Companies (2006) ver 4 random crashes (2003) Sorting Numbers (1997) [UPPERCASE] (1997) weird [hideif] happenings maybe . . . (2003) Traffic - FYI (2003) OT - help with filemaker - short (1999) Digest for 09-30-97 (1997) [WriteFile] problems (1997) BGcolor (1997) Remote Administration (1998) if else problem (2003) Script Rating on WebDNA Dev Net (2002) Was code to phantom spacing -- now BBEdit [!][/!] (2001)