running a huge site

[Zoltan Dezso]

Hi everyone,

We are running apache with eruby to server .rhtml files. Every apache
process loads eruby, thus every access makes a huge dent on memory. We
have tried using mod_ruby, and while memory usage got better, we had
strange errors and performance didn't increase either. There is no
documentation on the web (i don't regard a non-functioning forum and a
jotted down bunch of notes from modruby.net documentation) and quite
frankly noone seems too eager to share information about this.

Our config is
AddType application/x-httpd-eruby .rhtml
Action application/x-httpd-eruby /cgi-bin/eruby

Tried mod_ruby with this too
RubyRequire apache/eruby-run
RubyRequire apache/erb-run
RubyRequire eruby
<Files *.rhtml>
SetHandler ruby-object
RubyHandler Apache::ERubyRun.instance
</Files>

My company has just lost a server recently due to the high load (~8 per
second, WTF?) Former company (with PHP and Java), we used to serve
hundreds of pages and neither language is very light.

We are not using rails, and unless rails is significantly changed to
accommodate for japanese keitai sites, that is not going to change. FCGI
is not entirely out of the question (although would mean a complete
rewrite of the sites probably).

Our options are: Eruby (is this even maintained anymore?), Mod_ruby (is
this working well, is it performant?), FCGI (might work). What's not an
option: Mongrel (no ssl breaks the deal), Rails, Do nothing (either we
can make ruby make faster and more scalable, or bye-bye ruby -
personally, i love this language, would be a heartbreak to see it go,
but business is business).

Any insights?

Zaki

 

[Jano Svitok]

Hi everyone,

We are running apache with eruby to server .rhtml files. Every apache
process loads eruby, thus every access makes a huge dent on memory. We
have tried using mod_ruby, and while memory usage got better, we had
strange errors and performance didn't increase either. There is no
documentation on the web (i don't regard a non-functioning forum and a
jotted down bunch of notes from modruby.net documentation) and quite
frankly noone seems too eager to share information about this.

Our config is
AddType application/x-httpd-eruby .rhtml
Action application/x-httpd-eruby /cgi-bin/eruby

Tried mod_ruby with this too
RubyRequire apache/eruby-run
RubyRequire apache/erb-run
RubyRequire eruby
<Files *.rhtml>
SetHandler ruby-object
RubyHandler Apache::ERubyRun.instance
</Files>

My company has just lost a server recently due to the high load (~8 per
second, WTF?) Former company (with PHP and Java), we used to serve
hundreds of pages and neither language is very light.

We are not using rails, and unless rails is significantly changed to
accommodate for japanese keitai sites, that is not going to change. FCGI
is not entirely out of the question (although would mean a complete
rewrite of the sites probably).

Our options are: Eruby (is this even maintained anymore?), Mod_ruby (is
this working well, is it performant?), FCGI (might work). What's not an
option: Mongrel (no ssl breaks the deal), Rails, Do nothing (either we
can make ruby make faster and more scalable, or bye-bye ruby -
personally, i love this language, would be a heartbreak to see it go,
but business is business).

Any insights?

Just blind hints:

- FGCI will help you with the overhead of starting interpreter each
time (maybe mod ruby will do that as well)

- erubis is an ERB implementation in C that claims is much faster

- caching parsed templates can help a lot as in my experiences with
plain ERB parsing takes a significant part of running time (you may
use ruby-prof to find out whether it is the case). In my case, with
caching parsed templates time of a script dropped from 12 seconds to 6
(it was a standalone script, not a webpage). Obviojusly, it depends on
how many templates do you have, and how many times they are rendered.

- you should use mongrel behind something (apache, nginx,...) anyway,
so maybe you can work around ssl somehow.

Take these as ideas to look at, that might or might not be helpful. I
have not tested any of them, I even do not develop nor deploy webpages
;-)

J.

 

[Florian Aßmann]

Hi Zoltan,

I'm using a mongrel_cluster behind an apache load balancer which works
fine with SSL. Then you can do alot of performance stuff in Apache
beforehand.
If you want more performance think about using erubis instead of
plain/old erb and imho you're not forced to use the big ActiveRecord
when you're using Rails. Personally I like Sequel but you can do your db
stuff with OG too.
You can also define different database connections for your models which
disburdens your DB server.

=2E.. ahhh, there are quite some performance tips for Rails out there. Or=

you use Camping or Merb which are significantly smaller, and so on...

Cheers
Florian

 

[Craig Beck]

