Re: Private thoughts from CoPress

[Joey Baker]

Hey guys–

First off, this is now on the public Google Group — like we talked about earlier.

• re: MySQL in RAM. Dean clearly has more experience that me on this score. I think we're arguing the same point that it's faster to cache in RAM. It's also my belief that Drupal nor WP are setup to work that way. If it's one line of code, then score! But I have to ask, why don't most people take this approach?

• I'm not entirely sure what the benchmark proves except that Drupal 6 is faster than 5 in page cacheing and that page cacheing works (what what to opensource development!).

• When you do the test on your dorm computer, why not just set up 5 different sites? That will give you 5 databases and be a really good simulation.

Thanks again ya'll for continuing this discussion! I feel like I should put a disclaimer here: I've worked with Drupal on several business projects and truly respect and understand its power and allure. It is a fast, flexible, CMS that can do just about anything you can dream.

The issue here, and I think it's philosophical, is what we're trying to accomplish. WP is a CMS that, with a few plugins, is ready to go nearly instantly for any newspaper. No, it's not the perfect solution, but it is fast.

Drupal could very potentially trump WP as a CMS for newspapers. The problem is that it takes a very long time to setup. That dev. time could be put toward developing a Django/RoR/other rapid-app-prototype thing. Or just getting up and running now on WP.

And this is our biggest difference, (I believe). Drupal will never be quite as good as a home-grown CMS. Starting from scratch more drastic an approach then starting with Drupal, and will take longer. But we're really excited by Populous and have high hopes. In the meantime, we're going to go with WP.

• We can do it now!

• We've got experience with it. Beta testing with WP is already done. It's just a matter of beta testing our service/servers.

• WP is ~95% of what we need anyway.

• Our next move will likely be to a CMS that is 100% of what we need.

Cheers,

____________________

Joey Baker

CoPress Business Development

The Daily Orange

m: 408-220-4221

www.byjoeybaker.com

twitter: @joeybaker

On Jan 3, 2009, at 10:08 AM, Miles Skorpen wrote:

WordPress is missing things—no question. But so is, for example, Drupal in comparison to Django. Drupal isn't a framework, so it is harder to build new tools with Drupal than with Django ... but people choose to use Drupal instead of Django (or instead of Ruby on Rails or any other coding framework) because it makes doing some things easy.

The same is true of WordPress. And I think you should take a closer look. For example, it isn't all that hard to manage the front page of a WordPress site. Categories can easily feed into slots on the page. WordPress DOES have custom fields (and a lot of plugins use them). Take a look at this demo theme to see how it could work— http://www.revolutiontwo.com/demo/church.html . I think that page is a lot more complicated than the one you linked to earlier, and WP handles it with ease. Doing some of the more complicated story sorting can be a bit more difficult with WordPress—but there are work arounds, and WP makes a lot of other things (like theming and updating) a lot easier. I haven't had any experience with Drupal, to be honest, but I also have trouble thinking that its theming engine is much more powerful than WP's—2.7, in particular, is VERY impressive in this regard.

WP certainly has its problems—the admin isn't really set up for a large organization, among other things, but I think it deserves more credit than you are giving it. (And WP makes it really simple to have section pages, blog integration, and support all sorts of multimedia.)

Miles

On Fri, Jan 2, 2009 at 7:53 PM, Zhuiyang [Dean] Chen <de...@ocirs.com> wrote:

Wordpress is missing a lot of little things though. For example, there is no easy way to manage the front page on wordpress as far as I know. I'm not aware of a wordpress equivelent of CCK which allows us to add in custom fields for different types of multimedia, multiple authors, custom teasers. There is also no equivlent of the views module that allow me to easily change the content filter, format and sort order for each box. Also wordpress does have a pretty easy to use sidebar control, it's still no where near as powerful as Drupal's panels, which allow for drag and drop setup of side bars for the articles and any of the boxes of the front page. Drupal's theming engine is also much more powerful.

Everything is just easier to do and work with in Drupal after a site surpasses a certain complexity, we actually did quite a bit of research with various CMS's including Wordpress and Django and conluded the Drupal is our best option. Our site is also far from feature complete at this point, we still need section pages, blog intergration, multimedia support to mention a few.

--
Dean

On Fri, Jan 2, 2009 at 4:45 PM, Miles Skorpen <mi...@copress.org> wrote:

Hello! I just thought I'd add my $.02 ...

Looking at ocirs.com:99 ... it actually wouldn't be hard to do something like that. Each section would be a different category, and it would use custom fields to set the images—I ran a site that had a significantly more complicated front page on WordPress for a year before moving to Django.

The downside to doing this is the number of requests it requires from the database. WordPress is known for being pretty bad at this ... which is why there are a number of really awesome WP caching plugins out there. If we were pulling everything from the database, would it start to slow down? No question. But since 99% of the pages aren't going to change much, most calls will be for static pages, dramatically reducing the load on the database.

Eventually, when we have a whole bunch more schools, I imagine that we'll create a setup with load balanced server and several dedicated database machines. But now, with an expected 5 (smaller) schools per server, I don't really see this being necessary.

Miles

On Thu, Jan 1, 2009 at 6:24 PM, Zhuiyang [Dean] Chen <de...@ocirs.com> wrote:

Yeah, I don't mind if you add this thread to the public CoPress group.

Anyways, a few counter points.

• mysql has a feature called query cache that caches all queries in RAM, it's a one line setting in mysql's ini. Here is a benchmark testing this feature. http://www.weberdev.com/get_example-4920.html The performance difference from caching and querying from database on disk is huge, 151ms v 4507ms. And much of the response time from Drupal is database related, so the 30x difference in performance is going to have a huge impact on viewer experience, not to mention the potential CPU resources saved from not have to do the look up.
• There is also a certain point where HDD speed isn't a luxury but a necessity, because when the total numbers I/O's from database queries and the operating system exceeds the I/O capabilities of the HDD, the site is going to grind to a halt, I don't know what that point is but I'm pretty sure it's close. I/O has an equal share if not larger impact on performance than the cpu and memory. I'll do some testing once I finish developing the site. 
• Here's a old benchmark of Drupal with some older hardware, but I think it reflects pretty well the individual resources per virtual server. The shows that Drupal can only handle 150 requests per second to anonomous users, and that's only with core modules.
• I also manage and made our blogs at Chronicleblogs.com which are all wordpress based so I have some pretty extensive Wordpress experience, it just doesn't have the power and flexibility of Drupal. It will be near impossible to create a easy to manage and update frontpage like our current demo at ocirs.com:99 on Wordpress let alone all the section pages and extra multimedia features.
• I'll do a benchmark on my dorm computer when I get back to school and forward your the results, but it won't reflect the fact that the resources are being shared 4-5 ways.
  

On Thu, Jan 1, 2009 at 4:47 PM, Joey Baker <jo...@byjoeybaker.com> wrote:

Sorry guys, just want to cc greg on this, as The Alligator is actually running a WP install right now and may be able to speak from experience on server-load.

-Joey

On Jan 1, 2009, at 1:42 PM, Joey Baker wrote:

Dean–

Thanks a lot for the info!

I'll be upfront with you: I'm on the webdesign and project-management as opposed to the web development side of things. I'm also a software, not hardware guy. In other words, I'm a self-recognized non-authority on all of this… however, I assure you, I'm not the one who's made these server decisions. :)

