Repost from my old CFZen blog: Aaron Longnion
http://refynr.com
This is a focus on architecture design mistakes I've seen made too often over the years by CF developers building ColdFusion architectures. Often times, the codebase and system started small and grew too fast, such that the original developer/architect didn't have the time or experience to scale the system up with the demands of high-load applications.
- Not dedicating enough time and resources on optimizing the database: Too often, there are smart, but unqualified programmers/developers designing and maintaining the database. A qualified/certified DBA, even part-time, is well worth the investment. You need one who can profile your database, tune all the server and individual database settings, recomming index changes, be responsible for DB design and integrity, regular maintenance, set up replication/failover/clustering, and will proactively monitor your database to let you know what problems need attention in relationship to your applications.
- Not dedicating enough time and resources on optimizing queries:Again, developers tend to throw themselves into the role of writing all the queries, but don't necessarily think about the performance/scalability issues of writing non-optimal queries. Often times a DBA who is qualified for all the Database Server stuff (see #1 above) isn't the same type of DBA who can optimize your queries. You need someone who can run the queries with explain plans, and then can make recommendations on improvements. These improvements pay off immensely!
- Coupling all parts of the system into one mega-application, instead of separate applicationsUsually they start out as fine: clever little applications that "do the job". They may have started in the CF 4 or 5 days, and grow and grow over the years until they're a mass of spaghetti code. It may never occur to the developers that as the app gets bigger that not everything belongs together any more. It will take some work, but it's important for long-term stability and scalability that you de-couple big chunks into smaller applications that run independent from the original beast. Scheduled Tasks, Web Services, APIs, User Admin Areas, Reporting, file/image services, Search services, etc. should no longer be coupled to the main application. Each of those parts should be broken out, so that each can be tuned optimally. Do you want your whole system to start bottlenecking because Search or Web Services become slow or go down? If they're decoupled, you don't have that problem.
- Not using a good "shared" file system scalable for high numbers of file writesWhen there are multiple physical servers in your cluster (if applicable), you may want a single location to save files. No-no's here are mapped drives/mounts to a non-dedicated server (such as a drive on your database server, some external drive, etc.). A good NAS and/or SAN solution with failover scales better as file writes become higher over time. Cloud Computing solutions are becoming big now, too, but I haven't tested enough in this area to make sound recommendations. I'm sure other with more experience can tell us. Comments?
- Not tuning the JVMMany articles have already been written on this subject, so I won't go into it. If you're having performance problems and you don't know how to tune your JVM, get help from one of the many articles out there, hire an expert, or get Adobe Platinum support for CF.
- Not tuning Request settings in the ColdFusion AdministratorSee #5 above.
- Not making good use of Multiple InstancesWhen you de-couple areas of your application (see #3), often it's wise to put your new applications into separate CF instances. For instance, all heavy tasks (Scheduled Tasks and other "batch" type processes) should run on a separate instance. You don't want to know how many times I've seen a Scheduled Task bring the entire infrastructure to it's knees.
- Not using CF Monitoring tools, such as SeeFusion, CF8 Server Monitor, and/or FusiontReactorGet familiar with at least 2 of these, and hire an expert to help you get up to speed on them more quickly. These save your butt!
- Trying to recreate the "holy grail" reporting system from scratchFirst, any reporting system should be a prime candidate for de-coupling. And reports that come from the database should not be running against your "write" (master) database, but rather against your "read-only" (slave) database, or else you'll have a lot of bottlenecks on your hands as users create massive reports reading data while other users are trying to simultaneously write data via the rest of the application. But secondly, look for reporting solutions that are already available. Most of the time users don't really need *real-time* reports, and off-line/archived data lends itself better to the more complex reports that users start to request over time (allowing Excel exports makes a lot of people happy, cuz they know how to generate reports "the way they like them" in familiar Excel. Also, don't write a Report UI that allows users to request *too many* records - your milage will vary, but it's almost never a good idea to allow reports that have no filters, such that they can just *get everything* all at once. Few web apps are built for handling that much data, so find other solutions.
- Not taking advantage of various caching capabilities:We all know (hopefully) to cache queries where possible, but... do you use the Application/Server scope where appropriate, and to use cfcache (or other 3rd party CF cache tags/CFCs/frameworks) in areas that rarely change? Do you come up with caching strategies for data, so that it can persist in the Application/Server scope without going back to the dB unnecessarily? Could other data/files be cached to disk? Can you use Verity (or Lucene/Solr) for searches instead of pulling directly from the database all the time?
http://refynr.com
