You can read the show notes and listen to the podcast here.
Michaela: Welcome back to the show. I'm here with Mike Collins and we're going to be talking about scaling your ColdFusion Applications. And we'll look at some of the JBM things you can do that and some of the key performance metrics and session management strategies you might use. And we'll look at both using local servers and using clever things like Docker to do it more remotely. So, we'll also briefly look at load testing security and monitoring if you will scaling your application. So welcome Mike.
Mike: Welcome, thank you.
Michaela: And in case you don't know Mike, he's been with ColdFusion since it was born back in the earlier days. He used to work at [inaudible] [00:43] he's been at Macromedia and Adobe. And now he's got his own business school Support Objectives that provides annual ColdFusion support and consulting. So, he's a really smart guy I am so happy you got him here on the show today.
So yes. So, tell us you know why is scaling important in the ColdFusion world, because maybe people haven't really thought about this topic?
Mike: Right exactly, so this session tries to address kind of the bit starts off with addressing some of the big picture items as far as what you're really, almost from the install, making those first decisions from OS to the connector setup, to what features you want to actually install with ColdFusion and then walks that out into knowing your key performance metrics and then all the way through understanding session strategies.
A lot of questions you get hit with immediately as soon as you start looking and installing and how you want to implement ColdFusion, that's the quite view in this session.
Michaela: Yes, so you're going to be speaking at CF Summit East on this topic in Washington DC in a few months. But maybe, we should just back up a minute you know the details that.
Mike: yes
Michaela: You know, just to ask take a devil's advocate position here. Why can't you just stick more memory and more CPU and have one server?
Mike: Absolutely, so the idea here is you want to remove the single point of failure and that's the key aspect of the discussion. We're going to be looking at how we can set up an environment where we know if one server goes down whether [inaudible] [02:34] to you or you are just trying to do maintenance, you have a plan in place that you will be able to take a server out and no if the sessions are going to continue to perform. Not everybody needs seamless sessions but the folks that do they get the high load traffic. The e-commerce sites that needs to have that roll over. These are topics that are going to be important for that.
Michaela: Yes, because if you're running that kind of site, if the site goes down it's costing you money. So, that's you know a reason and it's costing your reputation as well online.
Mike: Right. I deal with customers that have that high sensitivity and it's you know, if something does go down it takes you know, you spend hours in figuring out exactly what that was and why it went down and it's not a small, you need to restart the server again.
Michaela: And you mentioned maintenance, so you know if you have a cluster of several servers you can take one down completely, do some patches, rip you know upgrade the hardware or whatever and it's not going to affect your website that you're running on that cluster?
Mike: That's correct, so yes. So, right out of the gig, you're going to have a plan for how you're going to manage your session and then even goes into your code because if you choose EHK# for your sessions, that would change how you store your session variables as opposed to if you use some of like the new features 2016 such as read RedX or you can actually release the sessions back. So, you know from right out of the gig these are important decisions and you know a lot of times if you have legacy code that already has all the session [inaudible] [04:23] scoping. It's going to make it a little bit more challenge to move to a new [inaudible] [04:30] not a impossible in the days of coaching.
Michaela: Right. And the issue there is that you've got variables that are valid for the whole user session and they're coming back multiple times and they might be going back to a different server in the cluster. And if you don't deal with it correctly that just not going to see those variables.
Mike: Right, exactly. And you know that's one thing. I mean sometimes people sessions aren't always the most critical thing for folks. They can, you know have their users re-log in you know on the occasional outage. And sometimes, you know that's probably a fifty fifty by arrangement. So that's not always critical but other things such as just knowing your key performance metrics you know and how much you can push a particular VM before or is better just to create another VM to handle more [inaudible] [05:23] in metrics like that.
Michaela: So when people are you know scaling what they are common issues you see?
Mike: I think the common problem is you know just how much JBM memory should be allocated. You know, I think a lot of times people are unsure as far as what the number should be. Whether you know or sometimes they may have too much memory as opposed to just finding that right number, you know whether it's a gig, two gigs. So some of the cabbage collection settings are also questions that people have that we can address. We are going to talk about that in the session as well. You know there’s a new thing with garbage collection that you can use or you could just use the default ColdFusion settings as well which 90% of folks use. We will address that in the session.
Michaela: Right and for people who haven't really dug into the JBM, you know the whole Java virtual machine running that and it kind of builds up the amount of memory it's using and then every now and again it does what's cool garbage collection and cleans up the unused memory and that's what you're talking about their?
Mike: Yes. Well there are some I mean as far as the early obstacles. Connector, how to set up your Connector, you know in some best practices with that. There's a something, an admin manager within the connector, very few people know about that can be used let's say for development or even production if you want to that gives you some key metrics. That, we'll demo in the session.
Michaela: I imagine most people haven't even heard of that so…
Mike: yes
Michaela: That'd be really cool if they can see that in your session.
Mike: Yes, yes I'll actually do a live demo with some of the testing that will see the sessions go from one through to the other and we'll be able to see that traffic inside that [inaudible] [07:34] connector admin.
Michaela: Any other common things you see when you are helping people out with scaling this servers?
Mike: You know, I would say having a plan for when things go wrong. So Knowing where to look. I talk about putting in some alerts that will generate snapshots which is usually where I go when I find a problem I will definitely, I will want to have a snapshot at the exact moment of the issue and nine times out of ten if I have that I can solve the problem pretty quickly. Because it will tell me whether it's a database issue or it's a code issue you know right down to the line number that is creating the issue.
Michaela: And when you say alerts, you're talking about a ColdFusion server monitor built into ColdFusion.
Mike: Right.
Michaela: Or Fusion reactor all something else?
Mike: All of the above and right, because you can certainly do all of the above. I would but I think the unresponsive [inaudible] [08:39] is one everybody has and probably everybody should be using you know [inaudible] [08:44]. That is easy to implement and you could to tune that to how many unresponsive requests you know it in a troubleshooting mode you probably set that to one minutes thirty seconds and then generate the [inaudible] [08:59] you know so you know we're getting some more details during session but yes.
So certainly that's one area having a plan for when things go wrong and knowing you know what you are going to be doing, what you want and what you going to want to be looking at.
I think a lot of times, people they just you know, they don't even know that you know where the log files are a lot of times. So, they end up you know looking at the you know log files to stack traces and then [inaudible] [09:27]
Michaela: Yes, well the log files could be pretty cryptic too, so.
Mike: Yes, you know and there's more than one so [inaudible] [09:38]. So there's several ones you have to know which [inaudible] [09:44] and you mention Fusion Reactor too, so yes, exactly any monitoring tool is going to help you get visibility. It's going to help you Fusion Reactor also can give you a [inaudible] [09:57] at any time and moment time. And also keep rolling logs of every request as well as the resources at the time of any requests. And also what JBC [inaudible] [10:12] were done how many records back to the database. So there are several ways of getting more visibility.
Michaela: Yes, I think Fusion Reactor has a lot of good things. I did a broadcast episode with David Tattersall from Integral who make Fusion Reactor and I'll link that into the show notes for the people who are interested in that because they just came out with a cloud version that can like store enormous amounts of data because it doesn't have to go in the server. So lots of cool stuff.
Mike: I have several customers that love Fusion Reactor so I [inaudible] [10:48] customers.
Michaela: You know, so you mentioned deploying your application across multiple servers. So is that the only way to go or can you use JBM instances or containers to, what are the different options you have?
Mike: Well absolutely I think we're starting to see containers creep in to the solution I mean where I think today 97% of the solutions out there are mainly VM based. Oh I think you know several of my customers are looking at containers. So we'll talk about that a little bit but in the end it doesn't really I mean you still need have to keep track of your key metrics knowing you know, you're going to be basically going to be using [inaudible] [11:38] orchestration. You just still enough to tell the orchestrator how many loads you want inside your [inaudible] [11:46] orchestration. And so, we'll talk about that a little bit but we won't get into much detail.
Michaela: So what about multiple JBM instances, does that mean multiple instances of ColdFusion or is that something different?
Mike: Right, so I think well you can do it a few ways or you could scale by having multiple JBMs on one VM load or you can use multiple instances across many VMs. What we typically see is some one instance per VM is what is most part you know and I've seen both. I've seen where you have two, three, four instances on one VM and then you have four VMs and overloads. And you went up at sixteen instances that all communicate together or some crisscross of communication.
Michaela: Now between these different options is the licensing basically the same you know every instance you need to pay for or some of them don't have that issue?
Mike: Yes, you would have to abide by the ColdFusion new law and User License Agreement and I would. If you have a licensing questions I can take those offline it gets a little [unclear] [13:09] with VMs and I think then are several different ways you can license VMs. And you know, and then scale matters to as far as you know [inaudible] [13:21-23] discounting you know that. So I would definitely recommend contacting Adobe for licensing [inaudible] [13:30-32] oh yes, so it does matter. I mean you know and how you scale you need to consider licensing.
Michaela: Right but basically as if we'll talk about later you're using containers and you have dynamic scaling going on so.
Mike: Right. I still think they're working on that I think Adobe still working on some new verbiage when with 2018 with containers.
Michaela: Yes, so if you do this where you've got your application deployed across multiple instances or servers or containers, what happens with when one of them goes down, does that screw up what's happening on your site or?
Mike: Not exactly, so that's where you're planning comes in, that's what the session tries to address. It tries to you know bring into those decision points and have a plan for knowing if a server goes down with what exactly is going to happen, so. If you build in a session reliable architecture, your session should just be able to move from one load to the other whether it's a VM or a container and the end user would have had no knowledge that there are now been served by other.
You know that changes to if you're more of a you know traditional ColdFusion app versus a web API, you know if you're just using Rest APIs, you might be, there's going to be some different architectures there so you may. You know the Rest API version may already have an architecture that's much more flexible than I'll say than the one that is more traditional legacy ColdFusion.
Michaela: Right so if you have the session switch between servers that might be because that the instant ColdFusion has gone down but it might also just be that particular instance got real busy handling a lot of threads, is that the case. It's doing some balancing of the load between that instances?
Mike: That could be rights are there any type that the load balancer was weighted in some respects. It determined that this is whatever that threshold was ordered than it could just decide to start sending us to the other servers. Now if you had sticky sessions that would occur that would basically always send the same server but in the case where you don't have sticky sessions where you're getting [inaudible] [16:13] then yes it’s a little balancer would send to whatever the next server is.
Michaela: Yes or maybe, I mean I think there are other strategies where even the load balancer knows how busy a server is and it doesn't send the next one it's smart and sends to the one that got the least.
Mike: Exactly, so depending on whatever you're [inaudible] [16:30] I mean if you have liked an F5 or VIP, they typically will just use a networking. You can also do a probe which then call a ColdFusion page and be a little [inaudible] [16:52] intelligence and ask you know whether other servers healthy. There are several options there but that's getting into the specifics of what your load balancer actually [inaudible] [17:03]
Michaela: yes
Mike: Thinking of load balancing, you have you know your Tomcat which is built into the ColdFusion and then you also have your hardware base such as your [inaudible] [17:13]
Michaela: Which do you prefer? Do you prefer to load balancing with software or hardware?
Mike: Probably I would say, probably hardware I mean you're still going to get a little bit more intercept from your F5 big IP and that's what typically what you're going to see out there.
Not too many people use Tomcat because with Tomcat, you still have to get all the way to the connector before it decides where you're going. So you might get bounced. So having an F5 there, you are going to make that decision earlier you know.
Michaela: So what are some of the key metrics you'd be looking at on the server to see if it was healthy?
Mike: Yes the key metrics I mean this goes back to my when I did load balancing and how we would actually determine and have an appropriate number of servers and things like that. So what we would do is we would and I would talk about this the sessions you know basically one way to come up with a number is as far as knowing how many servers you will exactly need to meet your expected load is to actually apply loads to like [inaudible] [18:29] work type of you know just a common union work type of server typical VM let's say.
Apply load to that and then watch the CPU and memory and see how much load you can actually apply that particular VM. And then eventually you're going to get some level of some threshold where you're going to say, “The server basically is comfortable at 50+/sec. This is what we can do and that would change if you have PDF generation or some kind of image manipulation that may only be 10+/sec. So, you get some number that's right and then you do the Math and then you can basically determine in order to properly handle your user base, you would need 10 VMs with that level of communication.
Michaela: So that lets you, that kind of calculation that tells you how many servers or virtual machines you need to buy. But also it helps you plan ahead, so if you know that you're going to get a spike in traffic around Black Friday for example, if you are an E-commerce store, you could plan ahead for that if you knew roughly how much traffic you were going to get?
Mike: Correct yes. Exactly, so you can do it exactly. So you can create that math but you know there's also a lot of ways of using containers and orchestrations as well that you can look at to handle those high spikes like that as well.
Michaela: Yes, so to tell us about containers because that's one of the hot new things people are doing in ColdFusion in the last few years. What exactly is a container?
Mike: Container allows you to use instead of where the VM is an entire OS, a container is basically a layer that allows you to not have to create an entire VM in other to create a new slice of CPU and memory. It's a much more thinner way of managing a VM like the environment. And it's much more scalable. It allows you to condense a lot more servers on the same hardware thus saving a lot of money.
And so it's much more economical in the long run that's probably why it want to basically win over the long term. It will take years to really get into the enterprise but the prior win over the long term because it does give you the consolidation over VM. You can certainly run VMs in containers too but we probably see it and you know eventually replace you know your VM ware ESX over long term.
Michaela: Right. So it's basically a lightweight virtual machine takes up less resources and one of the other advantages, it spins up a lot faster than a VM traditionally does.
Mike: So yes, it's not just sandbox, just sandbox is your process with the CPU and memory at a much at a very thin layer.
Michaela: And then the other thing is you can have that container on your own local laptop that you're developing on, get it all working. Save all configurations in a script language, so it's all programmable as far as configuration and then just upload that to wherever you’re hosting out in the cloud?
Mike: Yes, it we have a number of customers there and we're seeing a lot of customers go that route as though still a lot of traditional VM because ColdFusion out there as well. I know in the CS Summit, I did a survey of the group and I don't think anybody was at Docker or any orchestration in production yet. I think what everybody was looking at was developing with it but it's still not in production yet. And some of them were larger ColdFusion customers.
Michaela: And you mentioned orchestration, what exactly is that in reference to containers.
Mike: It basically, you can think of it as just a set of instructions you're going to tell a product like [inaudible] [23:20] or rancher. You going to tell them a set of instructions as far as how true elastically [inaudible] [23:27] I mean, that's what you're going to actually need or your entire environment. Its price to simplify basically scale of scaling you're different.
Michaela: So instead of you having to manually spin up another instance of ColdFusion running in a container it monitors you know all the dozens or how many containers you have and it decides, “Okay, we're not so busy now we can shut down some of these or it's getting busy let's spin up some fresh copies?”
Mike: Right, yes and then you look at each container that a lot people uses that, each container is like a [inaudible] [24:13] so you know it will regenerate containers as part of its whole management cycle.
Michaela: Oh, so that means you don't ever have to recycle a ColdFusion server yourself ever again if it monitors it and they'll kill a six server.
Mike: Right, yes.
Michaela: Does it take a snapshot so you can know why it was getting sick or before it kills it you know?
Mike: I think that some of the weak points of some of the visibility is probably something, probably one of the weaker points of container so that's, am not sure as far as if it takes a snapshot at all, I think it's definitely one of the weaker points of containers is just in the visibility into a particular container itself. If you have hundreds of them and then trying to figure out which one is causing the problem that's kind of, it's more of a case where trouble shooting is something that I think it's one of the areas that needs to be looked at.
Michaela: Right, because I think ideally I'd like it to not just kill a badly performing container, I'd like it to like cryogenically freeze it so I can examine the body later to try and figure out what was going on.
Mike: yes.
Michaela: Maybe that will happen in the future.
Mike: yes
Michaela: So, you mentioned Rest based or API based applications earlier, how does that fit in with all of this. Does that make it harder to cluster or easier or?
Mike: Oh it's definitely, I would say definitely makes it easier and think if you're, since it's a newer architecture, you're going to be able to, for the most part you're going to answer a lot of the questions around session a lot of them already have some, you're going to have some authentication layer with Rest. You'll have, along with that you'll have some session management layer that'd basically resolve how you're going to manage your sessions. So that by definition almost helps you turn on and off different servers and have little impact on your overall architecture.
Michaela: And how does that relate to people coding using Micro services?
Mike: As far as with.
Michaela: Well, some people split up their app into lots of little services and they kind of the whole app becomes a kind of a Rest thing. So different areas of the app is served by different applets.
Mike: Okay, as far as scaling wise, I mean I don't think you know I think the layers will be there regardless I don't see how you know that should the architecture should kind of address you know, all of that CPIs whether it be the smaller in nature and more larger enterprise.
Michaela: Now, earlier you briefly mentioned load testing, do you have a favorite application you use for that or?
Mike: I've used several in the past but right recently I've just been using J Meter that seems to be all I really need to provide enough stress. I'm not looking to do anything fancy, I'm just trying to might just do like a kind of a workload, a typical workload level of requests just to get you know that there's something I know about the PDF generation that going on I'll definitely include that in my script just to get a good generic workload of particular server requests that's happening on the server. And that it's not hard to stress a server, I mean all you have to do is [inaudible] [28:18] can write four or five different requests and throw a hundred users at it and you'll see the load increase and would quickly see where you are stressing.
Michaela: So J Meter stimulates users. They can log in to part of the site, they can simulate clicking on things or filling out search text and it can kind of spread that out as though a human was thinking between the page requests. What kind of clever stuff?
Mike: Exactly, so you'd write out a few more scripts and so you'd pick a few pages out in your application and you know sampling and then you can tell J Meter I would like to emulate 50 users and they will actually create 50 threads and start requesting the particular urls that you're having in your script.
Michaela: And then can you?
Mike: Correcting and all that stuff.
Michaela: Oh okay, cool. And then can it you can feed in custom like, suppose the user ID and password had to be separate for the different users, you can feed that in?
Mike: Yes so if you… yes you can it has advanced scripting so you can definitely walk through in the variables in your scripts. So you can log in and [inaudible] [29:45] particular pages. You can get advance like that or just, in development you could just code it so if [inaudible] [29:53] what we are trying to do here is show where we're trying to stress a server to get to those metrics. You can get advanced with the scripting or you can kind of just understand what you're doing and these are not off while you're trying to do load testing.
Michaela: Yes, I mean the key thing is you're hitting a representative sample of pages. You can't just send it all to the home pages, it got to go through things typical users do.
Mike: Exactly. And you could probably err on the side of you know your heavier pages so then you get a conservative number.
Michaela: Yes, the other thing I have seen in low testing is you know you can't just hit pages that are displaying data, you've got to do some updates because you may have some contention that happens if someone's updating the data and someone else is trying to do other things from the [inaudible] [30:49] so or they're trying to update it.
Mike: That's true. Yes and there's a whole [inaudible] [30:53] testing but yes. We are now focusing on the performance numbers CPU, memory or any other. Certainly if you're looking at load testing from a testing perspective, right you want to complete sampling [inaudible] [31:06]
Michaela: And you know sometimes you're trying to see okay, what amount of number of sessions can this server configuration handle. Maybe you're also testing that fail over you know you talked about earlier between the servers or maybe you're just trying to find you know what point is the server actually die and what's the bottleneck that caused it to die?
Mike: That's true. So you can, as your servers on a load, you can put them on a moderate load and then take a server out of the cluster and see how that works. You could be browsing the site at the same time as an end user and see what kind of experience you have. You basically take a few servers out of the cluster and with low you know accurate view of what the end user would see.
Michaela: That sounds really important for anyone who has an application that they need to be reliable or scale.
Mike: Absolutely.
Michaela: Now, what about security and all these stuff of load balancing and clusters, does that get affected in any way or?
Mike: Typical, it's not something I focus on in the session I mean you know I would say we've always assumed there's some way of security. We're regardless of the traditional CF app, if its API based application. I think you would probably see security more on the load testing sites or if you were doing actual you know you're looking more at the functional specs within load testing, you would just make sure your security API is you know working within some threshold of acceptable times.
Michaela: Great, well it sounds like you're going to have a really exciting session in CF summit East Mike? Anything else you want to tell people about your session before we move on to another question?
Mike: No that's all. You know I [Inaudible] [33:20] end we didn't cover anything on [inaudible] [33:23]
Michaela: Cool. So tell us why you're proud to use ColdFusion?
Mike: I just always you know had a passion for ColdFusion and I just you know it was described to me one time as kind of the Swiss Army knife of application tools and it always seems like there's a way to do something with ColdFusion. No matter what the problem is there's always a way to solve it. You integrate whether even if you have to do some Java package or something, there's always a way to integrate it into ColdFusion. And lots of great resources out there that are from all the experts on the Internet as far as bringing in scripts and [inaudible] [34:09-10] the more you know to alter the [inaudible] [34:13] of projects and things like that, that are out there in blogs and [unclear] [34:18] of course.
A lot of great experts that we share with that always seem to have an answer so I really just, relatively you know fast I see a lot of applications and in today's world I mean it's pretty hard to even create a slow ColdFusion page. I mean, you would really have to work hard at it to create a performance issue. I've seen some really poor codes and still perform fine. You know these are pages that would take forever but still they work very fast.
So, you know it's very forgiving that way migrations are very forgiving back with ability. I do a lot of migration, so very few problems going from you know 10 to 11 to 16, [inaudible 35:04-08] clean and you can't say that about our products. So, it's kind of like a lot of time, you know you kind of really learn to appreciate working with ColdFusion.
Michaela: That's great. So, what would it take to make ColdFusion even more alive this year?
Mike: You know I always like to see it adapt and see it integrate with all the newer technologies. You know more sample apps with some of the newest and greatest stuff I've been looking at things like View JS recently. So I saw that [inaudible] [35:44] doing some things with Views. So you know may be, you know anything that they can integrate, bring some younger talents in the ColdFusion world and make it you know see a [inaudible] [35:55] world then I think all the better right because you're always looking for that adoptions stories. It's been around a while so you know anything that will make it newer and fresh, I think.
Michaela: You know I was talking with Mike Brunt the other day and he mentioned that Jeremy Laz got a new venture to do with Blockchain and we were kind of saying, “Well how can we marry ColdFusion into Blockchain?
Mike: Exactly yes, anything that brings it into, you know today's technology, it’s okay.
Michaela: Yes, so what are you looking forward to at CF Summit East this year?
Mike: You know I was like seeing the team and everyone getting back probably you know, we've got 2018 coming out so that's going to be new and exciting. Learning about you know the new monitoring tool is probably one of the biggest things, I see that updated the show that up at Summit last year, so I would see what's going on with that. And you know just meeting all and I have some contacts up in DC, so it would be great to see them as well.
Michaela: And may be even relive that earlier conference back in 2000 that was in DC.
Mike: Yes.
Michaela: Cool, so if people want to find you online Mike, what are the best ways to do that?
Mike: Probably easiest way is to just go to my website supportobjective.com as it sounds one word. And you know or just I’m usually at the conferences. I'm usually at CF Summits. I am usually at all the major conferences. So look me up there, and we can sit down and chat.
Michaela: Great! Well we'll put that link and together with all the other things you mentioned in the episode on the show notes page on the Terra tech site. And thanks so much for coming on the podcast today, Mike.
Mike: Absolutely, thank you.