I know enough to hurt myself on this stuff, so… I've talk to a coupla a guys who actually know there stuff. I've also cc'd Miles on this — he's the guy who's managing our hosting effort/knows his shit.

Here goes:

• As far as I'm aware, neither WP or Drupal use the advance features of MySQL to enable tables to live in RAM, therefore I'm not really sure what adding more will do. 4GB of RAM for a PHP+MySQL solution (as opposed to Django or RoR) seems totally doable to me.

• HDD speed is always nice, but RAID 0, aside from the obvious data-loss danger probably just isn't necessary. Speed is always good, but it doesn't seem likely that we'll really need all of that extra-head room. We're not talking about large databases, or large files here.

• Both Drupal and WP are extremely well-designed CMS's that are very good at resource management. Yes, it is possible that this server may not be able to handle the load. Possible, but not likely. The software is good at managing it's resources and I think that without proof it's hard to argue that the server will come under heavy load.

• I understand your worry about a slashdot effect. Yes, it is possible that our server can't handle it, but follow my math here a second.

   • 5 newspaper sites * ~15,000 pageviews per day = 75,000 pageviews on the server per day.

   • A slashdot effect on dailyorange.com recently resulted in ~100,000 pageviews.

   • Assuming that the rare slashdot effect will only happen to one site at a time, this means that we need to account for less than double the daily traffic to have enough headroom to maintain the site.

   • A slashdot effect will be one page getting a lot of traffic. This page needs to be cached once (both Drupal and WP have a cacheing) and then the load is off of the HDD. The question becomes RAM and bandwidth. Less so on the ram if you're not really dealing with signed in users.

• I'm not saying that I know for sure that the server can handle every possible scenario, but it seems to me that we're pretty well set. If we encounter a problem, we add more X and solve it. We stress reliability, but we're not anticipating a need to host twitter levels of traffic.

• I'm not sure how much you've played with WP over Drupal, but I'd urge you to take a look at it. There are some really impressive features on it. No, it's not a full CMS, and yes, Drupal can do more. But I'd challenge you to come up with a list of things Drupal can do that WP can't that justifies the extra development time/money/hassle while you're still sitting, suffering on CP.

• Seems like you're putting a lot of research in so one more challenge if you're willing: give it a shot. By which I mean, grab your dorm computer — which you mentioned was as good as the server we've configured — and simulate 175,000 pageviews on a Drupal and WP install. You've got me nervous enough that I'd be relieved to have the results of that test — especially if they prove that we need a more powerful server.

• Last thought: I love playing with the big boys as much as the next guy, but it's important to recognize economy of scale. We're not building CNN.com or nytimes.com here. These sites are just never gonna receive traffic that would even register on the radar of these sites. (Heck, CNN survived an attack from all of China this summer.) It's just not really necessary to get top-of-the-line.

Last thing (promise): we've kept all of this private so far, would you mind if we add the CoPress Google group into this thread? (that would make it public.)

Cheers,

____________________

Joey Baker

CoPress Business Development

The Daily Orange

m: 408-220-4221

www.byjoeybaker.com

twitter: @joeybaker

On Jan 1, 2009, at 12:19 PM, Alex Klein wrote:

Joey is now copied on this thread in case you guys want to continue this debate for which I am woefully uninformed!

Joey, feel free to copy anyone from CoPress in any of your responses and copy me, too.

AK

On Thu, Jan 1, 2009 at 2:18 PM, Zhuiyang [Dean] Chen <de...@ocirs.com> wrote:

Sorry, just read Joey's blog and and to clarify my forth point about I/O, I corrected it a bit.

My main concern is actually not processing power or bandwidth but hard drive I/O from the database accesses(this applies to wordpress but especially to Drupal) especially when you have multiple sites accessing the same hard drive(which I assume to be 7200rpm since it is 250GB). I think this bottleneck will be become obvious with two or three sites during normal peak traffic, when the response time increases significantly and requests per second can't increase past a certain point causing abnormal page loading delays for viewers. I think that one of the improvements, such as doubling the RAM to 8GB or upgrading to faster hard drives(to 10,000rpm or 15,000 rpm) or setting up a RAID 0 configuration. Increasing the RAM will decrease hard drive I/O since it will allow most SQL queries to be cached to RAM making hard drive access unnecessary in most cases which increasing hard drive speed will allow for a higher I/O.

On Thu, Jan 1, 2009 at 3:08 PM, Zhuiyang [Dean] Chen <de...@ocirs.com> wrote:

Hey Alex,

Thanks for the update, can you forward this to Joey?

• Drupal is much more resource intensive since it is meant to be a more complete CMS solution where wordpress is more like a blog. Much of the resource costs, and features come not from drupal's core but from the much wider range and power modules that I installed seperately. Our wordpress blogs on the other hand are running mostly on the core with the exception of some pretty insignificant plugins(resource wise).
• CoLo wise, we have the huge advantage of being near Raleigh, NC where there is a huge technology and therefore datacenter sector. Therefore, we would have much easier access to our servers than usual. The main advantage to CoLo is that we can utilitize the latest processors, SSDs and load up on RAM which is very cheap right now.
  
• I plan to do a cost/performance/ease of management/scalability analysis on S3 and all our other hosting options since all of our options is viable and very different in nature. However, that would not be possible until I complete the feature complete version of the site so it will be a realistic representation of the load we should expect. This will probably be at least a month down the line. I would be happy to include CoPress in my analysis if you are willing to provide us with trial access to CoPress, it can very well accomodate our needs once I optimize Drupal since there aren't any benchmarks of Drupal 6 available on a quad-core yet.
• My main concern is actually not processing power but I/O from the database accesses(this applies to wordpress but especially to Drupal) especially when you have multiple sites accessing the same hard drive(which I assume to be 7200rpm since it is 250GB). I don't know how many sites you plan to host on that server but even with two or three sites, the bottle neck should become apparent. I think that one of the improvements, such as doubling the RAM to 8GB or upgrading to faster hard drives(to 10,000rpm or 15,000 rpm) or setting up a RAID 0 configuration. Increasing the RAM will decrease hard drive I/O since it will allow most SQL queries to be cached to RAM making hard drive access unecessary in most cases which increasing hard drive speed will allow for a higher I/O.
• I'll keep you updated on our future progress if you are interested.
  

--
Dean

On Thu, Jan 1, 2009 at 1:54 PM, Alex Klein <axeln...@gmail.com> wrote:

Dean,

The new post is up on CoPress.org. Check it out.

The writer, Joey Baker, sent me this additional feedback and asked me to pass it along to you.

I did want to take the opportunity to briefly address some of Dean's worries more privately.

• I've done some research and I can't find anything to say that Wordpress or Drupal have any speed differences. They're both PHP+MySQL based CMS solutions. That indicates a pretty similar server performance to me. Nonetheless, if Dean's sure that Drupal is more intensive, perhaps the reason he thinks our server specs are sub-par is b/c he's designing a system to run the more process-intensive Drupal.

• I'd think real hard about CoLo before you commit. There's a huge initial investment and non continuous upgrading. That initial investment is going to have to be made every few years as you update the server. Plus, there's nothing quite like having your very own server that you can't touch … and neither can anyone else. I'd highly encourage you guys to look elsewhere.

