I'm curious to get people's opinion's on how content profile works with lots of users.

The site I'm building will have 250,000 users. How would Drupal hold comparing using content_profile vs. Profile module. I've got a bunch of demographic info that needs collecting. In profile module I'd have to use about 100 check box fields. In content_profile I'd be able to simply use a multi-select taxonomy. In addiiton to this there are about 12 other text fields that would either be in the content_profile or Profile module.

The issue here is performance. [We'll be able to follow the standard procedures for scaling large sites like setting up master/slave and using memecache etc. Here I'm asking about the relative difference on load/ other server issues to applying these different approaches.0

Note, there will be one other node type that will have about 1,000,000 records.

Thanks,

Shai

Comments

loze’s picture

I'm interested in this too.
I'm working on a similarly sized site and concerned about performance with a large amount of content_profile nodes.

gausarts’s picture

subscribing, thanks

dnewkerk’s picture

Also subscribing... I have a large site as well and am curious about the performance of using content profiles for so many users.

aspope’s picture

Subscribing. I am in the same boat (well I hope to be, if the project takes off!)

NikLP’s picture

User profiles via the content_profile module are really no more expensive than traditional profiles in Drupal, to the best of my knowledge.

Aside from the fact that they are more versatile, profile, is bad, and fields are in core for D7, you really should have no worries with using content_profile for lots of users. I myself am in the middle of a 40,000 user site (not complete) that we don't anticipate problems with.

The only area where you will (currently, definitely) face any problems is in the area of registration, and very specific use cases, which may not be catered to as yet.

I've recently sponsored some work on content_profile_registration which makes things easier, but I'm waiting for more work on that and some on the autoassignrole module as well, which is another key component of such a system. auto_nodetitle appears to work fine now, however.

Hope that helps.

Web Development in Nottingham, UK by Kineta Systems / Follow me on Twitter! @NikLP

tryitonce’s picture

As I am researching the holy grail of Content Profile Module vs. content_profile (Drupal Core - Drupal 6.x) I came across this discussion in Drupal Groups - http://groups.drupal.org/node/22471 - How many nodes can Drupal handle?

Well, there are obviously limits to Drupal - but then it might be a long way to that point.

The more important point to me & my projects is the future in Drupal and with Drupal 7 including fields in core it might be worth waiting. Though, I started on Drupal 6.2 or so and soon realised how long it will take to be able to upgrade as modules have to be ready for real life use first.

Once my research has moved towards a conclusion I shall come back and comment. If not do remind me.

................

tryitonce’s picture

A first result - see this discussion - http://drupal.org/node/472192 - no more profile module (Core D6) in Drupal7? What then?

Still researching more ....

ari-meetai’s picture

I'm happy this doesn't make to D7. We'll have a true all-node framework then.. :)

artatac’s picture

I am still unclear what the additional benefits are to using this module rather that Profile in core?

Thanks

Joe

NikLP’s picture

Profile module is crap. You can't add CCK fields. You can't integrate it with Views. It sucks, it's dead, good riddance.

dnewkerk’s picture

@NikLP: Just for clarification... Views 2 "does" integrate completely with Profile module. You have access to all profile fields/data. With a little effort you can create Views-generated blocks to show fields/data from core profiles. While you can't add CCK fields of course, you can add a variety of other fields that are sufficient in various cases. Since in my case profiles are generally more of a place where a user's various data from their interactions on the site is collected together and displayed using Views (as compared to just using regular profile data and theming it in the template), I've made quite advanced profiles using core Profile based Views blocks, as well as various other node/comment Views blocks that all appear on the user's profile page together. All Views blocks of course carry a user argument to cause them to load the correct user data.

To my knowledge Profile module will still be in D7, although if users can have "fields" in the same form many elements in D7 will, then it would make working with Profile a more unified experience similar to working with nodes and other data. Users/profiles will not "be" nodes though. The current Profile module does store data in a questionable format that's hard to work with (though so long as you query it with Views it bypasses some of that).

NikLP’s picture

AFAIK in D7 user can "have fields", as can terms, comments etc. I believe, so the concept of a profile module is AFAICT pretty much redundant.

That's not going to help anyone stuck with a D5/6 site tho! :)

tryitonce’s picture

So, what should you do about developing your user profile?

Answers - in an <ol>

  1. It depends (says your lawyer) on what you want to achieve.
  2. If you are looking for simple user registration and a few simple functions like here in this site - I would think core Profile_Module is fine. You can have lots of data about your user and do some fancy layouts.
  3. If you need some more clever functions, relationships, lots of reporting (views) of and for your users - then you probably are more flexible and have more whistles and bells with the contributed Content_Profile and the Advanced addition for it.
  4. Upgrade to D7 - well not clear - though - see http://drupal.org/node/472192 - both options should get you there safely - eventually.
  5. When?!? - this question would also be relevant to answer. When would you migrate from D5 or D6 to D7?
  6. would you migrate from D5 to D6 now or should you wait for D7. That might another threat - but if you need certain features only D6 has and you need them soon (next 6-12 months) your best option would be to move to D6. If you can wait - start playing with D7.
    1. Well, when all the modules you need are ready? - Hardly before.
    2. When you had time to experiment with D7? - Absolutely!
    3. When you are convinced there are real benefits in moving on? - Being sensible - unless you feel you need to show of a flashy new D7 down the Kings Road of the internet.
    4. When there is no more support for D5? - Surely, if not you might have missed the boat. By then you should be at least up to playing with D7.
    5. When there is no more support for D6? - Will that be before my retirement?
  7. My guess is that sensible people will move there sites on when the conditions a,b,c are met.
  8. To wait until support ends for D5/D6 may only be an option for sites that are low on module use and are just working great as they are - not broken - don't fix it! This might even be a reason not to move at all.
  9. Considering how long it took to get modules into a proper D6 production site stage - D7 is at least a year off for more demanding sites - especially with sophisticated user networking (=profile) requirements (- probably even 18 months).
  10. I expect for my projects (all in D6) a move to D7 not before another 2 years and I expect to start playing with D7 for some new projects in a years time on a more serious basis.
  11. Well, that is the view of someone looking at Drupal from how it would work for the business - not from the point of technology, coding, features, etc.
  12. Finally, I decided to go for the contributed Content_Module with the advanced add-ons - and are still looking for a really good guide into the maze of CCK, Views, Panels and the lot. At least I am progressing.
  13. And to come back to the starting question here - for my "big" member site I am calculating with not more than 20,000 users - so, with Drupal.org just gone through the 500,000 nodes mark - there should be no problem.

So, at least I came back and added my conclusion - good luck and thanks to all the helpers here and especially those reporting back with their conclusions and solutions.

mohamed_e’s picture

Thanks! Helpful summary!