1. Doug - (High-Level View) Hardware scalability, major issues you'll encounter as you scale, suggestions of multiple tiers, proxy servers (static elements) - the theory why that's so valuable but not the details of you you would integrate them, some session "warnings" and a few other things. I also cover business and financial justifications for the various steps in the timeline of an organzation. What you need at each step, what to expect cost-wise, how to justify it, etc.

2. Matt - (enterprise strategy) - The high-level view sounds good, but as a CF developer, I'm used to writing one Request. How do I design an architecture with multiple layers and proxies? What are the methods to take what Doug mentioned and actually make a plan out of it?

I show a very basic application framework and enterprise communication module code. This would mean that I would be showing code the allows specific functionality to communicate, but not actually any functionality. The framework would just be a suggestion on how to organize code that integrates well with the architecture I propose. I talk about the performance and security benefits of proxies, but stay away from application level caching as this is coverd by Jeff.

3. Robi - (application strategy) - Ok, now I understand how to design an enterprise plan, but I'm just developing one application in the set and don't have anything to do with hardware. But I want to make sure I built my application with the enterprise strategies given by Doug and Matt. Show me some code. What does something like this look like? What are the inner-workings like? What really is EJB, COM, etc. from a code-level? Let me leave feeling I understand the plan from the highest level but also have something I can take away and start using in my designs tomorrow. How does an average CF developer learn more about these areas so they can become an enterprise-level developer.

I talk about application data caching (as opposed to application caching.. i.e. cf servers caching of p code).

Code bits and examples. I will also talk more about why its appropriate to move outside of CF and use other technologies in certain situations.

4. Jeff (caching stragegies) Doug's talk covers caching more in theory than practice. I talk about how valuable it is that once you get an answer, that you cache it so you won't have to do it again and use valuable resource. I also say that your network bandwidth is critical and very expensive and that images should be proxied outside of this network to save CF resources, IIS resources, network resources and all costs included. I also mention Akamai. But I usually don't have time to go deeper.

Jeff will talk in detail about query caching, proxy servers, page caching, etc. I'm sure people would like to learn more about exactly how this is done. Data layering cacheing.. i.e. client, session, application var stored queries or data, and datalayer cache in the db product.

What is caching? Caching at theDATA layer in the application server (CF server page caching) or on the DB base. Caching queries at the application level or the database level, using ODBC? Caching application level data (like p code using XCACHE) for super fast performance.

1. Mike Prince of CF Logviewer will be at CF_Scale to show how viewing the CF logs can help you with optimization and scaling problems. Get the CF_Scale discount price of $129.95 at https://www.logviewer.com/home/tera.cfm

2. A CF_Scale t-shirt is planned. The draft text is below. Email improvements to me ASAP.

[CFLOOP CONDITION="AM I STILL SOBER"]
   [CF_BEER 
   FLAVOR="ALE" 
   COLOR="LIGHT"
   HEAD="YES" 
   AUTOREFILL="ON"]
   [CFIF "ALL MEMBERS OF THE OPPOSITE 
   SEX LOOK GOOD TO YOU"]
      [CF_ABORT]
   [/CFIF]
[/CFLOOP]
[CF_NAP]

   
"What I have learned from CF_scale is that the number one tag you can change to improve most websites
performances dramatically is.... 

    CFQUERY 

Yes other tags may take 1 ms here or 0.5 there, but poor 
SQL queries can take 200-2000 ms EACH. Don't worry about 
things like "should I use CFMODULE vs CFINCLUDE" until 
every single query in your page is faster than 10 ms on SQL 
server or 100 ms for Access! 

If you turn on debugging you can get the exact time for 
each query. Queries can be speeded up by the use of indexes, 
stored procedures, temporary tables, the NOLOCK parameter and 
query caching."