• Amazon S3 is a real good solution if you're expecting a ton of bandwidth. A lot of Web 2.0 sites — like Tumblr, which I noticed you use, use Amazon's service. (btw…I'm at joeybaker.tumblr.com – love the the site). The problem is that the service really isn't economical for a single school. It's something that CoPress has considered for the time when we get many newsorgs on board, but it's just not an economical plan for low bandwidth. IMHO

• I've written this theme pretty strongly into the blog post, but we really hope we haven't scared you off. We're not just about hosting. There's more to CoPress than that and we'd really like to see you guys at Duke hop on board. Even if it's just adding some information about Drupal to our wiki. Or writing a blog post about your experience thus far. Heck. You don't even have to post it on CoPress (though we do receive some good traffic). Share and share alike.

Happy new year, Dean. Thanks for all your hard work.

AK

--
Dean Chen

--
Dean Chen

--
Dean Chen

--
Dean Chen

[Albert Sun]

Come on guys, this is starting to sound like a holy war.

Clearly both Drupal and Wordpress have their relative strengths and weaknesses or else the projects would have merged long ago. And there is so much variety in college newspapers that it doesn't make sense to try and impose a one size fits all solution on them. My own thoughts on the matter are that Wordpress is probably the best solution for small schools that don't have a lot of in house tech talent. It's the most easily maintained and the easiest to use. More advanced tools, (Drupal, Django, JSP,ASP.NET?lol) are tradeoffs in maintainability against flexibility and power.

Relative performance
From first hand experience running a live Drupal site, I can say that Drupal is quite a bit more demanding of system resources than Wordpress. In order to have multiple valued fields, CCK spawns a ton of new database tables all of which have to be hit on every query. And because of Drupal's hook system, every module has to be loaded each time. That's the price that's paid for the extra flexibility to do anything you like in modules. That said, our site is running on a system configured similarly to the one CoPress is planning on purchasing and we haven't noticed any slowness at all so far. Granted, we haven't gotten any huge traffic spikes yet, but we also haven't gone very far down the optimization, caching road either.

Joey, I don't think Django would be very resource intensive compared to Wordpress or Drupal. Python has the advantage of being able to compile some of it's code to run faster, plus the fact that python imports are much much cleaner and more sensical than PHP includes. Whereas nearly the entire code base of a PHP site has to be loaded on each request, with Python only the known necessary parts are imported.

Liquid Web vs. CoLo vs. S3/EC2
From what I've seen, most services that use S3 only use it for storing their static files. We considered doing it here at the DP for our videos and other static files, but as our server is handling everything just fine so far, we haven't needed to. EC2 doesn't seem to be designed to be used for plain web hosting. It's tailored toward processor intesnive tasks and distributed computing that needs to be run in parallel. Plus I doubt any college newspaper will have the explosive growth that would require that kind of scaling.

Colocation sounds good, it's definitely cheaper and you can get a better box than dedicated hosting, but what happens when you graduate Dean? What if there isn't anyone around who knows as much about servers and can drive out to the datacenter to fix it? Hardware is typically the piece that most easily fails on a server and we definitely didn't want to own our own and have to be responsible for fixing it.

Plus, with Liquid Web maintaining our hardware, they're responsible for backups as well. We purchased a service from them to do a continuous backup of our databases and files so if things go wrong we can roll back the server to how it was at any instant in the past.

I don't know what the Chronicles traffic numbers are, but I don't think any college paper ever regularly serves 150 requests per second or anywhere even close. At ~15000 pageviews per day, that's one pageview per 5-6 seconds. Let's not get ahead of ourselves here, for most of our sites, dedicated hosting of this sort is a luxury not a necessity. The Yale Daily News, one of the most highly trafficked college news sites is hosted (IIRC) on a sub $100/month VPS.

Development Time
Drupal taking longer to develop in than Wordpress I think mostly is because Wordpress has a shorter learning curve. Now that I've done one site in Drupal, I could do a second one extremely quickly. The real issue though is that designing and coding the theme takes the longest time out of any part of it. And here Wordpress wins I think because there are so many quality third party themes that can be downloaded. Drupal doesn't really have any themes suitable for use by a newspaper, and developing one takes time, because you have to learn how to use the theming system.

--
Albert Sun
University of Pennsylvania
Class of 2010
as...@sas.upenn.edu
248.462.0328

[Joey Baker]

YES! we're getting to the part of the discussion where I can say, "I agree with everything except…"

…It was my understanding that Django/RoR both require more RAM to run a basic application than a similar PHP app. So your min. server req's are more intensive. 

Albert and I are in agreement on Drupal vs. WP. Drupal has a steeper learning curve and has more dev time behind it. It is also far more flexible. It also isn't as flexible as a Django solution.

[Zhuiyang [Dean] Chen]

• It's a mySQL setting so it applies to any application that uses mySQL queries; it doens't need any Wordpress or Drupal support. Most people on shared hosts can't modify mySQL settings and I don't believe it's enabled on default mySQL configurations.
• The benchmark was meant to show how many simultanious requests a similar configuration(per host) can handle, it actually doesn't reveal i/o bottlenecks that might occur since harddrive i/o isn't being shared 5 ways.
• I'll run the benchmarks when I get back to Duke on Wednesday. 
• As Albert has mentioned, once Drupal has been configured once, it is very easy to mirror it and change some little things around for different papers.
• Wordpress indeed make more sense for less complex websites since Wordpress has a much simpler management interface and takes up less resources, but I just feel too limited with Wordpress.

--

Dean

 

 

 

--

Dean Chen

 

[Daniel Bachhuber]

I think it's really important to keep in mind too that we don't
consider Wordpress to be a long-term solution for student news
organizations (or at least with v2.7). If Populous doesn't pan out
like we want it to, then Drupal might be a good option. Wordpress, at
this point, makes the most sense for the resources we have and the
scale of what we want to do.

--
Daniel Bachhuber
www.danielbachhuber.com
danielb...@gmail.com
cell: +1 971 998 5407
aim/skype/twitter: danielbachhuber

[Adam Hemphill]

A very good point, Daniel. We're not looking for a "one size fits all"
solution—in fact, odds are we'll grow to support other (several,
perhaps) systems. For the time being, however, WordPress appears to be
a good fit for our initial clientele. Meanwhile, this discussion
closely mirrors the type of thing that CoPress is trying to foster;
thanks to everybody for speaking up and participating.

--
Adam Hemphill
http://www.adamhemphill.com
(860) 428-3619

[Zhuiyang [Dean] Chen]

Albert you make some very good points but there is a couple I have to comment on. My main argument regarding server performance wasn't processing power but I/O, I just don't think a desktop grade hard drive can handle 5 sites with similar traffice patterns. Most hard drives can handle only about 200 I/O's per second.

http://www.xbitlabs.com/articles/storage/display/25inch-hdd-250gb_5.html

Split that between 5 sites each with apache and mySQL individual I/O's and I can't see the system handling all of that.

I also don't expect our daily traffic to fully load the system, but 150 r/s, with no extra modules, doesn't bode well for any traffic specs. The comment about Yale Daily News is very interesting, although it seems that Yale's setup and backend is less complex than our's. I would be very interesting to learn more about Yale's system.

Backup isn't too hard to manage, I was thinking rsyncing to another harddrive and doing a complete backup weekly. And driving to the data center monthly for off site backups. I also think that hardware management isn't a very difficult to learn, if we can't happen to recruit some compsci major I don't think it will be very hard to teach someone how to swap out a hard drive or replace some card.

I've already mostly learned Drupal's theming, so themes aren't much of an issure anymore. The nice thing about Drupal is that now most content can be added and removed through a web interface with panels.

