Hi,
I’m just starting to play around with ruby and rails. I love the MVC
concept, and the language itself is a lot of fun also.
There is one thing that’s really bugging me - every rails site I’ve seen
so far (with the exception of this forum) seems to render very slowly.
There is this longer than normal (compared to PHP, ASP.net, JSP) delay
before the site gets loaded.
Is this the price to pay for using the framework?
Can anyone point me to a fastloading rails page?
thx
On 29/11/2005, at 7:40 PM, arnold soginet wrote:
Can anyone point me to a fastloading rails page?
It really depends on the site, for example my site at http://
wishlists.sitharus.com/ produces pages in 0.5-2 seconds depending on
the number of items and that’s with a slow machine. Don’t forget that
Rails is a fairly young framework, I’m sure that in time the speed
will improve.
Personally I find the ease of development a real bonus, hardware is
cheaper than my time 
Matz is working on the Ruby Virtual Machine. It’s not Rails slowing
things down, it’s Ruby.
Christer
On 11/29/05, arnold soginet [email protected] wrote:
Hi,
Can anyone point me to a fastloading rails page?
thx
–
http://nitrozen.com loads pretty fast 
It depends on how the application is written, not only what
language/framework is used.
The production hardware is of great importance, libraries
In reality you can get <1second /request rendering easily.
Here’s how to optimize Rails usage:
http://weblog.textdrive.com/article/175/rails-optimizing-resource-usage
Christer N. wrote:
Matz is working on the Ruby Virtual Machine. It’s not Rails slowing
things down, it’s Ruby.Christer
Ruby performance could certainly be improved. But this is, although
important, only a tiny piece of the puzzle. Rails can also be slowing
things down, if not used in a way that enables good performance.
I blog about Rails performance on http://railsexpress.de/blog
– stefan
Karol Hosiawa wrote:
–
http://nitrozen.com loads pretty fast
It depends on how the application is written, not only what
language/framework is used.
Very true.
The production hardware is of great importance, libraries
In a shared hosting environment, it’s hard to achieve good performance.
In reality you can get <1second /request rendering easily.
Just below 1 sec per request is very slow. My own app runs at about 10
ms per request.
Here’s how to optimize Rails usage:
Subscribe to my blog, too. I post Rails performance related issues on a
regular basis there.
– stefan
On 29.11.2005, at 8.40, arnold soginet wrote:
Hi,
I’m just starting to play around with ruby and rails. I love the MVC
concept, and the language itself is a lot of fun also.There is one thing that’s really bugging me - every rails site I’ve
seen
so far (with the exception of this forum) seems to render very slowly.
Could you give some examples?
There is this longer than normal (compared to PHP, ASP.net, JSP) delay
before the site gets loaded.Is this the price to pay for using the framework?
Can anyone point me to a fastloading rails page?
Besides what’s come up already:
//jarkko
On Nov 28, 2005, at 10:59 PM, Phillip H. wrote:
There is this longer than normal (compared to PHP, ASP.net, JSP)
speed will improve.Personally I find the ease of development a real bonus, hardware is
cheaper than my time
Rails can be plenty fast when used correctly. One site I built is
very data heavy and it loads plenty fast compared to other sites of
its size. Check it out http://yakimaherald.com
Cheers-
-Ezra Z.
WebMaster
Yakima Herald-Republic Newspaper
[email protected]
509-577-7732
Also, I have been impressed how snapier Rails is once deploying under a
FastCGI-enabled web server!
I’ll definitely check it out, once I’ve got a little more ruby under my
belt.
Speed of the application is dependent more in Rails and Ruby. Look into
optimizing your web service, database access, server tuning, and network
latencies. Of course, you would do those things anyway.
I agree.
It’s good to see that some of those sites (especially Stefan’s recipes)
do load pretty fast…
Thanks guys.
Keep in mind that rails in development will reload its components
everytime to compensate for changes you are making in the development
cycle. Once you move into a production mode, you will notice better
speeds.
Also, I have been impressed how snapier Rails is once deploying under a
FastCGI-enabled web server!
Speed of the application is dependent more in Rails and Ruby. Look into
optimizing your web service, database access, server tuning, and network
latencies. Of course, you would do those things anyway.
Allen
Stefan K. wrote:
Ruby performance could certainly be improved. But this is, although
important, only a tiny piece of the puzzle. Rails can also be slowing
things down, if not used in a way that enables good performance.
One thing I know you can do with Java/JSP and ASP.NET is to use
JspWriter.flush() or Page.Response.Flush()/HtmlTextWriter.Flush()
to send parts of a page to a browser while still computing the
remainder of the page. The browser will happily render the
HTML as it receives it. Assuming the header is quick
to generate) a user gets instant feedback. And for a long
page, everything “above the fold” may be generated and rendered
almost instantly even if it takes seconds to generate the rest
of the HTML page that’s not visible until scrolling down - and
by the time the user does scroll down it’ll be ready for him.
I’m too new to know how to do this in rails, though.
This is an optimization which tries to improve the “perceived
performance” for the user. It will do nothing to improve your servers
throughput. I’m much more after seeking improvements that increase
throughput.
Perceived performance is also very important for customer
satisfaction… I
came to realise that part of my users prefer a more responsive UI (a
better
perceived performance) even at the cost of a slightly lower global
throughput… (that’s not a reason for not optimizing the throughput
though
thibaut
Thibaut Barrère wrote:
throughput… (that’s not a reason for not optimizing the throughput though
I didn’t mean to imply that UI responsiveness isn’t important. But if
your throughput isn’t good enough, it won’t help trying to improve
responsiveness. So my priorites are: throughput comes first, if this is
good enough, then you can look for improving responsiveness. In most
cases, once you’ve achieved satisfactory throughput, responsiveness
follows from lower server load.
– stefan
Hi,
Am 30.11.2005 um 10:18 schrieb Stefan K.:
I didn’t mean to imply that UI responsiveness isn’t important. But if
your throughput isn’t good enough, it won’t help trying to improve
responsiveness. So my priorites are: throughput comes first, if this
is good enough, then you can look for improving responsiveness. In
most cases, once you’ve achieved satisfactory throughput,
responsiveness follows from lower server load.
I think the responsiveness is one of the most important things. If it
is approached by a high throughput, well done.
The whole bunch of Ajax effects emerged just because of UI
responsiveness. So I would not say this “flush();” is the only way, but
it can help a lot. Most browser engines are built on the fact that most
internet connections are slow. They show the page incrementally. Just
sad that rails can’t come up with this feature.
Helmut
I must agree that the #1 perceived performance problem with Rails (and
lots of other web development kits) is directly related to the lack of
flushed output. While is essentially an illusion and probably not an
issue for a lot of ‘applications’, many ‘public-facing’ sites rely on
this sort of responsiveness, especially when a page is lamentably full
of advertising and other ignorable elements. However, this is a hard
problem to solve when you want to perform after filters, etc.
Having said that, it would be interesting to see a way to flush output
for ‘optimized’ pages, even if some Rails functionality is limited.
Would this technically be possible without radically modifying the way
the framework works?
Joshua Sierles
Ron M wrote:
remainder of the page. The browser will happily render the
HTML as it receives it. Assuming the header is quick
to generate) a user gets instant feedback. And for a long
page, everything “above the fold” may be generated and rendered
almost instantly even if it takes seconds to generate the rest
of the HTML page that’s not visible until scrolling down - and
by the time the user does scroll down it’ll be ready for him.
This is an optimization which tries to improve the “perceived
performance” for the user. It will do nothing to improve your servers
throughput. I’m much more after seeking improvements that increase
throughput.
I’m too new to know how to do this in rails, though.
Currently this isn’t possible with Rails. The page gets constructed as a
string, which is sent to the FCGI/SCGI pipe only after it has been
constructed in its entirety. Depending on your FCGI setup, you will see
parts being rendered before the entire page has been received by the
browser though.
– stefan
Helmut Sedding wrote:
responsiveness follows from lower server load.
I think the responsiveness is one of the most important things. If it
is approached by a high throughput, well done.The whole bunch of Ajax effects emerged just because of UI
responsiveness. So I would not say this “flush();” is the only way,
but it can help a lot. Most browser engines are built on the fact that
most internet connections are slow. They show the page incrementally.
If your pages are so slow that you need to flush your output buffer to
make them appear faster than they are, then you are in trouble.
Just sad that rails can’t come up with this feature.
I didn’t say it couldn’t be implemented. I simply think it’s not worth
the added complexity, which is a slightly different position.
– stefan
Stefan K. wrote:
Joshua Sierles wrote:
I must agree that the #1 perceived performance problem with Rails (and
lots of other web development kits) is directly related to the lack of
flushed output. While is essentially an illusion and probably not an
issue for a lot of ‘applications’, many ‘public-facing’ sites rely on
this sort of responsiveness, especially when a page is lamentably full
of advertising and other ignorable elements. However, this is a hard
problem to solve when you want to perform after filters, etc.
I have an application that the turnaround times were too slow, so I
solved it using AJAX. It is a data entry application, and although the
turnaround times are good, the users wanted to be able to start typing
right away again. I used AJAX to make the entry field blank
immediately, but fire the request to the server asynchronously. This
way, every request happens, but the full feedback from it does not need
to happen before the next entry. I have never seen it where the user
can type a whole new item before the response, but when forcing it to
happen (artificial load on the server and copy/paste for the entry item)
everything caught up and processed correctly.
I just used a remote form link and a little Javascript in the after on
the form_remote_tag to blank the field after the request was sent but
before the response got back.
Joshua Sierles wrote:
I must agree that the #1 perceived performance problem with Rails (and
lots of other web development kits) is directly related to the lack of
flushed output. While is essentially an illusion and probably not an
issue for a lot of ‘applications’, many ‘public-facing’ sites rely on
this sort of responsiveness, especially when a page is lamentably full
of advertising and other ignorable elements. However, this is a hard
problem to solve when you want to perform after filters, etc.
Advertising is mostly implemented by embedding images in html, usually
retrieved from completely different servers. I can’t see how flushing
your output buffer prematurely would help there.
Having said that, it would be interesting to see a way to flush output
for ‘optimized’ pages, even if some Rails functionality is limited.
Would this technically be possible without radically modifying the way
the framework works?
It would be necessary to make major changes to request processing, with
questionable value. One major drawback which immediately springs to mind
is that you would need to send out the request headers before knowing
whether the request can be fullfilled at all. This doesn’t sound very
attractive to me.
I’m not convinced it’s worth the implementation effort and there are a
number of other areas which I’d try to improve before diving into output
flushing, but I’ll keep the suggestion in the back of my head.
– stefan
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs