Largest EE Sites

Lea Alcantara: This episode is sponsored by In Control 2013 Orlando. Escape winter and join Brad Frost, Chris Coyier, Meagan Fisher, Samantha Toy, and many more mobile and web design experts in Orlando for the In Control Conference this February from the 17th to the 19th. Visit incontrolconference.com and use the discount code EEPODCAST and save $200 off on registration. See you there!

Emily Lewis: The ExpressionEngine Podcast would also like to thank Pixel & Tonic for being our major sponsor of the year. [Music ends] Hey Lea, how are things going with you?

Lea Alcantara: Pretty good. I just had a giant site launch last week, so I feel like there’s a huge amount off my plate. [Laughs]

Emily Lewis: [Laughs] Well, we’re talking about largest sites today. What do you mean by giant?

Lea Alcantara: Well, giant for me… [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: Not necessarily in traffic, but just in terms of just getting a whole bunch of done while I’m teaching and things like that. It’s actually a small organization for a specific niche thing, so they are not really meant to have huge traffic, but for me, like big sites, small sites, it’s always stressful. [Laughs]

Emily Lewis: Yeah, that’s the truth, although sometimes small sites — I think it was Brad Parscale who talked about it — sometimes you can get a site that’s almost like a cookie cutter and you can just crank those out easily.

Lea Alcantara: For sure.

Emily Lewis: I like those when those come along. But speaking of different sized sites, I’m excited about today’s topic because I’m not entirely sure what constitutes a large site versus a small site beyond like what you described.

Like for me, I mostly work with small clients, maybe medium-sized clients, but their sites in terms of what’s required of me in terms of designing or development commitments, it sometimes feel like they are very big. Maybe having lots and lots of different types of content that have to be managed in unique ways and relationships created and things like that. Even though maybe this site doesn’t get a lot of traffic, the CMS is, in my perspective, large in the sense of how much development was required.

Lea Alcantara: So that’s why we have our guest, Travis, here today. So Emily, why don’t you introduce our guest?

Emily Lewis: Travis is president of Hop Studios, the award-winning Canadian web design and development firm. An expert in ExpressionEngine, Travis has been working with EE since its beta release, and is the creator of several popular add-ons. Welcome to the show, Travis!

Travis Smith: Thank you very much. I’m happy to be here.

Emily Lewis: We are glad to have you. Do you want to tell our listeners a little bit more about yourself and your firm?

Travis Smith: Absolutely. So Hop Studios started about ten years ago as a web design and development company. We started with a number of different CMSes. At that point, we really used mostly blogging software like Movable Type and WordPress and so forth, and we discovered ExpressionEngine right around the time that it very first came out, right when it was switching from being pMachine. We stuck with it ever since. Right now, most of our clients are ExpressionEngine sites, and we have built a number of different large sites with it.

Emily Lewis: So speaking of large sites, you posted on the Hop Studios’ blog a couple of months ago, back in November, the 20 largest ExpressionEngine sites, and from reading the article, it looks like large is defined, at least in this example, according to traffic?

Travis Smith: Yeah.

Emily Lewis: Is that kind of the standard for defining what makes a site large?

Travis Smith: Well, it is for me for this list. I started keeping a list of large sites actually in 2008 or 2009 because I was building a site that I thought was pretty big and I wanted to know how it compared to the other ones that are out there because we were running into some problems with scaling and so forth, and I wanted to be able to see what could ExpressionEngine handle. So in terms of what makes a large site, yeah, traffic is the primary number or the primary way that I rank this list, but it’s not exactly by traffic. It’s not a 100% by traffic.

Lea Alcantara: So what are the other aspects that would create a large site that isn’t just traffic based?

Travis Smith: What I discovered was that not everybody wanted to tell me exactly how much traffic they were getting.

Emily Lewis: [Laughs]

Lea Alcantara: Interesting.

Travis Smith: Most people were pretty forthcoming with information about their sites in a bunch of different ways, but there were a few that I couldn’t get in contact with, or that I have to guess, or that I have to look up through the public information based on Alexa ranking and so forth. The other things that I would take into account when I made those list, traffic was the main one, but also the size of the database, like how many different entries that it contained, and then I also considered the Alexa rank. Alexa is a web server that tracks your traffic and popularity, but it’s not necessarily something that is exactly lined up with page views.

Emily Lewis: And you also mentioned something in the post about largest also being affected by whether you have like a forum with a large number of members, and you even listed kind of just buzz and awards that maybe the site has won.

Travis Smith: Yeah, absolutely. I mean, one thing is some of these sites that are very, very large, they are not running exclusively in ExpressionEngine. They might have a part of the site that’s custom built or that runs a forum.

Emily Lewis: Oh.

Travis Smith: And the forum is using, sometimes it’s using ExpressionEngine Forum software or sometimes it’s using another forum software, so you can’t only go by traffic. So I took into account a little bit of the name recognition of the site, though really that’s a pretty small part. If you wanted to make a list of the biggest companies that are using ExpressionEngine, that would be a completely different list because, for example, Nike uses ExpressionEngine from what I’ve heard, but not to run nike.com.

Emily Lewis: [Agrees]

Lea Alcantara: Sure, sure.

Emily Lewis: So these different characteristics that you looked up to compile this list, I’m curious, does it translate to defining what is meant by an enterprise system or an enterprise site?

Travis Smith: I would actually say no, definitely not. Because a lot of these sites, they are run by actually fairly small organizations, or they are sites that are really only for information distribution, and an enterprise site for me has a lot. It’s often tied more to enterprise tools like corporate login or levels of editorship or things like that, different ways to do versioning and things that you need in an enterprise environment.

Emily Lewis: [Agrees]

Travis Smith: Some of them do need that sort of thing, but that’s really not what this list would good for determining.

Emily Lewis: It’s interesting because I know I certainly made an assumption that the largest EE sites would be tied to large companies.

Travis Smith: Yeah, you would think that like IBM would be a big — presumably they have their own software, but you think of big sites like when you think of the biggest ExpressionEngine sites, but that’s not actually the case.

Lea Alcantara: Yeah.

Emily Lewis: So…

Lea Alcantara: Sorry, I just also wanted to point out, for example, the Canadian government uses EE on some of their government sites, but that doesn’t mean the entirety of the government of Canada uses ExpressionEngine for their entire system.

Emily Lewis: I would love to be a fly on the wall in the decisions about where they decide to deploy ExpressionEngine in those large organizations where they have many different kind of sites.

Travis Smith: The US State Department also uses it, and they actually do run a very large installation as well, so that’s kind of large from an enterprise point of view and large from a traffic point of view.

Emily Lewis: Why did you decide to put this list together in the first place?

Lea Alcantara: And make it public specifically, you made it public. Because you mentioned earlier that you just started compiling it for your own company cause, but then you decided, “Okay, maybe I’ll compile this and then show it to everyone.” Why did you make it public?

Travis Smith: My background is in journalism. I like writing articles and I like doing research and sharing it, and I thought also that if I published a list like this, I might be able to encourage some other people to share other sites that were running ExpressionEngine and find out if my list really was authoritative or if I’ve left anybody out. So also a part of my research is to put it out there and then get additional suggestions and input.

Interesting, now that you mentioned it, I remember that it was around the time, I guess it was 2008, because it was around the time that change.gov, Barack Obama’s site to transition into the government, was put up and that was an ExpressionEngine site, and I think that that was also part of the inspiration was I had heard about this big site and I wanted to hear about more.

Emily Lewis: Do you think that having a list, like how does it benefit like your firm? What can someone learn from it? Is it a matter of sharing how these sites have handled their traffic and the challenges that they have being a large site, or is it more the promote ExpressionEngine as a tool that works great with large sites? Both?

Travis Smith: Putting it up, at first, it was more from myself so I can maybe gather more information and just know, also to know if my research was correct. I figured somebody would tell me if I’ve made a horrible mistake, but since then I’ve actually found that it’s helped me because it has put me in touch with some folks from other sites who build large sites, and I can sometimes now ask them questions when my site isn’t going so well.

I have heard from many, many people that they use it in their pitches to clients. They’ll take examples from this list and say, “ExpressionEngine can run something as big as a Barack Obama site, or a list of parts, but then it’s probably good enough for your site as well.” So I think it has helped other people with their sales, and I’ve used this as well.

Emily Lewis: You mentioned that it gives you an opportunity to perhaps reach out to other developers when your site isn’t working so well. So let’s talk a little bit about some of the challenges that you’ve encountered with some of these large sites that maybe you don’t see with the smaller site.

Travis Smith: Challenges in terms of building and maintaining it, that sort of thing?

Emily Lewis: Well, like you said, like when things aren’t going so well, what wouldn’t go well? What might happen?

Timestamp: 00:09:56

Travis Smith: Oh, what I find interesting is that sites kind of go to this slow process of slowing down as the traffic grows and as the content grows, there’s sort of an imperceptible slowdown that one day you’ll go, “Wow, this site is really lagging. What’s going on with it?” Even if you haven’t changed something, or you add very small things over time, and each small thing that you add adds a little bit of complexity and a little bit more demand on your server, and then finally there’s some point where your server goes, “No, I’m done.” And then at that point, you need to think about, “Okay, well, how am I going to speed this site up again? Or how am I going to deal with this problem that didn’t seem to be there a month ago and now it’s showing up all the time?”

Lea Alcantara: Is that something that you really can’t anticipate as much? Because it sounds like you deal with it when it finally happens as opposed to … because you only worked with the content you currently have when you launched, and so of course, you make adjustments to that. But is there anything that you do to help, let’s say, alleviate those maybe eventual concerns? Or is that even impossible if you have no idea what the eventual content needs or traffic needs are going to scale?

Travis Smith: Well, you talked about anticipating it, and you absolutely can anticipate it, you just can’t necessarily know exactly when it’s going to happen or how it’s going to manifest. The sites that I build that I know are going to get big, you take that into account when you plan how you’re going to structure the data, how you’re going to organize member groups, how you are going to version them and things like that.

I don’t necessarily think you need to build a site that’s going to last for 10 or 20 or 30 years because demands of the site and the direction of the site might change. You build for the near future is how I feel. You make sure that the site can handle what it is, and then what you think it’s going to be, and then you just have to check back in every once in a while and realize that these things need not just maintenance, but they need improvement over time.

Lea Alcantara: So how do you explain that to clients because sometimes maybe it’s a little bit different with larger clients, but with smaller clients, it’s hard to explain to them that, “Let’s check back on this site in six months and see what happens, or even to a year depending on the traffic or the needs of the site because you might need to do some tweaks based on how they use the site and how the visitor uses the site, et cetera. Is that a conversation that you have right away during a sales process or the signup process? How do you approach that?

Travis Smith: It’s absolutely something that I talk about during the sales process. I get a sense of the client and whether or not they anticipate that the site is realistically going to have long term rapid growth, or if it’s going to be a pretty stable static site going forward into time.

I mean, when I say static, I don’t mean static like a hotel site where you put up a picture of the room and then those are the rooms, it doesn’t have to change. I just mean static in terms of you add additional blog post and you add additional contributors sometimes, but for the most part, the site you build is the site that they’re going to use.

On the other hand, sometimes you don’t know. One of my clients is the Jewish Journal newspaper in Los Angeles, and we built a site for them that was when we launched, I think they had three blogs and I figured they’d probably end up with about 20 or 30 blogs, well, now they have 130 blogs or 140 blogs, and they just keep adding them. So that even the design of the blog page itself, let alone the ExpressionEngine system, that just needs to be rethought and redone along the way.

Emily Lewis: When you’re beginning with an implementation in terms of anticipating that a site will grow, what are some of the key areas that you focus on to set yourself up for the best case scenario?

Travis Smith: I talk to them about what they expect their standard traffic to be, what sort of expectations they have about their audience, and then I also make sure I ask them what they think peak traffic would be in. Sometimes they don’t know and I try to advise them, “You can certainly plan for a day when your traffic is going to double or triple.” But if you’re an event site, you have to plan for a day when your traffic is going to be ten or twenty times as big on the day of your event. Or if you’re the kind of site that is going to be doing a lot of news and sometimes you think that one of your news articles might become very popular, show up on Reddit, show up Boing Boing, something like that, then you need to plan for a server and a site structure that can handle ten- or twentyfold increase, and that’s something that ExpressionEngine itself, I think, has become better at over time.

Emily Lewis: In what way?

Travis Smith: Well, not just ExpressionEngine, but with some of the add-ons that are out there, there are now more options for sites that need to handle sudden spike in their traffic.

Lea Alcantara: What kind of add-ons are these?

Travis Smith: Well, let me think. Solspace has Static Caching module that I use for some sites when I expect that they are going to have really large traffic spikes. Then there’s another one that was announced just recently.

Lea Alcantara: CE Cache perhaps?

Travis Smith: That is another one, but that’s not the one I’m thinking of, but yes, CE Cache is another one that offers a way to cache contents in a way that it makes it so your server can handle high traffic to a single page much more easily.

Emily Lewis: You have mentioned several times the role of the server. What do you do in terms of working with a host provider?

Travis Smith: Well, the other thing that was interesting about putting together this list was finding out from other developers what sort of server setup they have and how they were hosted. When you get to be a certain size, I mean, a lot of people start on shared hosting where they are just one of a couple different websites on one server, and then you tend to go to a dedicated server, which is quite a price jump where you’re the only person taking up the entire resources of the server. Then you get into situations where you want to run across multiple servers which can be even more complicated. You can have several web servers or several database servers or both, and that becomes quite tricky to manage.

Emily Lewis: When you’re working with a client, do they dictate the host provider, or do you try to do that so that you can set yourself up for success making sure you have the right system?

Travis Smith: I recommend and try to gently push my clients towards Nexcess, which I’m happy to mention here. They just recently partnered with EllisLab to be an ExpressionEngine-certified or somehow special ExpressionEngine hosting company. But I’ve been working with them since the beginning and have been really happy with them. But if a client has a particular hosting need or they are already hosted with another web hosting company, we work with that. We just make sure that the hosting company and their hosting setup can handle the traffic that they are expected to get.

Emily Lewis: When you are building out the ExpressionEngine system, you mentioned a little while ago part of it is also deciding how you’re going to set up the data. Are there any rules of thumb you follow? Like you’ve mentioned member records or custom fields, is there anything that you try to follow that helps optimize how the data is collected and then served?

Travis Smith: There’s no single rule of thumb. I try to anticipate — I guess, for me, the two parts of the ExpressionEngine setup where I think you might run into the most clogging in a high traffic situation. One is going to be that you have a lot of embedded templates, a lot of bits of templates that are nested within each other, and that for me, the more complex a site design is, the more nesting of templates that you end up usually needing to do. You need to divide it up into more smaller bits that can be called or not called and so forth.

Emily Lewis: [Agrees]

Travis Smith: So if I’m looking at a really big site, I will really try to push them towards simplicity of layouts and templates.

Emily Lewis: [Agrees]

Travis Smith: And say, “Look, yeah, we are going to spend extra time just simplifying the design and unifying it as much as possible, and that helps the back end because the template structure can be a lot more simple or a lot simpler.”

On the other side, some sites have a heck of a lot of data. I think the biggest number of entries for a site is Zocalo in Mexico, which is a newspaper based out of Mexico City. And the last I checked, they have 700,000 entries and they add hundreds a day so it’s probably 800,000 by now. I mean, it’s quite a site just in terms of the entries, and they run into problems because since they are problems, but they run into issues that they need to resolve because of the amount of data that they have.

But the real tricky bit is when you have relationships. When you have an article that links to a slide show that links to an author that links to categories and related stories, and it’s the relationships that bog down the database because every relationship ends up being more data that you have to fetch. So again, when I’m looking at potentially large site, I’ll try to really simplify and organize those relationships in a way that they are going to be the least demanding for the database server that they could possibly be, and that usually helps by structuring your data relationships carefully at the very beginning and not changing it halfway through your project or through renovation and so forth.

Lea Alcantara: So with all those types of entries for newspaper sites and everything like that, is version control more imperative for a large site, and how do you implement that for ExpressionEngine?

Travis Smith: Yeah, most large sites end up with multiple people working on them, sometimes multiple contractors and developers, but sometimes it’s just multiple editors adding and changing the content. The version control for ExpressionEngine is simple, but I think pretty solid and good. Basically, you can turn on versioning for any entry, and then you can keep an arbitrary number of versions for any particular channel, and I usually save 10, 20 or 40 different versions. It really doesn’t bog down the database that much to keep the old versions around and it really helps you understand who edited this and why, and why it used to say, and where did that broken HTML come from, so that’s pretty easy.

The template versioning in ExpressionEngine is also pretty handy, and again, having that versioning turned on does not slow down a site’s performance at all, and that really helps from the development point of view just being able to quickly roll back or make changes or see what other people have been making changes to a template before you go and change it.

There’s another level of version control which is versioning the files themselves, like the files of your ExpressionEngine install or the files that people are uploading, and that’s more complicated because that’s not handled directly by ExpressionEngine, and so you need to set up your own system or use an add-on that does backups or something like that.

Timestamp: 00:20:17

Emily Lewis: And do you use any sort of third party version control for your sites?

Travis Smith: I do, but it varies on a client by client basis.

Emily Lewis: Oh, does it?

Travis Smith: Yeah. Some clients want more sophistication in the versioning and source code control that they have set up, and for others, it doesn’t really matter because they are a smaller client. They might have a big site, but they might be a small client that’s just working directly with us, and we backup and version control our own files, but we don’t need to set up a system that’s going to be robust for all the different people they might have and climbing around on their site.

Emily Lewis: [Agrees]

Lea Alcantara: For those that do need more robust version control options, what are a couple of EE add-ons you use for those clients?

Travis Smith: At the most recent ExpressionEngine conference that I was at, many of the developers there were talking about using Git as their system for doing source control. Git is the general software that you use and then GitHub would be a web service that is a place that allows you to store and distribute the files that you are working on. So Git would be one to mainly to version control the files of ExpressionEngine or the add-ons that you add or the custom code that you’re writing. The other tool that I use is a tool called Backup Pro from Safe Harbor, I think it is.

Emily Lewis: [Agrees]

Travis Smith: And that is, it’s not a version control system, but it is a way to backup all your files and your database on a regular basis, so I find that that is actually a really good tool as well to make sure that what you’re working on doesn’t get lost.

Lea Alcantara: Okay, just to clarify, you meant Backup Pro by Mithra62 because Safe Harbor is the competition to Backup Pro. [Laughs]

Travis Smith: Is it? [Laughs]

Lea Alcantara: Yeah, yeah. [Laughs]

Travis Smith: Let me call up and see which one I was using.

Lea Alcantara: EEHarbor creates Safe Harbor. Backup Pro ,created by Mithra62.

Travis Smith: Backup Pro was the one that I’ve used recently. I have also installed Safe Harbor. I’m agnostic when it comes to these tools. I use the one that’s best for the particular situation.

Emily Lewis: [Agrees] We’re going to be talking with Eric Lamb for our next episode, so I apologize for putting this on you because it will be a question I ask him, but I have never actually done anything with formal backup other than relying on what my host provider would do for me. So can you explain to me like, do you have to work with the host provider to make sure that your backups don’t contradict theirs? I mean, what’s the process with the backup approach?

Travis Smith: Absolutely. All reliable web hosting companies are going to offer some sort of comprehensive backup strategy. However, over the years, I have occasionally had problems where the web host, despite their comprehensive backup strategy has completely failed to backup my site properly.

Emily Lewis: [Agrees]

Travis Smith: And that’s been disastrous. If you have a company that you work with regularly, and even the company I work with, you should occasionally test them. Ask them to recover a file for you from two weeks ago. Ask them to give you a copy of the database from yesterday. You don’t need to do that often, but it definitely is the case that their strategies, their backups for your site might be corrupt or turned off, or who knows what. It has definitely happened.

Emily Lewis: So it’s a lesson you learned the hard way, it sounds like.

Travis Smith: I definitely learned it the hard way, yeah.

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs] I’m glad I don’t have to learn the hard way. Yeah, I think I need to start doing those right away. [Laughs]

