I work some reasonably large tables (couple million records) and moderate db sizes (currently about 5 GB I think). The app server really isn't the problem in those situations, it is the database itself and, more importantly, how the database is set up and tuned.
When dealing with a database, CF just issues a command (usually through an already open connection) and then waits for the results. To speed that process up, you have two options. 1) don't actually query the db (cacheing) and 2) make the db query itself faster (db tuning) Cacheing is a great idea if you know what data you are going to use, how and when. For db tuning you need to understand your queries so you can write indexes and then you need to start thinking about the data itself and how it is stored. For instance, how does the data get into your database? Does it come in via individual operations (people on a website submitting something)? Or does it come in as batches from other systems? If it comes in as batches, you'll want to use a database bulk import utilities instead of reading a file in with CF (or any higher level language) and then, once it is in the db, do additional processing you might need on the data before moving it to its final destination. If you find yourself needing to have very large tables, you might also want to look into partitioning. There are both horizontal and vertical partitioning schemes. Horizontal partitioning says "put these columns of the table over this device and these columns over on this device" which is very useful if you have wide tables that store a bunch of data but only some of the columns are frequently used. Vertical partitioning says "put rows 1 to 1,000,000 on this device and 1,000,001 to 2,000,000 on this device". This type of scheme is very useful if you have data that you can segment off by time as is often the case in business reporting. You might store Q1 data on device A, Q2 data on device B, etc. since you'll usually be limiting yourself to data all from one particular business quarter. Anyway, there is lots to say about database performance and tuning and how it effects your application responsiveness. As far as the actual language itself goes, I'd say stick with what you know. You'll write better code in a language you know than you will in a language you don't know well, even if that other language was deemed inherently "faster". Which, btw, Ruby is not. Ruby is a fully interpreted language, it never gets compiled down to cached byte code. And Ruby on Rails (up until the 1.9.x branch which is out but not stable) is not multi-threaded. Ruby and RoR can be quite fast and is easy to build apps with but does not currently scale out. That is changing, however, and is one of the reasons I'm finally learning RoR. Primary rules of application development: First, write a good spec that identifies what needs to be built. Second, write a good application that does what it needs to do in a maintainable, intelligent but not overly fancy way. Third, load test the shit out of it and see where the bottlenecks are. Decide if the performance as is is good enough. Identify features and bottlenecks that you are going to target for improvement. Work hand in hand with the client to incorporate feedback quickly and transparently and chances are good they will be very happy indeed. Judah ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Want to reach the ColdFusion community with something they want? Let them know on the House of Fusion mailing lists Archive: http://www.houseoffusion.com/groups/cf-community/message.cfm/messageid:312782 Subscription: http://www.houseoffusion.com/groups/cf-community/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.5