--

Dean

--
Dean Chen

[Zhuiyang [Dean] Chen]

I agree, what I've been trying to say is that Drupal is what I believe to be the best solution for Duke right now. I'm sure Wordpress will be a good fit for smaller sites, especially for those that are trying to total costs, but I think we can do a little better with our budget.

--

Dean

--
Dean Chen

[David Estes]

MySQL's Query Cache seems overly broad to me. Though I've never used
it myself and I may be misunderstanding this, it seems it invalidates
the cache for an entire table after any modification to a single row.
That makes sense from an ease-of-use standpoint, but I'd recommend
getting a little more hands-on and properly integrating memcached or
something similar. (This is easy in Django, but how feasible is it
with WordPress and Drupal?) Also, keep in mind that overly aggressive
caching may give you an overall decrease in performance, especially on
shared hosting or other servers with limited RAM.

Albert/Joey: Django/Python is fairly memory-intensive, but it's less
so than RoR was for us. Both default to keeping their application code
in memory for the entire life of the server process, so I believe
they're more RAM-intensive than a PHP-based solution, but would
(theoretically) have better performance.

- David Estes
The Daily | University of Washington

On Jan 3, 12:50 pm, "Zhuiyang [Dean] Chen" <d...@ocirs.com> wrote:
>    - It's a mySQL setting so it applies to any application that uses mySQL

>    queries; it doens't need any Wordpress or Drupal support. Most people on
>    shared hosts can't modify mySQL settings and I don't believe it's enabled on
>    default mySQL configurations.

>    - The benchmark was meant to show how many simultanious requests a

>    similar configuration(per host) can handle, it actually doesn't reveal i/o
>    bottlenecks that might occur since harddrive i/o isn't being shared 5 ways.

>    - I'll run the benchmarks when I get back to Duke on Wednesday.
>    - As Albert has mentioned, once Drupal has been configured once, it is

>    very easy to mirror it and change some little things around for different
>    papers.

>    - Wordpress indeed make more sense for less complex websites since

>    Wordpress has a much simpler management interface and takes up less
>    resources, but I just feel too limited with Wordpress.
>
> --
>
> Dean

>  On Sat, Jan 3, 2009 at 1:54 PM, Joey Baker <j...@copress.org> wrote:
>
>
>
> > Hey guys–
> > First off, this is now on the public Google Group — like we talked about
> > earlier.
>
> > • re: MySQL in RAM. Dean clearly has more experience that me on this score.
> > I think we're arguing the same point that it's faster to cache in RAM. It's
> > also my belief that Drupal nor WP are setup to work that way. If it's one
> > line of code, then score! But I have to ask, why don't most people take this
> > approach?

> > • I'm not entirely sure what the benchmark<http://vision-media.ca/resources/drupal/drupal-performance-benchmarks...> proves

> > except that Drupal 6 is faster than 5 in page cacheing and that page
> > cacheing works (what what to opensource development!).
> > • When you do the test on your dorm computer, why not just set up 5
> > different sites? That will give you 5 databases and be a really good
> > simulation.
>
> > Thanks again ya'll for continuing this discussion! I feel like I should put
> > a disclaimer here: I've worked with Drupal on several business projects
> > and truly respect and understand its power and allure. It is a fast,
> > flexible, CMS that can do just about anything you can dream.
>
> > The issue here, and I think it's philosophical, is what we're trying to
> > accomplish. WP is a CMS that, with a few plugins, is ready to go nearly
> > instantly for any newspaper. No, it's not the perfect solution, but it is

> > *fast.*

>
> > Drupal could very potentially trump WP as a CMS for newspapers. The problem
> > is that it takes a very long time to setup. That dev. time could be put
> > toward developing a Django/RoR/other rapid-app-prototype thing. Or just
> > getting up and running now on WP.
>
> > And this is our biggest difference, (I believe). Drupal will never be quite
> > as good as a home-grown CMS. Starting from scratch more drastic an approach
> > then starting with Drupal, and will take longer. But we're really excited

> > by Populous <http://www.populousproject.com/> and have high hopes. In the

> >http://www.revolutiontwo.com/demo/church.html. I think that page is a lot

> > more complicated than the one you linked to earlier, and WP handles it with
> > ease. Doing some of the more complicated story sorting can be a bit more
> > difficult with WordPress—but there are work arounds, and WP makes a lot of
> > other things (like theming and updating) a lot easier. I haven't had any
> > experience with Drupal, to be honest, but I also have trouble thinking that
> > its theming engine is much more powerful than WP's—2.7, in particular, is
> > VERY impressive in this regard.
>
> > WP certainly has its problems—the admin isn't really set up for a large
> > organization, among other things, but I think it deserves more credit than
> > you are giving it. (And WP makes it really simple to have section pages,
> > blog integration, and support all sorts of multimedia.)
>
> > Miles  On Fri, Jan 2, 2009 at 7:53 PM, Zhuiyang [Dean] Chen <

> > d...@ocirs.com> wrote:
>
> >> Wordpress is missing a lot of little things though. For example, there is
> >> no easy way to manage the front page on wordpress as far as I know. I'm not
> >> aware of a wordpress equivelent of CCK which allows us to add in custom
> >> fields for different types of multimedia, multiple authors, custom teasers.
> >> There is also no equivlent of the views module that allow me to easily
> >> change the content filter, format and sort order for each box. Also
> >> wordpress does have a pretty easy to use sidebar control, it's still no
> >> where near as powerful as Drupal's panels, which allow for drag and drop
> >> setup of side bars for the articles and any of the boxes of the front page.
> >> Drupal's theming engine is also much more powerful.  Everything is just
> >> easier to do and work with in Drupal after a site surpasses a certain
> >> complexity, we actually did quite a bit of research with various CMS's
> >> including Wordpress and Django and conluded the Drupal is our best option.
> >> Our site is also far from feature complete at this point, we still need
> >> section pages, blog intergration, multimedia support to mention a few.

> >> --Dean  On Fri, Jan 2, 2009 at 4:45 PM, Miles Skorpen <mi...@copress.org>wrote:
>
> >>> Hello! I just thought I'd add my $.02 ...
>
> >>> Looking at ocirs.com:99 ... it actually wouldn't be hard to do something
> >>> like that. Each section would be a different category, and it would use
> >>> custom fields to set the images—I ran a site that had a significantly more
> >>> complicated front page on WordPress for a year before moving to Django.
>
> >>> The downside to doing this is the number of requests it requires from the
> >>> database. WordPress is known for being pretty bad at this ... which is why
> >>> there are a number of really awesome WP caching plugins out there. If we
> >>> were pulling everything from the database, would it start to slow down? No
> >>> question. But since 99% of the pages aren't going to change much, most calls
> >>> will be for static pages, dramatically reducing the load on the database.
>
> >>> Eventually, when we have a whole bunch more schools, I imagine that we'll
> >>> create a setup with load balanced server and several dedicated database
> >>> machines. But now, with an expected 5 (smaller) schools per server, I don't
> >>> really see this being necessary.
>
> >>> Miles  On Thu, Jan 1, 2009 at 6:24 PM, Zhuiyang [Dean] Chen <

> >>> d...@ocirs.com> wrote:
>
> >>>> Yeah, I don't mind if you add this thread to the public CoPress group. Anyways,
> >>>> a few counter points.
>

> >>>>    - mysql has a feature called query cache<http://www.databasejournal.com/features/mysql/article.php/3110171/MyS...>that caches all queries in RAM, it's a one line setting in mysql's ini. Here