Travis Smith: I believe the quote is, “There are two kinds of people in the world, those who have lost data and those who are going to lose data.” It will actually happen to you. Even if your web host company has a backup strategy, it might not be perfect or completely in line with what you need.

For example, one web hosting company that I worked with, they kept a snapshot of the database everyday for seven days, and then every week for four weeks, and then every month for three months. So you could get a copy of last month’s data, but you couldn’t get a copy of data from the month and a half ago, or you couldn’t get a copy of the data from ten days ago, you can only get it from seven days ago or fourteen days ago.

So you need to be aware of what they are actually backing up, and if it’s good enough now, you can be sure there always going to be times when you’re like, “Oh, I wish I had data from eight days ago, or nineteen days ago.” And you just have to suck it up as that happens, but at least understand your web hosting company’s backup plans and whether or not they are going to be able to restore things for you.

It’s really critical because usually it’s just one piece of data that you put a lot of work into that’s gone. If it’s all your data, chances are, they’ve got a full backup of that. But it’s often that case where you’re like, “Oh man, that was huge.” It was a small detail, but a huge piece of work, and so in answer to your question, no. You can definitely have your own backup strategies and that won’t conflict with your web hosting company’s backups. You just shouldn’t rely exclusively on that if you want to be totally safe.

There’s also been cases where I’ve had clients who wanted to move away from a web hosting company as they had a bad experience or they were in sort of conflict and having their own backup was a huge…

