[cfaussie] Reducing CF's Footprint.
Has anyone done any work on reducing the footprint of CF? Our Admin, Carl, has been doing some work on CF memory management. Mainly Garbage Collection. (He will be presenting his findings at our next CFUG if anyone is interested) He has started playing with reducing CF's base memory usage by removing unneeded jar files from CF/lib/ and seeing how that is impacting things on startup. So far things seem to be going well, and there have been some significant improvements. The question is: what can we safely remove? We know what we need for our application, but what does CF need to run at a minimum without compromising on stability? Thanks. Ricardo. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
RE: [cfaussie] Reducing CF's Footprint.
I don't know, this seems a curious way to seek to solve the problem. Instead, it would seem more appropriate to focus on lowering the footprint created by your app(s). In most instances, CF seems to start up with at most a couple-to-a-few-hundred meg. The rest (between that and the approximate max on 32 bit of about 1200mb) is all influenced by your code, your config, the traffic, etc. It seems that addressing that would be more fruitful (and less risky, since something may fail someday and now you won't know if it's because you removed some needed jar). And of course, if you are on CF9 (Standard or Enterprise) or CF8 Enterprise, you can go to 64 bit and remove that 1200meg max. Or if you're on CF Enterprise 6.1 or above, you can go to multiple instances, and may find that putting different apps/sites in different instances allows each to use a reasonable amount per instance (not nearing its limit, even on 32-bit.) I know it's not answering your question. I'm just offering it as a reminder of another way to attack your problem. /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Ricardo Russon Sent: Tuesday, October 12, 2010 8:42 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Reducing CF's Footprint. Has anyone done any work on reducing the footprint of CF? Our Admin, Carl, has been doing some work on CF memory management. Mainly Garbage Collection. (He will be presenting his findings at our next CFUG if anyone is interested) He has started playing with reducing CF's base memory usage by removing unneeded jar files from CF/lib/ and seeing how that is impacting things on startup. So far things seem to be going well, and there have been some significant improvements. The question is: what can we safely remove? We know what we need for our application, but what does CF need to run at a minimum without compromising on stability? Thanks. Ricardo. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Reducing CF's Footprint.
Thanks Charlie and Barry. I understand what you are both saying but at this point its just a case of the what ifs and why's. It just seems that CF does not deploy in an optimal state. Especially when it comes to the JVM's config in relation to memory management. So perhaps there are other ways to massage performance out of it. Creating a kind of CFLight. I really don't think I'm in a position to discuss the business case for it. But personally I like your idea Barry, of rolling out a turn-key solution. Ricardo. On Wed, Oct 13, 2010 at 12:00 PM, Barry Beattie barry.beat...@gmail.com wrote: He has started playing with reducing CF's base memory usage by removing unneeded jar files from CF/lib/ I hope you're all developing against a similarly crippled CF instance, lest you roll out a feature working in your dev/test environment but not on your customers installs. I thought you guys were having enough battles with supporting different versions, let alone different sub-versions? I'll be curious to hear Carl's presentation, not from a technical P.O.V, but from logistics and business case. There's a lot to be said for throwing more iron at a problem (ie: hardware can be cheap compared to concequences). While this example (below) is not the same thing, it shows how a little bit of hardware failure can snowball into multi-millon dollar losses. http://www.theaustralian.com.au/australian-it/still-no-clue-to-virgin-blues-20m-question/story-e6frgakx-1225937335722 Perhaps what is needed is to lease your customers your app(s), the OEM CF licence ... and the hardware needed to run it - a complete turn-key solution? meh, I'll shut up now. On Wed, Oct 13, 2010 at 11:46 AM, charlie arehart charlie_li...@carehart.org wrote: I don't know, this seems a curious way to seek to solve the problem. Instead, it would seem more appropriate to focus on lowering the footprint created by your app(s). In most instances, CF seems to start up with at most a couple-to-a-few-hundred meg. The rest (between that and the approximate max on 32 bit of about 1200mb) is all influenced by your code, your config, the traffic, etc. It seems that addressing that would be more fruitful (and less risky, since something may fail someday and now you won't know if it's because you removed some needed jar). And of course, if you are on CF9 (Standard or Enterprise) or CF8 Enterprise, you can go to 64 bit and remove that 1200meg max. Or if you're on CF Enterprise 6.1 or above, you can go to multiple instances, and may find that putting different apps/sites in different instances allows each to use a reasonable amount per instance (not nearing its limit, even on 32-bit.) I know it's not answering your question. I'm just offering it as a reminder of another way to attack your problem. /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Ricardo Russon Sent: Tuesday, October 12, 2010 8:42 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Reducing CF's Footprint. Has anyone done any work on reducing the footprint of CF? Our Admin, Carl, has been doing some work on CF memory management. Mainly Garbage Collection. (He will be presenting his findings at our next CFUG if anyone is interested) He has started playing with reducing CF's base memory usage by removing unneeded jar files from CF/lib/ and seeing how that is impacting things on startup. So far things seem to be going well, and there have been some significant improvements. The question is: what can we safely remove? We know what we need for our application, but what does CF need to run at a minimum without compromising on stability? Thanks. Ricardo. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group
Re: [cfaussie] Reducing CF's Footprint.
Hi Ricardo, I absolutely agree that CF's JVM configuration is not perfect for any given use case. It is an attempt to deliver something that works for most average CF sites and therefore you'd have to do load testing and JVM tuning to cater for more specific needs. And I don't think that's a point worth discussing really. What I find an interesting approach though is that you're trying to remove unneeded jar files etc to reduce the (I assume) memory footprint. I'd actually love to see the presentation, it's a shame that I'm over in Brisbane next week - maybe you can record or stream it via Connect? I think quite a lot of people would be interested in his findings. My personal opinion on this (without having tried or seen more on it) is that you're creating more issues along that path than you solve for the reasons that Charlie and Barry already elaborated on. But again - I might be wrong. Cheers Kai Thanks Charlie and Barry. I understand what you are both saying but at this point its just a case of the what ifs and why's. It just seems that CF does not deploy in an optimal state. Especially when it comes to the JVM's config in relation to memory management. So perhaps there are other ways to massage performance out of it. Creating a kind of CFLight. I really don't think I'm in a position to discuss the business case for it. But personally I like your idea Barry, of rolling out a turn-key solution. Ricardo. On Wed, Oct 13, 2010 at 12:00 PM, Barry Beattie barry.beat...@gmail.com wrote: He has started playing with reducing CF's base memory usage by removing unneeded jar files from CF/lib/ I hope you're all developing against a similarly crippled CF instance, lest you roll out a feature working in your dev/test environment but not on your customers installs. I thought you guys were having enough battles with supporting different versions, let alone different sub-versions? I'll be curious to hear Carl's presentation, not from a technical P.O.V, but from logistics and business case. There's a lot to be said for throwing more iron at a problem (ie: hardware can be cheap compared to concequences). While this example (below) is not the same thing, it shows how a little bit of hardware failure can snowball into multi-millon dollar losses. http://www.theaustralian.com.au/australian-it/still-no-clue-to-virgin-blues-20m-question/story-e6frgakx-1225937335722 Perhaps what is needed is to lease your customers your app(s), the OEM CF licence ... and the hardware needed to run it - a complete turn-key solution? meh, I'll shut up now. On Wed, Oct 13, 2010 at 11:46 AM, charlie arehart charlie_li...@carehart.org wrote: I don't know, this seems a curious way to seek to solve the problem. Instead, it would seem more appropriate to focus on lowering the footprint created by your app(s). In most instances, CF seems to start up with at most a couple-to-a-few-hundred meg. The rest (between that and the approximate max on 32 bit of about 1200mb) is all influenced by your code, your config, the traffic, etc. It seems that addressing that would be more fruitful (and less risky, since something may fail someday and now you won't know if it's because you removed some needed jar). And of course, if you are on CF9 (Standard or Enterprise) or CF8 Enterprise, you can go to 64 bit and remove that 1200meg max. Or if you're on CF Enterprise 6.1 or above, you can go to multiple instances, and may find that putting different apps/sites in different instances allows each to use a reasonable amount per instance (not nearing its limit, even on 32-bit.) I know it's not answering your question. I'm just offering it as a reminder of another way to attack your problem. /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:cfaus...@googlegroups.com] On Behalf Of Ricardo Russon Sent: Tuesday, October 12, 2010 8:42 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Reducing CF's Footprint. Has anyone done any work on reducing the footprint of CF? Our Admin, Carl, has been doing some work on CF memory management. Mainly Garbage Collection. (He will be presenting his findings at our next CFUG if anyone is interested) He has started playing with reducing CF's base memory usage by removing unneeded jar files from CF/lib/ and seeing how that is impacting things on startup. So far things seem to be going well, and there have been some significant improvements. The question is: what can we safely remove? We know what we need for our application, but what does CF need to run at a minimum without compromising on stability? Thanks. Ricardo. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr
Re: [cfaussie] Reducing CF's Footprint.
On Tue, Oct 12, 2010 at 5:42 PM, Ricardo Russon ricardo.rus...@gmail.com wrote: Has anyone done any work on reducing the footprint of CF? I could be flippant and say: use Railo - it has a much smaller memory footprint. Sorry, couldn't resist! :) Our Admin, Carl, has been doing some work on CF memory management. Mainly Garbage Collection. (He will be presenting his findings at our next CFUG if anyone is interested) I'd love to see this preso. JVM tuning is a real black art and there is always room for good presentations on this area of working with Java technology. When I was at Macromedia, we were constantly tweaking the JVM settings to improve the stability of macromedia.com. Every time we launched a new application, we had to go back through load testing and re-tuning the site because every change in the application composition could cause changes in the memory behavior of the site under load. He has started playing with reducing CF's base memory usage by removing unneeded jar files from CF/lib/ and seeing how that is impacting things on startup. So far things seem to be going well, and there have been some significant improvements. That really surprises me. Which version of Adobe ColdFusion are you working with? CF9 improved start up times dramatically (by deferring initialization of some subsystems until post-launch, I think - certainly the server is able to respond to requests much sooner after startup). The question is: what can we safely remove? Much is going to depend on what CFML features your application uses. It sounds a rather dangerous approach to me. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
Re: [cfaussie] Reducing CF's Footprint.
I'll speak to Carl about including his latest findings in his presentation next week. He originally was only going to present on GC, but I'll see if he has the time to add the latest results (removing the jar files) to his slides. I don't think this is something that anyone here is planing to do to a production server any time in the near future. But I haven't found any real reason not to proceed with researching this. The startup figures are really looking good from what he has done so far. Mainly memory size, but a slight improvement in load time. Thanks for all the feedback. I'll pass it on. Ricardo. -- You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