> >>>>    is a benchmark testing this feature.

> >>>>    http://www.weberdev.com/get_example-4920.htmlThe performance

> >>>>    difference from caching and querying from database on disk is huge, 151ms v
> >>>>    4507ms. And much of the response time from Drupal is database related, so
> >>>>    the 30x difference in performance is going to have a huge impact on viewer
> >>>>    experience, not to mention the potential CPU resources saved from not have
> >>>>    to do the look up.

> >>>>    - There is also a certain point where HDD speed isn't a luxury but a

> >>>>    necessity, because when the total numbers I/O's from database queries and
> >>>>    the operating system exceeds the I/O capabilities of the HDD, the site is
> >>>>    going to grind to a halt, I don't know what that point is but I'm pretty
> >>>>    sure it's close. I/O has an equal share if not larger impact on performance
> >>>>    than the cpu and memory. I'll do some testing once I finish developing the
> >>>>    site.

> >>>>     - Here's a old benchmark of Drupal<http://vision-media.ca/resources/drupal/drupal-performance-benchmarks...>with some older hardware, but I think it reflects pretty well the individual

> >>>>    resources per virtual server. The shows that Drupal can only handle 150
> >>>>    requests per second to anonomous users, and that's only with core modules.

> >>>>     - I also manage and made our blogs at Chronicleblogs.com which are

> >>>>    all wordpress based so I have some pretty extensive Wordpress experience, it
> >>>>    just doesn't have the power and flexibility of Drupal. It will be near
> >>>>    impossible to create a easy to manage and update frontpage like our current
> >>>>    demo at ocirs.com:99 on Wordpress let alone all the section pages
> >>>>    and extra multimedia features.

> >>>>     - I'll do a benchmark on my dorm computer when I get back to school

> >>>>    and forward your the results, but it won't reflect the fact that the
> >>>>    resources are being shared 4-5 ways.
>

> >>>>   On Thu, Jan 1, 2009 at 4:47 PM, Joey Baker <j...@byjoeybaker.com>wrote:
>
> >>>>> Sorry guys, just...
>
> read more »

[Zhuiyang [Dean] Chen]

Yes, MySQL's Query Cache is probably not the best way to cache Wordpress and Drupal because it is pretty "dumb" since it is at a such a low level. I mentioned it as an argument for increasing the amount of RAM in the server configuration since I don't believe it is enough for our purposes. There's a module for Drupal that will easily allow us to easily implement many cache systems including memcache, which is what we will end up using; MySQL query was just a simpler example for the purposes of the debate.

--

Dean

--
Dean Chen

[MaxCutler]

I'm the current webmaster of the Yale Daily News, and have many
thoughts on this topic. But my predecessor, Robert Baskin, caught wind
of this discussion and asked me to post a response on his behalf:

"I was the Online Director of the Yale Daily News until this past
October. The current one, Max Cutler, is also on this list, but I
thought I'd respond since I built the current iteration of the site
from scratch and can explain some of our decisions. As I wrote, I
realized that I've actually blogged about a lot that is relevant to
this topic - sorry for all the links.

The current version of the site is built on CakePHP. When I built the
site two years ago, I was most familiar with PHP, and even though
Rails was the new hotness back then I chose to stick with PHP but use
a framework for all of the advantages they provide. Cake is a bit
heavy, and we've struggled with performance. I've blogged about some
of what we did at our online blog - http://online.yaledailynews.com/

