is it a lot?

david wrote:

david 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 :()
    
anyone?

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)...

david wrote:

Chris T wrote:
  

david wrote:
    

david 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 :()
    

anyone?

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 :slight_smile:

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
Chris

david wrote:

Chris T wrote:
  

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.
    
The problem with caching is that is something based on real time, just an example, there is something now, but if you refresh the page after 1 minute maybe there isn't anymore because it's show based on time.now... is it possible a cache in this case? i think that with a cache will be shown something that wouldn't be shown, isn't it ?
the 0.4 sec is based on the development environment on a 1.4 ghz and 512 mb ram, with just one user(me), the db access is about 3-4 queries + ferret

With the development environment, rails is reloading everything on each request. You can't compare requests per second on development with production. Also, when you say real time does it really need to be real time (e.g. IM, and conversations), or google news (which is probably updated every five minutes (at least on the user specific stuff, and the common stuff I would be guess may be updated every 30 seconds, but would be shared with thousands of users). Have a good read of the agile book, investigate fragment caching, and think about what the users need and when they need it.

Cheers
Chris