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 :()
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?
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)…
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 
david wrote:
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
Chris
david wrote:
even something like Google News does make heavy use of caching, whether
As I said I’m still getting to grips with deployment myself, but if I
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
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
Chris T wrote:
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.
i’ll try in the production enviroment…
it’s more like IM real time than google news which can be updated every
30 seconds… i think that in an IM apps you can’t cache anything, is it
right?
Ok, i’ll look the book
thanks