Re: cf-database vs cf-java-database
On Sat, Jul 14, 2012 at 3:07 AM, Nathan Strutz str...@gmail.com wrote: As with most things in ColdFusion, you get convenience over performance. puts on his Adobe hat... not that he ever takes if off Really? I mean - yes - ColdFusion does favor practicality over pretty much every thing else, but I'm not sure it's fair to imply that performance is always second fiddle. There have been huge performance gains in ColdFusion from v6 to v10. Out of box with minimal tuning, ColdFusion can have -very- good performance. Add some more indepth tuning and you can have an incredibly fast system. I know you weren't trying to say CF couldn't perform, but I kinda felt like I had to say something here. ;) -- === Raymond Camden, Adobe Developer Evangelist Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: cfjedimaster ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351903 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
Yeah I wrote that in and then kind of coincidentally debunked it. Still, it feels true too often. With database connectivity, it's really not true. With object heavy development, performance still isn't there. If so, where are the benchmarks against php, python, Ruby, C#, JSP/JSF etc.? Obviously some of these platforms are much better than others in hard performance and in developer performance. Ruby for example is one extreme. Writing web servers and programming HTML with C++ is the other. I don't want to call you out, but I do want to see the facts. And finally, I will tell you I don't do CF because it's the fastest boat on the ocean or because it can haul the biggest loads. I do it because it's the nicest cruising vessel around. She's plenty seaworthy, cap'n. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Mon, Jul 16, 2012 at 11:27 AM, Raymond Camden raymondcam...@gmail.comwrote: On Sat, Jul 14, 2012 at 3:07 AM, Nathan Strutz str...@gmail.com wrote: As with most things in ColdFusion, you get convenience over performance. puts on his Adobe hat... not that he ever takes if off Really? I mean - yes - ColdFusion does favor practicality over pretty much every thing else, but I'm not sure it's fair to imply that performance is always second fiddle. There have been huge performance gains in ColdFusion from v6 to v10. Out of box with minimal tuning, ColdFusion can have -very- good performance. Add some more indepth tuning and you can have an incredibly fast system. I know you weren't trying to say CF couldn't perform, but I kinda felt like I had to say something here. ;) -- === Raymond Camden, Adobe Developer Evangelist Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: cfjedimaster ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351904 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
On Mon, Jul 16, 2012 at 2:07 PM, Nathan Strutz str...@gmail.com wrote: Yeah I wrote that in and then kind of coincidentally debunked it. Still, it feels true too often. With database connectivity, it's really not true. With object heavy development, performance still isn't there. If so, where are the benchmarks against php, python, Ruby, C#, JSP/JSF etc.? Obviously some of these platforms are much better than others in hard performance and in developer performance. Ruby for example is one extreme. Writing web servers and programming HTML with C++ is the other. I know object creation was one of the things speeded up in CF8. Do I have hard #s for you? Nope. But I remember seeing CFC creation get incredibly faster. (It may have been 9.) Are you basically saying you want to see firm #s for CF versus other languages? How are you judging CF as being slower for 'object heavy' and what does that mean in your opinion? I don't want to call you out, but I do want to see the facts. Right, but what facts are you looking for explicitely? Like, CF can normally make N CFCs per second with M methods in them each. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351907 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
Right, but what facts are you looking for explicitely? Like, CF can normally make N CFCs per second with M methods in them each. Yes. Have that on my desk by morning. Thanks. Just kidding, man, I don't write your checks. Unfortunately performance and applications is incredibly subjective, depending on hardware, applications and external connections including File I/O, network traffic, database calls, extra libraries and so on. On top of that, for testing cross-platform performance comparisons, you have to test something small that all application can do, so this usually comes down to math problems, which has very little to do with web apps (and lowest level languages always win). You have to test a larger app (like a pet market), but if you're just going for speed then you do a lot of caching, you remove extra objects and flatten object hierarchies, etc., it's not a fair test. Do I wish we could just see a true performance comparison in a fair and impartial manner? Yeah, but I know it's a pipe dream. Previous versions of CF have had a performance brief written up, e.g. the CF9 one: http://www.adobe.com/products/coldfusion/pdfs/cf9_performancebrief_ue.pdf Do you know if we will get one for CF10? I'm really interested to see how Tomcat helps under pressure. I know performance briefs are typically one-sided (I've been watching the jQuery blog for a long time now - yeah, i said it). Even still, I like to see what's improved and what I can expect. -nathan ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351909 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
On Mon, Jul 16, 2012 at 5:33 PM, Nathan Strutz str...@gmail.com wrote: Previous versions of CF have had a performance brief written up, e.g. the CF9 one: http://www.adobe.com/products/coldfusion/pdfs/cf9_performancebrief_ue.pdf Do you know if we will get one for CF10? I'm really interested to see how Tomcat helps under pressure. I know performance briefs are typically one-sided (I've been watching the jQuery blog for a long time now - yeah, i said it). Even still, I like to see what's improved and what I can expect. I'll ping the Powers that Be. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351910 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
As with most things in ColdFusion, you get convenience over performance. If you use a raw database driver (and a front-end platform to handle it), you may have the option of streaming results directly out of the database and onto a web page. This is extremely performant and uses very little memory. This is not what ColdFusion does. CF pulls the results out of the database and drops them into a query object. This object looks more like a struct of arrays when you dig in (and it essentially is). Furthermore CF lets you manipulate the data, change the recordset, query off of it, merge it with another, and so on. It's crazy powerful, but not the fastest knife in the drawer. Adobe ColdFusion uses DataDirect (.com) JDBC drivers for most (if not all) of the databases. This makes it convenient for Adobe to farm out that hard work while providing a standard interface, but on the other hand, native JDBC drivers (i.e. drivers provided by Microsoft, Oracle and other database vendors) tend to be a bit quicker because they have a lot riding on their performance with Java applications. Those native drivers also usually contain more advanced, database-specific features. DataDirect, by their very nature, has to take a safer route. Then again, that's DataDirect's primary job, and you won't often find them more than a half-step behind and often two steps ahead, that's how they make money. Of course, you don't have to use the DataDirect drivers. ColdFusion will accept any valid JDBC driver (that's why the JDBC spec was invented). But then you still have the ColdFusion overhead. DataDirect + ColdFusion has the fantastic advantage of managing database connection pools, thread pools, network connections, network database resolution, security, and so on. If you think you can do a better job by writing native Java, then you work at the wrong company. In other words, this is way, way more work than anyone should ever sign up for, except those people at DataDirect (or Microsoft, or Oracle), or the Adobe CF team office. This is the kind of low-level programming that business application developers need to avoid in order to stay productive. Now, if you have some people who are handy with JDBC and can write great Java, it could make sense to put some of your objects into Java, but chances are, this is a bunch of baloney also. If your only work in Java is some SQL-containing database objects (first off I'd like to point out that that's not actually OO), then you are creating more overhead than you think. Instead of a CF JDBC-connector object, you'll be creating a custom JDBC connector object; personally I'd rather rely on Adobe to get this right, either way it's probably about the same amount of actual objects on the heap. Yes calling java from CF is lightning quick, and getting results back will be sliightly faster, let me point out a few things about your new development lifestyle: 1. You now have another language to maintain 2. That other language needs to be compiled every time you make a change 3. Unless you are on a very recent version of CF, CF may need a restart every time you change the Java code 4. Your SQL is in that other language, so now it is harder to get to 5. Your SQL has to fit into Java strings, so no more pretty line breaking and easy reading of SQL for the developers 6. There is nothing invented by all of mankind that is simpler than the cfquery tag 7. You now require CF and Java developers to do what used to take just a CF developer 8. You lose the ability to do query of queries and other CF manipulations So let's go back to the drawing board. First, are you sure you need to scale up? Could you scale out instead? Is it possible that a SQL database isn't even what you need? When you talk about scalability, maybe going to NoSQL databases would be a better fit. How about a cloud-hosted database where this conversation wouldn't even exist? Going back to the CF speed problem, I know a guy, maybe you know Mike Brunt too, he calls himself the cf whisperer, and it's true, he can listen to your app and tune your JVM so that it works faster than almost any pure Java app. If you're experiencing performance problems, almost every single time you'll find that you have a poorly tuned database, you're selecting too much data at a time, you're using inefficient joins, you don't use cfqueryparams, or something similar along these lines. There is a certain point, depending on hardware and the application, where you actually do have a scalability problem, but from my experience, some proper tuning and refactoring will get you way further than you think (until you have to spend $millions on real server hardware). ColdFusion server and its database connections are never the problem in my experience. Jumping to Java would be a bad call. nathan strutz [www.dopefly.com] [hi.im/nathanstrutz] [about.me/nathanstrutz] On Fri, Jul 13, 2012 at 9:57 PM, PT cft...@gmail.com wrote: Is there any advantage to having a CFC hand
Re: cf-database vs cf-java-database
What database are you using? If sql server then it has a native xml query engine which you can access via url and form posts through iis, so could cut cf or any middleware out of the loop. Regards Russ Michaels ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351890 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
MySQL, or one of the NoSQL variants, though I am still investigating. Twitter's DB solution offers a lot of promise, but it is only designed to handle = 30% of what I am looking for and is still beta. I have been ignoring SQL Server in favor of open source alternatives, but I will give it another look. Thanks! On 7/14/2012 4:48 AM, Russ Michaels wrote: What database are you using? If sql server then it has a native xml query engine which you can access via url and form posts through iis, so could cut cf or any middleware out of the loop. Regards Russ Michaels ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351891 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
This is very informative and answers most of my questions regarding CF's role. I will probably be sticking with CF and concentrating more on the DB side. I thank you immensely. On 7/14/2012 4:07 AM, Nathan Strutz wrote: As with most things in ColdFusion, you get convenience over performance. If you use a raw database driver (and a front-end platform to handle it), you may have the option of streaming results directly out of the database and onto a web page. This is extremely performant and uses very little memory. This is not what ColdFusion does. CF pulls the results out of the database and drops them into a query object. This object looks more like a struct of arrays when you dig in (and it essentially is). Furthermore CF lets you manipulate the data, change the recordset, query off of it, merge it with another, and so on. It's crazy powerful, but not the fastest knife in the drawer. Adobe ColdFusion uses DataDirect (.com) JDBC drivers for most (if not all) of the databases. This makes it convenient for Adobe to farm out that hard work while providing a standard interface, but on the other hand, native JDBC drivers (i.e. drivers provided by Microsoft, Oracle and other database vendors) tend to be a bit quicker because they have a lot riding on their performance with Java applications. Those native drivers also usually contain more advanced, database-specific features. DataDirect, by their very nature, has to take a safer route. Then again, that's DataDirect's primary job, and you won't often find them more than a half-step behind and often two steps ahead, that's how they make money. Of course, you don't have to use the DataDirect drivers. ColdFusion will accept any valid JDBC driver (that's why the JDBC spec was invented). But then you still have the ColdFusion overhead. DataDirect + ColdFusion has the fantastic advantage of managing database connection pools, thread pools, network connections, network database resolution, security, and so on. If you think you can do a better job by writing native Java, then you work at the wrong company. In other words, this is way, way more work than anyone should ever sign up for, except those people at DataDirect (or Microsoft, or Oracle), or the Adobe CF team office. This is the kind of low-level programming that business application developers need to avoid in order to stay productive. Now, if you have some people who are handy with JDBC and can write great Java, it could make sense to put some of your objects into Java, but chances are, this is a bunch of baloney also. If your only work in Java is some SQL-containing database objects (first off I'd like to point out that that's not actually OO), then you are creating more overhead than you think. Instead of a CF JDBC-connector object, you'll be creating a custom JDBC connector object; personally I'd rather rely on Adobe to get this right, either way it's probably about the same amount of actual objects on the heap. Yes calling java from CF is lightning quick, and getting results back will be sliightly faster, let me point out a few things about your new development lifestyle: 1. You now have another language to maintain 2. That other language needs to be compiled every time you make a change 3. Unless you are on a very recent version of CF, CF may need a restart every time you change the Java code 4. Your SQL is in that other language, so now it is harder to get to 5. Your SQL has to fit into Java strings, so no more pretty line breaking and easy reading of SQL for the developers 6. There is nothing invented by all of mankind that is simpler than the cfquery tag 7. You now require CF and Java developers to do what used to take just a CF developer 8. You lose the ability to do query of queries and other CF manipulations So let's go back to the drawing board. First, are you sure you need to scale up? Could you scale out instead? Is it possible that a SQL database isn't even what you need? When you talk about scalability, maybe going to NoSQL databases would be a better fit. How about a cloud-hosted database where this conversation wouldn't even exist? Going back to the CF speed problem, I know a guy, maybe you know Mike Brunt too, he calls himself the cf whisperer, and it's true, he can listen to your app and tune your JVM so that it works faster than almost any pure Java app. If you're experiencing performance problems, almost every single time you'll find that you have a poorly tuned database, you're selecting too much data at a time, you're using inefficient joins, you don't use cfqueryparams, or something similar along these lines. There is a certain point, depending on hardware and the application, where you actually do have a scalability problem, but from my experience, some proper tuning and refactoring will get you way further than you think (until you have to spend $millions on real server hardware). ColdFusion
Re: cf-database vs cf-java-database
you know there is a free version calledsql server express right ? On Sat, Jul 14, 2012 at 5:26 PM, PT cft...@gmail.com wrote: MySQL, or one of the NoSQL variants, though I am still investigating. Twitter's DB solution offers a lot of promise, but it is only designed to handle = 30% of what I am looking for and is still beta. I have been ignoring SQL Server in favor of open source alternatives, but I will give it another look. Thanks! On 7/14/2012 4:48 AM, Russ Michaels wrote: What database are you using? If sql server then it has a native xml query engine which you can access via url and form posts through iis, so could cut cf or any middleware out of the loop. Regards Russ Michaels ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351893 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: cf-database vs cf-java-database
Thanx for the great post Nathan . BTW this is a great line. I am sure I will quote it one day. There is nothing invented by all of mankind that is simpler than the cfquery tag G! On Sat, Jul 14, 2012 at 4:07 AM, Nathan Strutz str...@gmail.com wrote: As with most things in ColdFusion, you get convenience over performance. If you use a raw database driver (and a front-end platform to handle it), you may have the option of streaming results directly out of the database and onto a web page. This is extremely performant and uses very little memory. This is not what ColdFusion does. CF pulls the results out of the database and drops them into a query object. This object looks more like a struct of arrays when you dig in (and it essentially is). Furthermore CF lets you manipulate the data, change the recordset, query off of it, merge it with another, and so on. It's crazy powerful, but not the fastest knife in the drawer. Adobe ColdFusion uses DataDirect (.com) JDBC drivers for most (if not all) of the databases. This makes it convenient for Adobe to farm out that hard work while providing a standard interface, but on the other hand, native JDBC drivers (i.e. drivers provided by Microsoft, Oracle and other database vendors) tend to be a bit quicker because they have a lot riding on their performance with Java applications. Those native drivers also usually contain more advanced, database-specific features. DataDirect, by their very nature, has to take a safer route. Then again, that's DataDirect's primary job, and you won't often find them more than a half-step behind and often two steps ahead, that's how they make money. Of course, you don't have to use the DataDirect drivers. ColdFusion will accept any valid JDBC driver (that's why the JDBC spec was invented). But then you still have the ColdFusion overhead. DataDirect + ColdFusion has the fantastic advantage of managing database connection pools, thread pools, network connections, network database resolution, security, and so on. If you think you can do a better job by writing native Java, then you work at the wrong company. In other words, this is way, way more work than anyone should ever sign up for, except those people at DataDirect (or Microsoft, or Oracle), or the Adobe CF team office. This is the kind of low-level programming that business application developers need to avoid in order to stay productive. Now, if you have some people who are handy with JDBC and can write great Java, it could make sense to put some of your objects into Java, but chances are, this is a bunch of baloney also. If your only work in Java is some SQL-containing database objects (first off I'd like to point out that that's not actually OO), then you are creating more overhead than you think. Instead of a CF JDBC-connector object, you'll be creating a custom JDBC connector object; personally I'd rather rely on Adobe to get this right, either way it's probably about the same amount of actual objects on the heap. Yes calling java from CF is lightning quick, and getting results back will be sliightly faster, let me point out a few things about your new development lifestyle: 1. You now have another language to maintain 2. That other language needs to be compiled every time you make a change 3. Unless you are on a very recent version of CF, CF may need a restart every time you change the Java code 4. Your SQL is in that other language, so now it is harder to get to 5. Your SQL has to fit into Java strings, so no more pretty line breaking and easy reading of SQL for the developers 6. There is nothing invented by all of mankind that is simpler than the cfquery tag 7. You now require CF and Java developers to do what used to take just a CF developer 8. You lose the ability to do query of queries and other CF manipulations So let's go back to the drawing board. First, are you sure you need to scale up? Could you scale out instead? Is it possible that a SQL database isn't even what you need? When you talk about scalability, maybe going to NoSQL databases would be a better fit. How about a cloud-hosted database where this conversation wouldn't even exist? Going back to the CF speed problem, I know a guy, maybe you know Mike Brunt too, he calls himself the cf whisperer, and it's true, he can listen to your app and tune your JVM so that it works faster than almost any pure Java app. If you're experiencing performance problems, almost every single time you'll find that you have a poorly tuned database, you're selecting too much data at a time, you're using inefficient joins, you don't use cfqueryparams, or something similar along these lines. There is a certain point, depending on hardware and the application, where you actually do have a scalability problem, but from my experience, some proper tuning and refactoring will get you way further than you think (until you have to spend $millions on real
cf-database vs cf-java-database
Is there any advantage to having a CFC hand off database operations to java or some derivative over letting cfquery handle them itself? I have seen people use the CFC as a wrapper for using another language to handle the database access, but I have never seen a concrete explanation for doing this. I am looking for speed advantages, mainly. Is there any language that is faster at database interactions than CF on a large scale, or does it even matter? I am pretty sure no matter what I do, the database is going to be the choke point, but every little bit helps, especially when scaling up and things get wonky. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:351888 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