My company has just lost a server recently due to the high load (~8
per
second, WTF?) Former company (with PHP and Java), we used to serve
hundreds of pages and neither language is very light.


Our options are: Eruby (is this even maintained anymore?), Mod_ruby
(is
this working well, is it performant?), FCGI (might work). What's
not an
option: Mongrel (no ssl breaks the deal), Rails, Do nothing (either we
can make ruby make faster and more scalable, or bye-bye ruby -
personally, i love this language, would be a heartbreak to see it go,
but business is business).

From what I've seen concerning performance issues, Apache proxying
to a cluster of mongrels is the way to go. Your apache can handle the
SSL connection and can load balance across any number of mongrel
instances across any number of machines. Mongrel itself does not
handle SSL, but put them behind your firewall and you're set.

Do you have hardware limitations? (i.e. only one server etc?)

Another option that I had briefly experimented with was using a
Lighttpd-fcgi stack that did way better than Apache-fcgi, although I
haven't seen much talk of Lighttpd lately.

http://www.lighttpd.net/

 

[Zoltan Dezso]

You don't say anything about the style of your application itself. Is it
the
kind of forms-driven site with a newly-developed domain model that is
generally a good fit for Rails? Apart from a Japanese-language issue,
you
don't say what has guided your choice of a framework (or no framework).
If
you have really decided to generate your dynamic content from Ruby
unassisted by a framework, then there are several high-performance
deployment options for you to consider.

I'd look at Kirk Haines's Swiftiply.