Emily Lewis: Oh, that make sense too.

Lea Alcantara: Yeah, absolutely, and sort of related to formal backup options, because I know the majority of the time when I do a client backup is when I update a site. I do the backup right before I start uploading new files and all that fun stuff. Now, I imagine that a larger site would be a little bit more cumbersome to update. So how do you update a large site safely and quickly? Is there a particular workflow or process for you?

Travis Smith: I would not put safely and quickly in the same boat…

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs]

Travis Smith: When you have a big site, some of the things to think about when you’re upgrading it are, even just how long it takes to backup all the files and the database, and usually those big sites are pretty dynamic, so if it takes you an hour or two to backup the files and put them somewhere safe and make all your changes and test, that could be two hours of comments or even of new articles that you need to think about how you’re going to deal with. It’s interesting that the smaller sites, you can upgrade them or make changes. They are only going to be down for a couple of seconds, or a minute or two while you make your small changes, but the big sites that have a lot of data and a lot of things to think about, those are ones that are hard to upgrade.

Again, I don’t have one particular way that I do it. I do have procedures that I follow and names that I try to stick to. I always have a database called “EEDB.” I always have a database called “EEDB Back.” There was a time about two years ago when I was upgrading a client’s site, and I took the data from EEDB and I copied it to EEDB Back and went to do the upgrade and things went horribly wrong because they were running live using the database EEDB Back. That was where all their data was, it was in the backup database, and that was what they were running on.

