Very generic performance question

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
djudd's picture

On September 1st I will be rolling out our new website, which is a Drupal 6.13 engine, to replace our existing site.

I'm using the normal goodies, Views, Panels, Organic Groups, SimpleNews, Advertising, etc... Our site currently does about 8,000 unique visitors a day, and about 1 million page views a month. So it's not exactly a "high performance" site, but it takes some traffic.

I will be using a GoDaddy dedicated server package when we go live, since we just don't have the budget for traffic shapers, load balancers, dedicated lines, etc...

How bad am I going to get hammered here? Do I need to start looking into modules like Boost? Do I need to focus some early attention on Views caching? Just curious as to what I should expect early on, so that we don't get floored day 1.

Thanks for any tips anyone can give me.

Comments

Biggest Consideration

kwinters's picture

The biggest consideration is whether traffic is mostly anonymous or logged in. Anonymous traffic scales very well automatically, and you get get a whole lot more out of it if you have something like APC installed (I think this is common on this kind of environment).

In your list, organic groups is the only real processor hog.

Ken Winters

www.coalmarch.com

Ken Winters

In your list, organic groups

moshe weitzman's picture

In your list, organic groups is the only real processor hog.

What part of OG exactly? We don't know anything about this site such as whether it uses access control, has lots of groups with several members, lots of members in a few groups, and so on. It is a bit annoying to have to retort uninformed replies like this.

OG has an inherently high

kwinters's picture

OG has an inherently high percentage of users that are authenticated, and the authenticated user experience is something like an order of magnitude more work for the server than cached anonymous content.

Unless you want to talk about the definition / degree of "hog" I don't think my statement is unreasonable.

Ken Winters

www.coalmarch.com

Ken Winters

Moshe, I don't think OG will

djudd's picture

Moshe,

I don't think OG will be a very highly used function of our site, but I really don't know yet either.

In the past, we've done absolutely nothing with social networking. I've incorporated the ability for our registered users (again, another new feature of our website) to create discussion groups with a hosted file repository, an event calendar, and the ability to assign ranks to their users.

But this is all new. We're a small community newspaper in a town of about 45,000 people, and we don't expect a lot of traffic outside of our home area.

I wish I could be more specific in terms of what our users will be doing, but this is all new ground for us. I believe that in order for a community newspaper to bring the community together, social networking has got to be a part of what we do online, but no one has tested this out in our market yet, so there are no metrics from which to sample.

I'm less concerned about the performance of OG than I am Views to be honest, because of the amount of data Views will populate, and the fact that it's presenting our stories, which are the most used portion of our site by far.

Number of groups? Don't know. We are hoping the local church groups, quilting clubs, etc... might make use of these features, but there's no way to tell for sure yet. Members? Most likely a limited number of our unique visitors, I'd say a few hundred tops.

From everything I've seen so far, OG performs nicely in our type of environment, so I'm not overly concerned there.

Yeah, same thing happened to

heshanlk's picture

Yeah, same thing happened to me,
I used Boost, it helped me to reduce load average, so for anonymous users Boost will be the solution, its light weight(I guess).

APC will help you to use Opcode caching. 10-20% performance boost.

But if you use panels and Views, it will create a considerable overhead on the Database server, cause in the my case so many filesorts, so its making a big overhead on the Database server (Checked with explain command).

Hope this note will helpful.

-Heshan

Senior Drupal Developer at DrupalConnect

filesorts should not be blamed on views

catch's picture

If you write queries which cause filesorts, they'll cause filesorts whether you write them by hand or via the Views interface. The only exception to this is if you're very competent with SQL and able to fine tune queries and indexes (and probably generate denormalised tables for some things) yourself. In 90% of cases you're better off using quick wins like caching views, than trying to recreate complex views queries by hand and optimize them (or paying someone else to do so) - this is definitely the case on a 1 million page views/month site.