Chris T wrote:
hi, do you think is it a lot 0.4 sec (with rendering, db and other
stuff) to load a page for a page that will be viewed a lot of time with
a lot of requests/seconds ? (caching is not possible in this page :()
Depends... on how many visitors you're expecting. On what you're
deploying on. On environment. Etc. Think we'll need a bit more info to
make any intelligent comments (or unintelligent ones for that matter)...
actually i'm expecting about 1000/1500 visitors at the same time
about the host i'm thinking about a hosting (like dreamhost) or a vps...do you think that a hosting can handle it?
the apps is something like google news, so a lot of news, categories and, i hope, visitors
I'm by no means an expert on this -- quite the opposite in fact, just in the middle of deploying my first full-scale app, and getting to grips with all that entails (fairly heavy duty Linux sys admin stuff), but I would say that you need to rethink how you're doing things. Does 1,000 at the same time really mean "at the same time", which, if they stayed on the site for 10 minutes each would imply something like 60,000 an hour, 1.5million a day. Can't see how that's going to happen on a VPS. Prob not even on a single dedicated host. Also, I would suspect that even something like Google News does make heavy use of caching, whether it's of the data, or the rendered html.
Finally, what's the 0.4 sec based on -- what machine is it running on, what environment, under what loads. How much of that is db access, how much rendering, and so on. Even if each page took 0.8 sec to produce, that wouldn't be a problem as long as you had sufficient (by which I mean a helluva lot) of backend mongrels dealing with that. In reality, I would suspect that through fragment caching, you could probably get that right down (and you would prob need to).
As I said I'm still getting to grips with deployment myself, but if I had to give an answer it would be that you need to rethink things somewhat.
Hope this helps