Hi. It's not like I had too much choice in the beginning. The company
started using ruby in 2000 when rails was not an option. Since then a
fairly large codebase was built bit-by-bit that generates sites for
mobile sites. Unfortunately japanese mobile sites are anything but
standards compliant (frankly, this whole mess is so wrong on so many
levels, that i don't even know where to start. You can forget about
unicode and the only encoding all phones support is the one that is the
least safe for every reason possible, then there is the problem of
special characters built on top of this encoding (pictograms,
emoticons), we have to take extra caution even on this base level - and
the list of supported tags in html is so varying, they had to write a
couple of books on the differences only - i hope japanese mobile
providers will someday realize that using normal XHTML would be so much
more beneficial to everyone. Then there's the issue of authentication
that is done differently for all carriers (we have to take the ID stored
on the phone - forget login screens and clever sessions, cookies
etc...). Finally (for this very short look into the abyss) there's the
problem of a certain provider that only supports apache with their
proprietary download engine - which is probably built by 8-year-olds
looking at the architecture, but that's a different story entirely)

So for me - while I really really like it - rails does not seem to be an
option unless i go in there and tweak the hell out of it myself, or
fork/merge it - but regarding that we scarecely have enough time to
finish our projects on time (again another issue completely) that's
highly unlikely
Also, a constraint is that for one site, i can only have one server
without a huge reorg - and with the risks involved, i'd doubt
topmanagement would approve.

So thanks everyone for the comments. For now, I will be looking into the
mongrel solution.

 

[John Joyce]

Hi. It's not like I had too much choice in the beginning. The company
started using ruby in 2000 when rails was not an option. Since then a
fairly large codebase was built bit-by-bit that generates sites for
mobile sites. Unfortunately japanese mobile sites are anything but
standards compliant (frankly, this whole mess is so wrong on so many
levels, that i don't even know where to start. You can forget about
unicode and the only encoding all phones support is the one that is
the
least safe for every reason possible, then there is the problem of
special characters built on top of this encoding (pictograms,
emoticons), we have to take extra caution even on this base level -
and
the list of supported tags in html is so varying, they had to write a
couple of books on the differences only - i hope japanese mobile
providers will someday realize that using normal XHTML would be so
much
more beneficial to everyone. Then there's the issue of authentication
that is done differently for all carriers (we have to take the ID
stored
on the phone - forget login screens and clever sessions, cookies
etc...). Finally (for this very short look into the abyss) there's the
problem of a certain provider that only supports apache with their
proprietary download engine - which is probably built by 8-year-olds
looking at the architecture, but that's a different story entirely)

So for me - while I really really like it - rails does not seem to
be an
option unless i go in there and tweak the hell out of it myself, or
fork/merge it - but regarding that we scarecely have enough time to
finish our projects on time (again another issue completely) that's
highly unlikely
Also, a constraint is that for one site, i can only have one server
without a huge reorg - and with the risks involved, i'd doubt
topmanagement would approve.

So thanks everyone for the comments. For now, I will be looking
into the
mongrel solution.

Hey Zoltan, don't worry much longer,
a few phones on the japanese market now display normal sites via Opera.
Thanks to the new pressure from iPhone you can expect handset makers
and service providers in Japan to be changing soon.
The special emoticons too are going to be thrown out or standardized,
there is already some translation of them between providers (not much
unfortunately).
But Unicode support has been a big problem in Japan and not just on
mobile sites, normal web sites as well.
Unicode support has been driven largely by Apple and Microsoft in
Japan, even though the JIS standards organization pushed to get SJIS
(shift-JIS) included as part of the Unicode standard. It's coming.
faster than W3C initiatives. Luckily, market pressures on handset
makers in Japan is always strong so they've been fairly agile in
meeting demands. (they've got great engineers who work late every day)

 

[Leonard Chin]

But on a cheerful note:
http://shindaita.stiq.net/rdoc/mobile_on_rails/

This made my day, hopefully others will find it useful too.

If you're going to develop mobile applications for the Japanese market
using rails , jpmobile by id:darashi has a more comprehensive feature
set than Rakuto's mobile on rails.

http://jpmobile.rubyforge.org/

 

[Zoltan Dezso]

http://jpmobile.rubyforge.org/

Thank you! This is really great.

On a different note, i've done a brief benchmarking for ruby. Results
are in no way scientific, just a very crude way of comparing different
methods. Done with ab, i used t = 10, c = 10|50|100 and keepalive both
on and off, so [10/10/o] should mean t = 10, c = 10, keepalive on, and
[10/100/x] t=10 c=100 keepalive off

OS: CentOS 5.0
Apache: 2.2.3
Ruby: 1.8.5

Result values are requests/second
Test page is a very very simple "hello world" type thing (just
displaying the contents of a variable really)

HTML[10/10/o]: 6026
HTML[10/50/o]: 5893
HTML[10/100/o]: 5860
HTML[10/10/x]: 896
HTML[10/50/x]: 1021

Eruby(1.0.5)[10/10/o]:131
Eruby(1.0.5)[10/50/o]:133
Eruby(1.0.5)[10/100/o]:132
Eruby(1.0.5)[10/10/x]:129
Eruby(1.0.5)[10/50/x]:133
Eruby(1.0.5)[10/100/x]:127
Eruby(1.0.5)[30/200/o]:106
Eruby(1.0.5)[30/200/x]:35

mod_ruby(1.2.6)ERubyRun[10/10/o]:692
mod_ruby(1.2.6)ERubyRun[10/50/o]:738
mod_ruby(1.2.6)ERubyRun[10/100/o]:722
mod_ruby(1.2.6)ERubyRun[10/10/x]:766
mod_ruby(1.2.6)ERubyRun[10/50/x]:811
mod_ruby(1.2.6)ERubyRun[10/100/x]:759

rails(fastcgi)[10/10/o]:173
rails(fastcgi)[10/50/o]:133

PHP(5.1.6)[10/10/o]:2993
PHP(5.1.6)[10/50/o]:3027
PHP(5.1.6)[10/100/o]:2954
PHP(5.1.6)[10/10/x]:1058
PHP(5.1.6)[10/50/x]:991
PHP(5.1.6)[10/100/x]:1057
PHP(5.1.6)[30/200/o]:2182
PHP(5.1.6)[30/200/x]:546

Zaki

 

[khaines]

On a different note, i've done a brief benchmarking for ruby. Results
are in no way scientific, just a very crude way of comparing different
methods. Done with ab, i used t = 10, c = 10|50|100 and keepalive both
on and off, so [10/10/o] should mean t = 10, c = 10, keepalive on, and
[10/100/x] t=10 c=100 keepalive off

OS: CentOS 5.0
Apache: 2.2.3
Ruby: 1.8.5

Of course, it depends on the hardware, too, but here's some additional
numbers:

OS: Ubuntu 6.06
Swiftiply: 0.6.0
Ruby: 1.8.5
Hardware: AMD Athlon X2 4200+

Keepalive is irrelevant since it's not currently honored in the above
setup.

(I ran 100k of each of these, 3 times, and averaged)
HTML[10]: 8953
HTML[50]: 9150
HTML[100]: 9180

(I ran 10k of each of these, 3 times, and averaged)
Iowa(0.99.3.5)[10]: 1152
Iowa(0.99.3.5)[50]: 1112
Iowa(0.99.3.5)[100]: 1065


Kirk haines