Emily Lewis: Oh no.

Travis Smith: So I took like a really old crappy version of the database and put it over the live one, but that’s a bad idea.

Lea Alcantara: [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: A little bit, a little bit.

Travis Smith: And in that case, it was the web hosting company’s backup that saved me because they had a backup of all the databases from that night.

Emily Lewis: We’ve talked a little bit about some add-ons for caching, and I’m curious, are there any other add-ons that are absolutely critical for you that you are commonly using for these types of sites?

Travis Smith: For large sites, let me think. Not specifically because of the traffic. Like I say, the static page caching module from Solspace is very, very useful, and that’s probably the main one that I use. In some ways, you want to use as few add-ons as possible, especially for large sites because that adds complexity when you’re upgrading with possible conflicts from version to version, and just more code and more database calls and more load, more demand on the server.

Lea Alcantara: Good point.

Travis Smith: So the simpler you can make the site, the larger you can get it.

Emily Lewis: So does that mean that sometimes you choose to forego an add-on that — I guess the way I would describe it would be to create a better content author experience like maybe a WYSIWYG editor and default to the built-in Rich Text editor.

Travis Smith: Yes, absolutely. It’s not a simple question to answer though, because sometimes an add-on can allow you to do something in a more direct or simple way, whereas if you are doing it with just native ExpressionEngine functionality, you might have to do more work or build more of a workaround to make it work.

Emily Lewis: [Agrees]

Travis Smith: On the other hand, some add-ons, especially from new or relatively inexperienced add-on developers, they might not be as efficient or effective in the way that they work with the database in the amount of CPU that they use. So it’s not a simple question to answer, but most of the big add-on developers write add-ons whose code is very efficient, and then it’s just a matter of the overall complexity of the site. It’s not the add-on developer’s fault, it’s just when you have a very complex page to load that has comments and ratings and favorites and things for people who are logged in and things for people who aren’t and that sort of thing, that can be a very weighty page.

Emily Lewis: Is that something that you evaluate before making a decision on an add-on? Let’s say a client is asking for some very specific functionality, there’s an add-on out there that can deliver on that. You have experience with add-on developments, so how do you evaluate whether it was built efficiently? Like do you go into the code, or do you run performance tests?

Travis Smith: I’m really a nosy and curious person, so I dive into the code and look at it and try to figure out how it’s doing its thing, and whether or not it’s doing it in the most efficient way. And then it’s handy because I can learn how to improve my own add-ons. That’s one of the things I love about ExpressionEngine is you can see the source code of all these add-ons and you can learn from it and improve your own work.

Timestamp: 00:30:06

Emily Lewis: So is there any reason why you would choose not to use ExpressionEngine for a large-traffic site?

Travis Smith: Oh, 95% no. There’s no hesitation I have. If there are times when I don’t recommend ExpressionEngine, it’s because it lacks the functionality that the end user might want, or the functionality would be so expensive to build custom that they would be better off with a tool that did that specifically, and even that, more and more these days, ExpressionEngine plus its add-on community can do just about anything that a client wants.

Emily Lewis: We all know, all three of us know how customizable ExpressionEngine is, but in terms of the performance and handling traffic, is there anything inherent in EE that makes it easier than maybe dealing with another content management system when you do get those huge peaks where an article got promoted on a popular site or something? Is there something inherent in EE that can help you address that?

Travis Smith: No, and in fact, unfortunately, still to this day, it’s a little bit the other way around, but ExpressionEngine sites, I think they run very well at standard load, but they are pretty efficient, and that they can be built in a way that is pretty efficient and doesn’t have a lot of demand on the database. But out of the box, ExpressionEngine sites are not great at handling those big, unique traffic spike events, and so they require some knowledge and expertise to be able to deal with those sorts of situation in a way that some other CMS tools don’t.

Emily Lewis: In the beginning when that happens, maybe one of your early sites where you did have a traffic spike, what did you do? Like what was the first place you went to for help?

Travis Smith: Talk to your web hosting company. Tell them what’s going on. Tell them you really want that traffic. You don’t want to send anyone away empty-handed and just get them to help you. They might be able to do something on the server immediately. Because you can prepare, you should prepare for a high traffic, but you can’t necessarily know where the bottlenecks are going to be, or what you can improve until you’re actually seeing that high traffic and you can test with it. Yeah, you can run sort of simulations of high traffic, but on those busy days, those are actually the days that you have the most opportunity to improve. What did I do originally? What I would originally is I would take a snapshot or I would just take the source of the single page that is experiencing sort of the huge amount of traffic and you can just make that into a flat HTML file, put that up and it can handle a whole bunch of traffic.

Emily Lewis: Oh.

Travis Smith: The downside is that you can’t make that page customized for each visitor with their login information, or you can’t get the comments to update live. It’s a frozen snapshot, but on a day of high traffic when you want people to read that content, that’s a quick and easy way to deal with it. Just make an HTML page, put that up, and use that for just that one busy page.

Lea Alcantara: Do you use MSM for any of these large sites, or would you ever use Multi-Site Manager for these large sites?

Travis Smith: Yeah, absolutely. MSM is a really great solution, but it’s a solution to only a small set of circumstances. There are actually times when I might run more than one site out of an ExpressionEngine install, but I don’t want to use Multi-Site Manager. There are times when you actually wouldn’t want to do that. Not just because it cost a little bit of extra money, but because you don’t need its functionality. But yes, Multi-Site Manager lets you run a whole bunch of sites out of one install, and I don’t have any. As far as I know, none of the ones in the top 20 are MSM sites other than they might have a very small secondary site, but I think there are probably — I know that there’s at least one huge MSM install out there that has hundreds and hundreds of sites and altogether its total traffic is really big, even though no individual site has a lot of traffic, so that would be a perfect use for it.

Emily Lewis: Have you ever been in a situation, or is it possible that if you have MSM running several sites, one of the sites gets a major traffic hit, does that affect other sites running on the install?

Travis Smith: Yeah, it absolutely would. It absolutely would. They would all start to slow down if one site was putting a huge load on the server.

Lea Alcantara: In those cases, does it make sense, for example, if you can anticipate this, you know that, “Okay, here’s a group of sites for this large client, but you know this one particular sub-site is going to be more popular than the rest, do you actually decide to install that one on a separate ExpressionEngine install so it’s on a separate database? Or if they are all on the same host, does it matter if they are on a separate database or not?

Travis Smith: I mean, these are very, very good questions. So yes, if there was one site that was going to always have a tremendous load and you want it to be able to protect the other sites from that, you should split it off and put it on its server and give its own database and have it via a separate install as opposed to as a part of a Multi-Site Manager. On the other hand, if you’re looking at hosting a bunch of sites efficiently and you know that you have 40 sites and none of them are going to be spiking at the same time with the others, but they could all benefit from being on a nice big server, then use Multi-Site Manager, put them all on the same dedicated box and you’re sharing resources effectively across sites that might have different traffic needs like a business site and a personal site, one that’s busy in the evening, one that’s busy on the weekends, one that’s busy during business hours. It could be a really efficient way to make the best use of your computer resources. Because you also don’t want a computer just sitting idle, an expensive set of server sitting idle for months at a time waiting for a big spike.

Lea Alcantara: [Agrees]

Travis Smith: So there’s always tradeoffs, and what I tell my clients is, “We can build your site and we can build to prepare for double the traffic, or we can build it to prepare for ten times the traffic if that’s where you think your traffic is going to go, but there’s always going to be a traffic event that you need to decide that you’re now going to prepare for.”

Emily Lewis: [Agrees]

Travis Smith: If you want a site that’s able to handle a one hundredfold traffic increase, we can build that for you, but that means that your site is going to be 99% underutilized 99% of the time, but you just have to be ready for that.

Lea Alcantara: That makes sense. Well, thank you, Travis, for joining us today. I think that’s all the time we have.

Travis Smith: You’re welcome, and great talking to you.

Emily Lewis: For us as well. In case, our listeners want to follow up with you, where they can find you online?

Travis Smith: My website is hopstudios.com, and we are on Twitter at @hopstudios. Those would be your best bets.

Lea Alcantara: Perfect. So now, [music starts] we’d like to thank our sponsors for this podcast, In Control 2013 Orlando and Pixel & Tonic.

Emily Lewis: We also want to thank our partners, EngineHosting, Devot:ee and EE Insider.

Lea Alcantara: And thanks to our listeners for tuning in! If you want to know more about the podcast, make sure you follow us on Twitter @eepodcast or visit our website, ee-podcast.com.

Emily Lewis: Don’t forget to tune in to our next episode! Eric Lamb from Mithra62 is joining us to talk about backup options for ExpressionEngine. And be sure to check out our schedule on our site, ee-podcast.com/schedule, for more upcoming topics.

Lea Alcantara: This is Lea Alcantara …

Emily Lewis: And Emily Lewis …

Lea Alcantara: Signing off for the unofficial ExpressionEngine Podcast. See you next time!

Emily: Cheers!

[Music stops]