Share » Forums » Developer » How to handle 400 000 users ?

How to handle 400 000 users ?

How to handle 400 000 users ?

Tuesday 28 June 2011 12:35:30 am - 23 replies

Author Message

Carlos Revillo

Tuesday 28 June 2011 11:46:32 am

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:

Thanks Marko. also tried to work on that, but still wasn't what i was looking for. your examples, if i'm not wrong, still generates html static files loaded after when requested. ya, i think it can work for 'most viewed pages' or things like that. but what i would like is to add in my templates some code to know if my user is logged or not. yes, i know there's a function for that, but if you have viewcache for those pages.

i thinking in cases, let's say galleries of photos that can be voted only once per user. still the ajax approach is good, but it requires javascript. you may say "who is not using javascript" yes, but still i'd like to add the posibility to work without it.

so, suppose this photo node i'm talking about where you have your related photos, the info about the photo, the geolocation of the photo and so on. if we had something to have all the page cached by viewcache, except some parts for checking if the user is logged or not, or something like that, i think it could be great.

but as said before, i've tried to work on that and no results. and after receiving some advices from eZ Crew people, i just gave up :)

Carlos Revillo

Tuesday 28 June 2011 11:57:15 am

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

I forgot this part. well, this is probably because some years ago i was more focused on developing sites that should pass accessibility tests. supposedly, if the site was paid by public money it needed to to pass the AA level, because as it was using public money, everybody should use the site. as you may know, one of the parts is that you cannot rely on javascripts and other technologies if you don't offer an alternative.

so, thinking about ez publish and ezstarrating, ok, ezstarrating is a form with some radiobuttons converted to those nice starts for clicking.

if a user doesn't use javascript (probably because of his browser) he can vote with the radio buttons. but if the page is using viewcaching, you cannot control if he has voted or not again...

so, don't get me wrong. i like ajax stuff. but it's just it should have always an alternative without the need of it. 

Cheers.

Marko Žmak

Tuesday 28 June 2011 12:50:51 pm

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

I forgot this part. well, this is probably because some years ago i was more focused on developing sites that should pass accessibility tests. supposedly, if the site was paid by public money it needed to to pass the AA level, because as it was using public money, everybody should use the site. as you may know, one of the parts is that you cannot rely on javascripts and other technologies if you don't offer an alternative.

so, thinking about ez publish and ezstarrating, ok, ezstarrating is a form with some radiobuttons converted to those nice starts for clicking.

if a user doesn't use javascript (probably because of his browser) he can vote with the radio buttons. but if the page is using viewcaching, you cannot control if he has voted or not again...

so, don't get me wrong. i like ajax stuff. but it's just it should have always an alternative without the need of it. 

I really understand your points, I'm also always trying to preserve non JS backwards compatibility as much as I can. But the fact is that today JS is almost a standard for all sites and soon there will not be a single site that doesn't rely on it. For example...

  • on cnn.com you cannot log in without JavaScript.
  • on usa.gov, several parts of site don't work if you don't have JS enabled (especially "contact us", "chat" or "FAQ").
  • on education.gov.uk the main menu and "increase contrast" don't work without JS

And interesting thing, if you look at share.ez.no without JS, it's only readonly mode for you... :)

And there's another point... If you think in terms of fbconnect, your server cannot always found out if the current visitor is logged in into FB or not, but jour JS can.

As much as I would also like all sites to have a full backwards compatibility with non JS browsers, this is something will have to leave to the past and full JS browsers should become a standard for all web.

In my opinion the things that shouldn't rely on JS are:

  • content - all content should be available without JS. Not only because of 1% of non JS users, but also because of search engines
  • all links should be clickable and lead to some page, even if they open a JS popup. This is not only because of search engines, but because of "Open in new tab" too
  • user interaction that is intended for general visitors (anonymous users) should have at least some fallback for non JS browsers
  • on sites of general public importance posting user content should have at least some fallback

All other parts (if I didn't forget something), especially for loged in users can freely be implemented via JS, having fallbacks where it's suitable, but without making opstructions to the preformance optimisation that JS usage bring.

P.S. Sorry for offtopic.

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

Hubert Farnsworth

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu