How to handle 400 000 users ?

Tuesday 28 June 2011 12:35:30 am

Hello,

I want to handle authentication of 400 000 users in eZ Publish. Do you think that so many users can be a problem for eZ Publish content engine ? 

I have a webservice to handle authentication. So no problem to use it with a login handler but can I tweak the process so that I don't need to actually store users in eZ Publish ?

I was thinking of creating one user for everyone and tell eZ that this user is connected but I'm not sure it will do it : what happen if one of them disconnect ? can eZ handle multiple connection of the same user ? 

Thanks for your help !

--
eZ certified developer: http://ez.no/certification/verify/346216

Tuesday 28 June 2011 1:22:55 am

Great, no performance problems ?

--
eZ certified developer: http://ez.no/certification/verify/346216

Tuesday 28 June 2011 1:31:20 am

There is an anonymous user for all the anonymous sessions. Maybe you can do something similar with one special user if you don't want to have 400k users in the database. If you would add 400k users to the db try not to add them all under the same group...

http://www.linkedin.com/in/ivolukac
http://www.netgen.hr/eng/blog
http://twitter.com/ilukac

Tuesday 28 June 2011 1:47:00 am

500k users is not really a pain point per se. But it can be if

• you have very big user profile class
• you have very complex roles and permissions assignments

As Ivo says, you could "trick" eZ by storing in the eZ content db one user per group, and storing in the user session data at runtime the "actual user id from external system", then use that info for applying your customizations in template / php code.

I would not go down that path with a light heart though, as I've seen a few implementations where this had been done and

• a lot of time was spent on it before getting it to work
• lot of security problems were in the custom code (but hey, that's what audits are for ;-) )
• performances were not good anyway in the end (eg. custom session code doing ws calls to backoffice authentication server one or more times per page, authentication server slowing down whole site under load...)

Principal Consultant International Business
Member of the Community Project Board

Tuesday 28 June 2011 2:03:04 am

Ok that's a VERY interesting feedback !

--
eZ certified developer: http://ez.no/certification/verify/346216

Tuesday 28 June 2011 5:09:11 am

Another tip...

Don't use per user view cache. This is actually already disabled by default but just to let you know.

For the parts where you need to display some contect specific for a user, use ajax calls like for example here on share.ez.no.

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Tuesday 28 June 2011 5:31:02 am

Lets say you have 500 pages * 400000 user = 200 000 000 files on disk, that is why :) in that case it would be even better to disable view cache and use some cache-blocks where possible

http://www.linkedin.com/in/ivolukac
http://www.netgen.hr/eng/blog
http://twitter.com/ilukac

Tuesday 28 June 2011 6:42:02 am

To clarify a bit about cache:

1. view cache generates one file on disk per object per user-group per-view-parameters. Not one per-user

so if you have 500k users in 50 groups, it's not so bad

2. cache blocks: here you decide the keys (one file stored per combination of keys used). Putting in the keys the node_id + curent user user_id is a horrible idea even with a few hundred users...

Principal Consultant International Business
Member of the Community Project Board

Tuesday 28 June 2011 7:10:36 am

This is an option, but i don't feel comfortable depending on AJAX for showing this or that content to a logged user. better than use cache per user, sure, but still i don't like it. 

sometimes i said to some ez crew members how good it could be a template tag like

{do-not-cache-this}
{* code *}
{/do-not-cache-this}

specially thinking about the inclusion of voting actions or per-user generated content without the need of javascript.

So, even having view caches enabled, that cache file could still have some php code to do some specific stuff. but unfortunately it's not possible (afaik) thinking in how ez publish works with this. 

Fortunately this seems to be possible with zeta components though :)

Cheers. 

Tuesday 28 June 2011 7:40:17 am

What's the problem with using ajax calls for this parts? It's a very common technique on all big sites.

{do-not-cache-this}
{* code *}
{/do-not-cache-this}

First I would suggest you to take a look at varnish, ezsi and ESI or SSI.

Second, on one site I have played with something that could be useful to you... a way to include, execute and cache just small pieces of your code, one at the time and include them via ESI or SSI. This approach would suit more your "per user" needs since it allows you to pass custom parameter to the code, which can also be used to generate different output for different users. I haven't yet used it in the way you would need it, but I supose it could be used for yur purpose.

If you're intersted, the approach is described here:

• http://share.ez.no/blogs/marko-zmak/when-ezsi-doesn-t-do-it

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth