notifications user threshold
| Project: | Notifications |
| Version: | 6.x-2.0-beta6 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Hi guys, im currently in the middle of migrating a site to drupal. The client has previously sent a newsletter of all new content out to 12,000 addresses in the past, but is now wanting to give users an option to modify what content they receive (woo! go notifications module!).
So i've gone through and implemented a bunch of stuff relating to this module, and am now at the point of importing all the email addresses into drupal and setting up the default subscription (to all taxonomy terms and content types). Although, in my script, subscribing each user to every term and content type (160 terms and 13 content types) is taking around 4 seconds per user. thats a pretty long time when you need to get 12000 users into the database.
But it has got me wondering. When creating nodes, how long will calculating the queue take each time? I'll do some testing, but I'm seriously considering re-pitching the mailout situation to the client... which sucks.
Have you guys got any thoughts to how i can configure the module scale to a site with that many users? or are my fears unfounded?
#1
I'm running a site with ~7000 users and, on the whole, find it scales well. You can define queue processing limits per cron run to fit your server resources. The one thing I would point out as a potential pitfall is a problem with inline images that I have described here: http://drupal.org/node/445190.
#2
The queue is calculated in a single query which so far is up to the task for many thousand users. This is running on sites like groups.drupal.org.
However, if at some point we find it is too slow and cannot we done on page request, the b-plan is moving it to cron processing. So I'm really interested if you have some performance reports for us.
About the subscriptions, if you subscribe users to all content types then there's no need to subscribe them to taxonomy terms too, you can save that part which will result in some query conditions saved, thus faster. Also you may not need the taxonomy subscriptions module at all, again less conditions thrown into the query.
However for this specific use case (subscribe everybody to everything) you'd be better off creating some plug-in with that custom subscription type.