Folks who are using Microsoft Access with CFMX may find that there are problems when trying to configure the datasource in the administrator, perhaps because the default settings aren't appropriate to the kind of security used with their database (whether that's no security, security by a single password, or by use of usernames/passwords--what Access calls user-level security, by use of an MDW file).
There is a MM knowledge base article (http://www.macromedia.com/v1/Handlers/index.cfm?ID=23381) that addresses how to properly configure a DSN in the CFMX Admin for either of these 3 forms of security.
Sunday, November 17, 2002
Problems on Linux? Check out new MM KB article
Are you having problems running CFMX on Linux? Interested in learning a little more about some undocumented performance tweak possibilities (that it seems may also have value outside of Linux), check out the new Macromedia KB article, "ColdFusion MX support on Linux", at http://www.macromedia.com/v1/Handlers/index.cfm?ID=23524.
The coverage of threads and thread configuration is not limited to Linux, including the explanations of activeHandlerThreads, minHandlerThreads, and maxHandlerThreads (of which only the first is reflected in the Admin as "Simultaneous Requests" (separate settings for each of the built-in and external web server support), and it seems the recommendations about setting them could apply to outside of Linux, though that's not stated and therefore can't be relied upon.
The coverage of threads and thread configuration is not limited to Linux, including the explanations of activeHandlerThreads, minHandlerThreads, and maxHandlerThreads (of which only the first is reflected in the Admin as "Simultaneous Requests" (separate settings for each of the built-in and external web server support), and it seems the recommendations about setting them could apply to outside of Linux, though that's not stated and therefore can't be relied upon.
Tuesday, November 12, 2002
Another issue that can challenge DWMX speed for CFers
Continuing the discussion of DWMX speedup opportunities from earlier today, I've learned something interesting. After looking at a sample from someone reporting sever delays, I observed something that definitely explain things for some people. She had reported that a very large file (approx 1000 lines) was taking a long time to load. But anyone opening such a file of HTML content would say it was no problem at all.
The thing is, this was a CF template and the code had several CFQUERY's in it, run conditionally so it's not about doing several at runtime, but still this causes issues for DWMX that one might not anticipate. It tries to load up the bindings tab with each CFQUERY to create what DWMX calls a recordset. It also loads up CFPARAM tags and FORM/CFFORM tags there as well, among other things.
So DWMX is clearly processing the page when it opens it, and with a dynamic page like CF it's going to be looking at the code to figure out things like this. (Indeed, she mentioned having inherited one code sample that had 36 queries in CFSWITCH/CFCASE statements!).
Many will want to point out that such code is itself a source of problems in its design (and she realizes that it's code that will benefit from redesign, especially in CFMX with components), but the bottom line is that there are code examples out there that will indeed suffer during opening in DWMX because of this issue. I didn't find any undue time spent while switching from one file to another, though.
I don't see any feature to get DWMX to no perform this preprocessing. If anyone knows of one, please do share. :-)
The thing is, this was a CF template and the code had several CFQUERY's in it, run conditionally so it's not about doing several at runtime, but still this causes issues for DWMX that one might not anticipate. It tries to load up the bindings tab with each CFQUERY to create what DWMX calls a recordset. It also loads up CFPARAM tags and FORM/CFFORM tags there as well, among other things.
So DWMX is clearly processing the page when it opens it, and with a dynamic page like CF it's going to be looking at the code to figure out things like this. (Indeed, she mentioned having inherited one code sample that had 36 queries in CFSWITCH/CFCASE statements!).
Many will want to point out that such code is itself a source of problems in its design (and she realizes that it's code that will benefit from redesign, especially in CFMX with components), but the bottom line is that there are code examples out there that will indeed suffer during opening in DWMX because of this issue. I didn't find any undue time spent while switching from one file to another, though.
I don't see any feature to get DWMX to no perform this preprocessing. If anyone knows of one, please do share. :-)
More Speedup Tips for DWMX
In my 10/16 entry, I pointed out one way to speed up DreamWeaver MX. I have a little more detail and a couple more ideas now.
I had mentioned how you could see Edit Site, then on the "Advanced" tab, in "Local Info" turn off "Refresh Local File List Automatically". I didn't point out that the same setting exists in the "Testing Server" field there as well. These will be a big help with respect to the speed of switching in and out of DWMX. This feature is intentional as it's trying to detect if while you were out of DWMX you were perhaps creating new files (such as when folks do indeed switch out to Studio/HomeSite). But if you don't make such file additions/deletions, or if mostly you're switching out to read email, etc, then this "auto refresh" is an expensive operation. Turn it off and much slowness will go away.
Similarly, the "Remote Info" section of the Advanced tab has a checkbox "automatically upload files to server on save", again to keep your remote machine in sync. Maybe you won't really want that feature enabled (and it will certainly slow down all saves). This feature is available in all the forms of remote access (ftp, local/network, RDS, SourceSafe and WebDAV).
Some have also suggested turning off Virus checking of the DWMX "Config" directory, though I've not experience that doing much good (but I may have gained so much with these other changes that it didn't add much).
I'd welcome anyone else's thoughts. This seems an important problem for so many that it would be useful to gather some ideas.
I had mentioned how you could see Edit Site, then on the "Advanced" tab, in "Local Info" turn off "Refresh Local File List Automatically". I didn't point out that the same setting exists in the "Testing Server" field there as well. These will be a big help with respect to the speed of switching in and out of DWMX. This feature is intentional as it's trying to detect if while you were out of DWMX you were perhaps creating new files (such as when folks do indeed switch out to Studio/HomeSite). But if you don't make such file additions/deletions, or if mostly you're switching out to read email, etc, then this "auto refresh" is an expensive operation. Turn it off and much slowness will go away.
Similarly, the "Remote Info" section of the Advanced tab has a checkbox "automatically upload files to server on save", again to keep your remote machine in sync. Maybe you won't really want that feature enabled (and it will certainly slow down all saves). This feature is available in all the forms of remote access (ftp, local/network, RDS, SourceSafe and WebDAV).
Some have also suggested turning off Virus checking of the DWMX "Config" directory, though I've not experience that doing much good (but I may have gained so much with these other changes that it didn't add much).
I'd welcome anyone else's thoughts. This seems an important problem for so many that it would be useful to gather some ideas.
Subscribe to:
Posts (Atom)