In particular, we've been aggressive in implementing various forms of
caching. I made five posts about it - http://online.yaledailynews.com/category/technical/caching/,
but I'll summarize here. MySQL query caching is in general a good
thing, but the cache is table-level, so if you make a change to any
row, the cache is invalidated. For example, we store the hitcount for
the articles in our articles table, so the query cache is invalidated
on every page when the hitcount is updated. MySQL query caching is not
enough to handle the kind of traffic spikes we see on a somewhat
regular basis (see http://online.yaledailynews.com/2008/04/25/the-day-the-music-died/)

For that, you'll need to implement at least data caching, and ideally
view caching. The industry standard is memcached. We use XCache, which
is a PHP memory cache, for reasons described in
http://online.yaledailynews.com/2008/08/24/caching-part-4-switching-to-memory/,
but I would recommend memcached if you're starting fresh.

With the performance improvements we've made, our system - which
supports comments, tags, multimedia (including video and audio), and
more - runs on a 2 gig slice at www.slicehost.com. We were on a
dedicated server, but switched to a VPS as I describe in
http://online.yaledailynews.com/2008/05/03/slice-and-dice/. Last
April, we hosted a conference for Ivy League newspapers to talk about
our online operations. All of us talked about the difficulty in
recruiting technical talent and the phenomenon where a competent and
motivated student comes along, does some good work, then graduates and
leaves behind a system that nobody understands or can maintain
effectively. For that reason, I must disagree with Dean on some things
here. For one thing, hardware is prone to breaking, and finding
somebody willing to maintain and support a colocated box will be
difficult if not impossible. Second, don't underrate the significance
of automated backups - if there's one thing I learned from interning
at Yahoo News, it's that simplifying the amount of system
administration required is clutch. Something always breaks - the rsync
command, the cronjob, the SSH key to the remote server - SOMETHING.

That all being said, we have been working on a replacement system that
may be of interest to CoPress soon. It's being custom-built on Django,
is even more fully featured than our current system, and is taking
full advantage of the lessons, performance and otherwise, we've
learned over the past several years. Stay tuned.

Robert Baskin"

I can weigh in further if there are any questions about how we handle
things at the Yale Daily News. But in general I think such discussions
are healthy, and I'm glad to see that CoPress is willing to talk about
such affairs publicly.

Max Cutler
Yale Daily News Webmaster
webm...@yaledailynews.com

On Jan 3, 4:46 pm, "Zhuiyang [Dean] Chen" <d...@ocirs.com> wrote:
> Yes, MySQL's Query Cache is probably not the best way to cache Wordpress and
> Drupal because it is pretty "dumb" since it is at a such a low level. I
> mentioned it as an argument for increasing the amount of RAM in the server
> configuration since I don't believe it is enough for our purposes. There's a
> module for Drupal that will easily allow us to easily implement many cache
> systems including memcache, which is what we will end up using; MySQL query
> was just a simpler example for the purposes of the debate.
>
> --
>
> Dean
>

> ...
>
> read more »

[codyv...@gmail.com]

I agree with Robert and Max -

You want to simplify your admin as much as possible - it's 'clutch'.
It's easy how it would seem ferocious to get some prodigious tech
undergrad to create some sort of custom platform, but they have a
shelf life graduation date and despite bragging rights you have to ask
whether worrying about the absolute basics of your news website
(hosting, platform) is the best use of your time. Really, when it
comes to a newspaper website what can a Django Custom do that
Wordpress 2.7 can't? What competitive advantage does a three person
tech team have over Wordpress's army of coders working incessantly to
make it better? Same applies to hosting. It's a cutthroat industry and
there are a lot of people who have to do it exceptionally well because
they are competing with someone else who is. Is it really worth
worrying about your own server?

One hosting company I can recommend with some gravity to CoPress is
Mosso. Mosso is cloud hosting, they are set up to host unlimited sites
on a single 'Cloud' without ever flinching. When NYU Local got linked
from Fark, we were getting 50 unique visitors every second, the speed
of the site remained snappy and fast.

When you take care of the basics you remove the headache and can get
your tech team to focus on more innovative plugins and projects.

Cody Brown

Publisher
www.nyulocal.com
www.tischfilmreview.com
www.codybrown.name

On Jan 3, 4:33 pm, MaxCutler <maxcut...@gmail.com> wrote:
> I'm the current webmaster of the Yale Daily News, and have many
> thoughts on this topic. But my predecessor, Robert Baskin, caught wind
> of this discussion and asked me to post a response on his behalf:
>
> "I was the Online Director of the Yale Daily News until this past
> October. The current one, Max Cutler, is also on this list, but I
> thought I'd respond since I built the current iteration of the site
> from scratch and can explain some of our decisions. As I wrote, I
> realized that I've actually blogged about a lot that is relevant to
> this topic - sorry for all the links.
>
> The current version of the site is built on CakePHP. When I built the
> site two years ago, I was most familiar with PHP, and even though
> Rails was the new hotness back then I chose to stick with PHP but use
> a framework for all of the advantages they provide. Cake is a bit
> heavy, and we've struggled with performance. I've blogged about some

> of what we did at our online blog -http://online.yaledailynews.com/

>
> In particular, we've been aggressive in implementing various forms of

> caching. I made five posts about it -http://online.yaledailynews.com/category/technical/caching/,

> but I'll summarize here. MySQL query caching is in general a good
> thing, but the cache is table-level, so if you make a change to any
> row, the cache is invalidated. For example, we store the hitcount for
> the articles in our articles table, so the query cache is invalidated
> on every page when the hitcount is updated. MySQL query caching is not
> enough to handle the kind of traffic spikes we see on a somewhat

> regular basis (seehttp://online.yaledailynews.com/2008/04/25/the-day-the-music-died/)

>
> For that, you'll need to implement at least data caching, and ideally
> view caching. The industry standard is memcached. We use XCache, which

> is a PHP memory cache, for reasons described inhttp://online.yaledailynews.com/2008/08/24/caching-part-4-switching-t...,

> but I would recommend memcached if you're starting fresh.
>
> With the performance improvements we've made, our system - which
> supports comments, tags, multimedia (including video and audio), and

> more - runs on a 2 gig slice atwww.slicehost.com. We were on a
> dedicated server, but switched to a VPS as I describe inhttp://online.yaledailynews.com/2008/05/03/slice-and-dice/. Last

> webmas...@yaledailynews.com

> read more »

[Joey Baker]

I've heard good things about Mosso too.

@Miles, et al… something to note down for if/when we eventually need it!

[blaloc...@gmail.com]

Vewd is on mosso. I can answer any questions we may have.


Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Joey Baker <jo...@copress.org>

Date: Sat, 3 Jan 2009 16:40:21
To: <cop...@googlegroups.com>
Subject: [CoPress] Re: Private thoughts from CoPress

[Zhuiyang [Dean] Chen]

Thanks Max(and Robert). The blog posts provided were pretty helpful, it seems that Drupal offers all the types of caching either built in or as a module so it seems we pretty much have our bases covered in that respect.

I mentioned earlier that we will most likely be looking to CoLo in a datacenter in Raleigh which is only about a 30 minute drive, so CoLo is better option for us than most. From personal experience the most part likely to fail is the hard drive. I figured a 4 drive raid 5 array with an spare drive should solve that concern for the most part, and replacing the faulty hard drive isn't very difficult. A redundant power supply should protect us against PSU failures. That leaves RAM, motherboard and processor. Ram is easily diagnosable and replaceable, I've never ran to a processor failing before, although the motherboard is harder to replace than most components, it's no rocket science either.

I also realize the benefits of automatic backup but it's also something that most organization can handle on their own since there's usually some time to troubleshoot the issue if something does go wrong. I would also feel a lot safer having the complete easily and quickly restorable backup in my hands. 

Since I haven't seen a benchmark of a fully optimized Drupal installation yet and seeing how much caching helped Yale Daily News, but at the same time, Drupal is definitely more resource intensive than a custom php CMS, so it's hard to say what sort of hardware requirements are necessary anymore. I'll try to do some premiminary testing on my computer when I get back to Duke on Wednesday and get back to you guys once I get some hard data on my hands.  If CoPress can handle the traffic I have no reservations about hosting the site there for the forseable future. But I'm still very concerned about the amout of RAM on the system which works out to be less than 1GB per site since the effectiveness of caching will heavily depend on the available RAM.

--

Dean

--
Dean Chen

[Joey Baker]

@Dean — fair point on the less than 1GB per site.

@Miles — That's certainly something we ought pay attention to.

[Miles Skorpen]

The Gazette is bigger than the Whit and the F News Magazine. We use
less than 750mb of RAM, though we are on Django. My impression was
that WP would use less, not more, RAM than a django system.

Miles

[Joey Baker]

That's my understanding/reading as well. Good to have data points to
back this up! :)

[David Estes]

We have 1.5GB RAM and a single 80GB hard drive at the UW Daily, with
Django running on Apache using mod_python, and memcached running on
the same machine. Some manual tweaks were required when Fark linked to
us, and more hardware would certainly be nice, but we've been fine so
far.

Personally, I think the CoPress server is more than enough for four
PHP-powered medium-sized papers, as long as caching is set up properly
to handle traffic spikes.

- David

> >> On Sat, Jan 3, 2009 at 6:33 PM, MaxCutler <maxcut...@gmail.com>  

> >> wrote:
>
> >> I'm the current webmaster of the Yale Daily News, and have many
> >> thoughts on this topic. But my predecessor, Robert Baskin, caught  
> >> wind
> >> of this discussion and asked me to post a response on his behalf:
>
> >> "I was the Online Director of the Yale Daily News until this past
> >> October. The current one, Max Cutler, is also on this list, but I
> >> thought I'd respond since I built the current iteration of the site
> >> from scratch and can explain some of our decisions. As I wrote, I
> >> realized that I've actually blogged about a lot that is relevant to
> >> this topic - sorry for all the links.
>
> >> The current version of the site is built on CakePHP. When I built the
> >> site two years ago, I was most familiar with PHP, and even though
> >> Rails was the new hotness back then I chose to stick with PHP but use
> >> a framework for all of the advantages they provide. Cake is a bit
> >> heavy, and we've struggled with performance. I've blogged about some

> >> of what we did at our online blog -http://online.yaledailynews.com/

>
> >> In particular, we've been aggressive in implementing various forms of

> >> caching. I made five posts about it -http://online.yaledailynews.com/category/technical/caching/

> >> ,
> >> but I'll summarize here. MySQL query caching is in general a good
> >> thing, but the cache is table-level, so if you make a change to any
> >> row, the cache is invalidated. For example, we store the hitcount for
> >> the articles in our articles table, so the query cache is invalidated
> >> on every page when the hitcount is updated. MySQL query caching is  
> >> not
> >> enough to handle the kind of traffic spikes we see on a somewhat

> >> regular basis (seehttp://online.yaledailynews.com/2008/04/25/the-day-the-music-died/)

>
> >> For that, you'll need to implement at least data caching, and ideally
> >> view caching. The industry standard is memcached. We use XCache,  
> >> which
> >> is a PHP memory cache, for reasons described in

> >>http://online.yaledailynews.com/2008/08/24/caching-part-4-switching-t...

> >> ,
> >> but I would recommend memcached if you're starting fresh.
>
> >> With the performance improvements we've made, our system - which
> >> supports comments, tags, multimedia (including video and audio), and

> >> more - runs on a 2 gig slice atwww.slicehost.com. We were on a

> >> webmas...@yaledailynews.com

> >> > > >    Wordpress has a much simpler...
>
> read more »

[Greg Linch]

This discussion is hardcore. That is all.

Greg

[Melinda Bardon]

Totally agreed.

--
Melinda Bardon
Portland State Vanguard
Online Editor
cell: 503.784.7249
office: 503.725.3883

[Joey Baker]

Perfect! We need more data!

@David — that's precisiy the kind of data we need!

Everyone else — if you're running a server right now, what are the specks? How do they compare to what we're offering at CoPress?

[Daniel Bachhuber]

@Joey, it would be sweet to dump this into a spreadsheet.... Might be
valuable research for CoPress to do

[Zhuiyang [Dean] Chen]

Hey Miles, what is the level of caching for the Gazette, are you guys using memcache or a similar system? And does that number apply to idle, average or peak times? Both those factors can have quite an impact on RAM usage.

The demo site at ocirs.com:99 is utilitzing about 730MB of RAM and that's with a beta version of Windows 7 I was playing around with as my desktop OS, no RAM caching, no other apps running and some of the modules disabled. There is too many factors in play in my case but I think we are going to easily approach 1GB when things are said and done under a production enviroment.

Even using what I believe a somewhat conservative 700MB estimate, with 5 servers that still adds up to 3.5GB and don't forget about the VPS overhead; there's just not enough headroom left.

I also understand that some sites are smaller than our's and will not be using a fully loaded drupal installation and may not need that much resources; $65 is definitely a sweet spot for many smaller organizations. However, if you guys would consider offering a more expensive package(doesn't have to be public since one price point definitely simplifies things) with more RAM(2GB+), we will gladly pay the premium, even if it just means I sleep better at night.

--

Dean 

--
Dean Chen

[Zhuiyang [Dean] Chen]

Great idea Daniel, a shared google doc spreadsheet where everyone can input their specs would be a nice thing to see.

--

Dean

--
Dean Chen

[Dean]

By the way, I don't know what you guy's launch time line is, but I
don't think we'll launch at least for another 2 months, although I'm
fine with commiting to CoPress and paying for the $125 setup fee way
before then.

--
Dean

> > >>> On Sat, Jan 3, 2009 at 6:33 PM, MaxCutler <maxcut...@gmail.com>

> > >>> wrote:
>
> > >>> I'm the current webmaster of the Yale Daily News, and have many
> > >>> thoughts on this topic. But my predecessor, Robert Baskin, caught
> > >>> wind
> > >>> of this discussion and asked me to post a response on his behalf:
>
> > >>> "I was the Online Director of the Yale Daily News until this past
> > >>> October. The current one, Max Cutler, is also on this list, but I
> > >>> thought I'd respond since I built the current iteration of the site
> > >>> from scratch and can explain some of our decisions. As I wrote, I
> > >>> realized that I've actually blogged about a lot that is relevant to
> > >>> this topic - sorry for all the links.
>
> > >>> The current version of the site is built on CakePHP. When I built
> > >>> the
> > >>> site two years ago, I was most familiar with PHP, and even though
> > >>> Rails was the new hotness back then I chose to stick with PHP but
> > >>> use
> > >>> a framework for all of the advantages they provide. Cake is a bit
> > >>> heavy, and we've struggled with performance. I've blogged about some

> > >>> of what we did at our online blog -http://online.yaledailynews.com/

>
> > >>> In particular, we've been aggressive in implementing various forms
> > >>> of
> > >>> caching. I made five posts about it -
> >http://online.yaledailynews.com/category/technical/caching/
> > >>> ,
> > >>> but I'll summarize here. MySQL query caching is in general a good
> > >>> thing, but the cache is table-level, so if you make a change to any
> > >>> row, the cache is invalidated. For example, we store the hitcount
> > >>> for
> > >>> the articles in our articles table, so the query cache is
> > >>> invalidated
> > >>> on every page when the hitcount is updated. MySQL query caching is
> > >>> not
> > >>> enough to handle the kind of traffic spikes we see on a somewhat
> > >>> regular basis (see
> >http://online.yaledailynews.com/2008/04/25/the-day-the-music-died/)
>
> > >>> For that, you'll need to implement at least data caching, and
> > >>> ideally
> > >>> view caching. The industry standard is memcached. We use XCache,
> > >>> which
> > >>> is a PHP memory cache, for reasons described in
>

> >http://online.yaledailynews.com/2008/08/24/caching-part-4-switching-t...

> > >>> ,
> > >>> but I would recommend memcached if you're starting fresh.
>
> > >>> With the performance improvements we've made, our system - which
> > >>> supports comments, tags, multimedia (including video and audio), and

> > >>> more - runs on a 2 gig slice atwww.slicehost.com. We were on a

> > >>> webmas...@yaledailynews.com

> ...
>
> read more »

[David Estes]

I think MySQL, Apache, and PHP have higher memory usage under Windows,
and their behavior under a pre-beta OS will be entirely unpredictable.
Try setting up Debian or something similarly stripped-down, and you'd
probably see very different usage. Additionally, memory allocation is
tricky, and free memory is wasted memory, so processes will often seem
to allocate much more than they actually need.

It might be helpful to set up a VMWare image configured similarly to
the CoPress server. This would be slower than the actual server, but
then we can test with different amounts of RAM, locally simulate a DoS
attack against it, and get a general estimate of how Drupal performs
against Wordpress.

- David

On Jan 3, 9:16 pm, "Zhuiyang [Dean] Chen" <d...@ocirs.com> wrote:
> Hey Miles, what is the level of caching for the Gazette, are you guys using
> memcache or a similar system? And does that number apply to idle, average or
> peak times? Both those factors can have quite an impact on RAM usage.
>
> The demo site at ocirs.com:99 is utilitzing about 730MB of RAM and that's
> with a beta version of Windows 7 I was playing around with as my desktop OS,
> no RAM caching, no other apps running and some of the modules disabled.
> There is too many factors in play in my case but I think we are going to
> easily approach 1GB when things are said and done under a production
> enviroment.
>
> Even using what I believe a somewhat conservative 700MB estimate, with 5
> servers that still adds up to 3.5GB and don't forget about the VPS overhead;
> there's just not enough headroom left.
>
> I also understand that some sites are smaller than our's and will not be
> using a fully loaded drupal installation and may not need that much
> resources; $65 is definitely a sweet spot for many smaller organizations.
> However, if you guys would consider offering a more expensive
> package(doesn't have to be public since one price point definitely
> simplifies things) with more RAM(2GB+), we will gladly pay the premium, even
> if it just means I sleep better at night.
>
> --
>
> Dean
>

> > >>> On Sat, Jan 3, 2009 at 6:33 PM, MaxCutler <maxcut...@gmail.com>

> > >>> wrote:
>
> > >>> I'm the current webmaster of the Yale Daily News, and have many
> > >>> thoughts on this topic. But my predecessor, Robert Baskin, caught
> > >>> wind
> > >>> of this discussion and asked me to post a response on his behalf:
>
> > >>> "I was the Online Director of the Yale Daily News until this past
> > >>> October. The current one, Max Cutler, is also on this list, but I
> > >>> thought I'd respond since I built the current iteration of the site
> > >>> from scratch and can explain some of our decisions. As I wrote, I
> > >>> realized that I've actually blogged about a lot that is relevant to
> > >>> this topic - sorry for all the links.
>
> > >>> The current version of the site is built on CakePHP. When I built
> > >>> the
> > >>> site two years ago, I was most familiar with PHP, and even though
> > >>> Rails was the new hotness back then I chose to stick with PHP but
> > >>> use
> > >>> a framework for all of the advantages they provide. Cake is a bit
> > >>> heavy, and we've struggled with performance. I've blogged about some

> > >>> of what we did at our online blog -http://online.yaledailynews.com/

>
> > >>> In particular, we've been aggressive in implementing various forms
> > >>> of
> > >>> caching. I made five posts about it -
> >http://online.yaledailynews.com/category/technical/caching/
> > >>> ,
> > >>> but I'll summarize here. MySQL query caching is in general a good
> > >>> thing, but the cache is table-level, so if you make a change to any
> > >>> row, the cache is invalidated. For example, we store the hitcount
> > >>> for
> > >>> the articles in our articles table, so the query cache is
> > >>> invalidated
> > >>> on every page when the hitcount is updated. MySQL query caching is
> > >>> not
> > >>> enough to handle the kind of traffic spikes we see on a somewhat
> > >>> regular basis (see
> >http://online.yaledailynews.com/2008/04/25/the-day-the-music-died/)
>
> > >>> For that, you'll need to implement at least data caching, and
> > >>> ideally
> > >>> view caching. The industry standard is memcached. We use XCache,
> > >>> which
> > >>> is a PHP memory cache, for reasons described in
>

> >http://online.yaledailynews.com/2008/08/24/caching-part-4-switching-t...

> > >>> ,
> > >>> but I would recommend memcached if you're starting fresh.
>
> > >>> With the performance improvements we've made, our system - which
> > >>> supports comments, tags, multimedia (including video and audio), and

> > >>> more - runs on a 2 gig slice atwww.slicehost.com. We were on a

> > >>> webmas...@yaledailynews.com

> > >>> recommend...
>
> read more »

[Zhuiyang [Dean] Chen]

Yeah, it's my development machine at home, will setup a couple of CentOS VMs on my server 2008 workstation when I get back to school on Tuesday. The specs are slightly higher, Q9450@3.2, 3x640GB RAID5, but running it under VM should even things out, there is also 8GB of ram to work with.

Since I'm by no means a Wordpress expert, if anyone haas a preconfigured VMWare image with a realistic wordpress configuration and can throw up on a webserver somewhere, I can download it and load it up and give you remote access to test it.

--
Dean

--
Dean Chen

[Miles Skorpen]

Also ... an interesting note. The Gazette is actually running with
only 200MB of RAM. We're small, but we are getting ~23,000 page views/
week.
As for the multiple price points—they'll come when we have enough
users for it to be reasonable.

Miles

[Rick Martinez]

My turn to join in :>

In my opinion, in this age of virtualization, is colocating or even
having a ded server really necessary? At FIUSM.com we're doing about
3,000 page views a day and we run off the lowest priced Linode. We
use PostgreSQL and Ruby on Rails with Litespeed as our httpd. Our
current version is hardly cached and it runs pretty well (it was
rushed, a lot of politics, now we're launching a much better version
this weekend with view and data caching).

I agree with Max that query caching isn't exactly the holy speed
solution, what you want to do is cache your data and views, and I mean
cache *everything.* I worked at a company that cached their home page
statically (yes, generated an index.html) because the only dynamic
information on there was a "Welcome, user" or "You are not logged in!"
and that information was easily accessible by a little AJAX.

Also, for me control is very important, especially when press can
spark up at any time. Say a D-I AA team upsets a ranked team, another
"Don't taze me, bro," etc. I love Linode because I do get the price
of "shared hosting" but it's well virtualized with Xen and I have
control even over the kernel. I don't know how many security experts
there are at CoPress but locking down shared hosting is difficult to
do comfortably for the user. Also, managing servers can be a bitch.
If we were just reselling and preparing virtualized solutions, we
wouldn't have the responsibility of dealing with a tiny little bug
that will crash 6-10 newspapers' websites.

It's not expensive to serve caches. Complicated logic and intense
queries are. You program smart, you avoid all that, and you can run
your website off your grandmother's computer.

Best,
Rick

On Jan 4, 12:55 pm, Miles Skorpen <ara...@gmail.com> wrote:
> Also ... an interesting note. The Gazette is actually running with  
> only 200MB of RAM.  We're small, but we are getting ~23,000 page views/
> week.
> As for the multiple price points—they'll come when we have enough  
> users for it to be reasonable.
>
> Miles
>
> On Jan 4, 2009, at 01:13 , Zhuiyang [Dean] Chen wrote:
>
> > Yeah, it's my development machine at home, will setup a couple of  
> > CentOS VMs on my server 2008 workstation when I get back to school  

> > on Tuesday. The specs are slightly higher, Q9...@3.2, 3x640GB RAID5,  

> > but running it under VM should even things out, there is also 8GB of  
> > ram to work with.
>
> > Since I'm by no means a Wordpress expert, if anyone haas a  
> > preconfigured VMWare image with a realistic wordpress configuration  
> > and can throw up on a webserver somewhere, I can download it and  
> > load it up and give you remote access to test it.
>
> > --
> > Dean
>

> > On Sun, Jan 4, 2009 at 12:56 AM, David Estes <david.es...@gmail.com>  

> > > > >>> leaves behind a system that nobody...
>
> read more »

[Joey]

Hey ya'll — not to bring up old news, but:

My brother, Phill, who I defer to on all technical matters above my
level of understanding

Had the following to say:

See (for example) http://groups.drupal.org/node/15663 as an example of
the work/talk that is out there about drupal and high performance/
uptime requirements.

–Joey

On Jan 3, 9:18 pm, "Zhuiyang [Dean] Chen" <d...@ocirs.com> wrote:
> Great idea Daniel, a shared google doc spreadsheet where everyone can input
> their specs would be a nice thing to see.
>
> --
>
> Dean
>

> On Sun, Jan 4, 2009 at 12:11 AM, Daniel Bachhuber <danielbachhu...@gmail.com

>
> > wrote:
>
> > @Joey, it would be sweet to dump this into a spreadsheet.... Might be
> > valuable research for CoPress to do
>

> > On Sat, Jan 3, 2009 at 9:03 PM, Joey Baker <j...@copress.org> wrote:
> > > Perfect! We need more data!
> > > @David — that's precisiy the kind of data we need!
> > > Everyone else — if you're running a server right now, what are the
> > specks?
> > > How do they compare to what we're offering at CoPress?
> > > On Jan 3, 2009, at 8:54 PM, Greg Linch wrote:
>
> > > This discussion is hardcore. That is all.
>
> > > Greg
>

> > >> >>> On Sat, Jan 3, 2009 at 6:33 PM, MaxCutler <maxcut...@gmail.com>

> >http://online.yaledailynews.com/2008/08/24/caching-part-4-switching-t...

> > >> >>> ,
> > >> >>> but I would recommend memcached if you're starting fresh.
>
> > >> >>> With the performance improvements we've made, our system - which
> > >> >>> supports comments, tags, multimedia (including video and audio), and

> > >> >>> more - runs on a 2 gig slice atwww.slicehost.com. We were on a

> > >> >>> webmas...@yaledailynews.com

> ...
>
> read more »