I know a lot of free hosters who support PHP etc. but I'd rather try Rails.
Does anyone know of a free hosting who offers Rails?
Unfortunately as a student I can't afford paid hosting on eg. Textdrive...
···
--
"May the source be with you"
* Aquila <braempje@netscape.net> [0359 16:59]:
I know a lot of free hosters who support PHP etc. but I'd rather try Rails.
Does anyone know of a free hosting who offers Rails?
Nope. If you just want to try it, why not get a Linux distro and run it on that?
···
--
'I should have been a plumber.'
-- Albert Einstein
Rasputin :: Jack of All Trades - Master of Nuns
Hello Aquila,
I know a lot of free hosters who support PHP etc. but I'd rather try Rails.
Does anyone know of a free hosting who offers Rails?
Unfortunately as a student I can't afford paid hosting on eg. Textdrive...
Please remember that Rails is from a CPU/Memory cost perspective
more comparable with Java or other application server technologies.
It absolutely makes no sense for any hoster to offer something like this.
It is also difficult to setup because you need a FCGI. mod_ruby does
still not work in a shared hosting environment.
If you are a student you can maybe ask someone in your university.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
I wrote a little piece on getting Typo to run on a freeshell.org
account (which is free!)
You will notice it is a bit slow as I was unable to get fcgi working,
but I'm going to get it working next week.
You can find the article here: http://wmoxam.freeshell.org
-- Wes
···
On Fri, 18 Mar 2005 01:59:44 +0900, Aquila <braempje@netscape.net> wrote:
I know a lot of free hosters who support PHP etc. but I'd rather try Rails.
Does anyone know of a free hosting who offers Rails?
Unfortunately as a student I can't afford paid hosting on eg. Textdrive...
--
"May the source be with you"
Free is going to be difficult to find at the moment. If you're smart,
you'll start an open source project and often times, open source
friendly hosting companies (like mine) will sometimes give you a nice
discount on their hosting rates.
If you do find any free companies, make sure you let others know so that
they can find a place to go as well. 
Cheers,
Robby
···
On Fri, 2005-03-18 at 01:59 +0900, Aquila wrote:
I know a lot of free hosters who support PHP etc. but I'd rather try Rails.
Does anyone know of a free hosting who offers Rails?
Unfortunately as a student I can't afford paid hosting on eg. Textdrive...
--
/***************************************
* Robby Russell | Owner.Developer.Geek
* PLANET ARGON | www.planetargon.com
* Portland, OR | robby@planetargon.com
* 503.351.4730 | blog.planetargon.com
* PHP, Ruby, and PostgreSQL Development
* http://www.robbyonrails.com/
****************************************/
Aquila wrote:
Does anyone know of a free hosting who offers Rails?
So conclusion: unless you're willing to play around with shells it's not
possible?
···
--
"May the source be with you"
Fascinating project. In practice, is there an actual community built up
around it, or just a bunch of individual users?
martin
···
Wes Moxam <wildwildwes@gmail.com> wrote:
I wrote a little piece on getting Typo to run on a freeshell.org
account (which is free!)
Dick Davies ha scritto:
* Aquila <braempje@netscape.net> [0359 16:59]:
I know a lot of free hosters who support PHP etc. but I'd rather try Rails.
Does anyone know of a free hosting who offers Rails?Nope. If you just want to try it, why not get a Linux distro and run it on that?
because it also runs just fine on other platforms 
Dick Davies wrote:
Nope. If you just want to try it, why not get a Linux distro and run it on
that?
It works on a local machine, but I'd like to have a site running on Rails.
My bandwith quotas don't allow it, and my machine isn't always on either.
···
--
"May the source be with you"
Hello Aquila,
> I know a lot of free hosters who support PHP etc. but I'd rather try Rails.
> Does anyone know of a free hosting who offers Rails?
> Unfortunately as a student I can't afford paid hosting on eg. Textdrive...Please remember that Rails is from a CPU/Memory cost perspective
more comparable with Java or other application server technologies.
43 Things averages 46661 KB/Rails process (we peak at 200,000 pageviews/day running 40 processes FastCGI across 2 servers). Most of the time load hovers around 0.10 to 0.20 (we have dual 3GHz Xeons with 2GB RAM), but peaks at about 0.50.
In an emergency, we can run the entire site off of one box with only 20 FastCGI processes with no performance degradation.
I was under the impression that Java takes up a much larger memory footprint, but have never actually used it so I can't say how much memory it takes. I have no idea how much CPU an equivalent Java site would use.
Please provide some relevant data about how much memory/CPU a Java site would need to have equivalent performance.
People have just managed to fit Rails into 64MB virtual servers. I doubt you could do the same with a Java app.
It absolutely makes no sense for any hoster to offer something like this.
I disagree and feel that this is a statement that carries a great deal of ignorance.
I believe people have gotten Rails to fit in a 64MB virtual server with a shoehorn. There's been some discussion of this on the Rails mailing list. It would make perfect sense for a host to offer free 64MB virtual servers because the sandbox is much easier to manage.
It is also difficult to setup because you need a FCGI.
I've not found this at all difficult, and judging from the Rails mailing list, many, many people have found it pretty darn simple with only a few well-documented gotchas. This leads me to believe difficult is entirely the wrong word to use.
Installing involves about 4 lines added to the httpd.conf and installing 3 packages. FastCGI is common enough that packages (FreeBSD's ports tree, in my case) are very readily available.
PGP.sig (186 Bytes)
···
On 17 Mar 2005, at 14:05, Lothar Scholz wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
* Lothar Scholz <mailinglists@scriptolutions.com> [2005-03-18 07:05:02 +0900]:
Hello Aquila,
It is also difficult to setup because you need a FCGI. mod_ruby does
still not work in a shared hosting environment.
Although not free, mod_ruby will work on a verio shared host (verio.com).
They call them virtual servers and you get root access (and so
do the 100 other users that you don't see.)
···
--
Jim Freeze
Code Red. Code Ruby
In my experience it's a bunch on individual users. However, it's been
around for a long time (since 1987) and I have a feeling that it was
more of a community in the past before there were blogs, hml based
discussion forumns, etc. I'd imagine that the long time users form
more of a community than all of us "newbies" who have joined since
the mid nineties.
-- Wes
···
On Fri, 18 Mar 2005 15:29:55 +0900, Martin DeMello <martindemello@yahoo.com> wrote:
Wes Moxam <wildwildwes@gmail.com> wrote:
>
> I wrote a little piece on getting Typo to run on a freeshell.org
> account (which is free!)Fascinating project. In practice, is there an actual community built up
around it, or just a bunch of individual users?martin
A free shell account will do the job if you're willing to sacrifice some speed.
-- Wes
···
On Fri, 18 Mar 2005 22:00:05 +0900, Aquila <braempje@netscape.net> wrote:
Dick Davies wrote:
> Nope. If you just want to try it, why not get a Linux distro and run it on
> that?
>It works on a local machine, but I'd like to have a site running on Rails.
My bandwith quotas don't allow it, and my machine isn't always on either.
--
"May the source be with you"
Hello Eric,
I think you didn't understand the intention of my posting.
43 Things averages 46661 KB/Rails process (we peak at 200,000
pageviews/day running 40 processes FastCGI across 2 servers). Most of
the time load hovers around 0.10 to 0.20 (we have dual 3GHz Xeons with
2GB RAM), but peaks at about 0.50.
.....
People have just managed to fit Rails into 64MB virtual servers. I
doubt you could do the same with a Java app.
This is about factor 50-100 to high to provide a free hosting
environment. You can without problems put 1000 PHP Users on one
machine. Many free hosters have even more then this.
It absolutely makes no sense for any hoster to offer something like
this.
I disagree and feel that this is a statement that carries a great deal
of ignorance.
I believe people have gotten Rails to fit in a 64MB virtual server with
a shoehorn. There's been some discussion of this on the Rails mailing
list. It would make perfect sense for a host to offer free 64MB
virtual servers because the sandbox is much easier to manage.
If somebody offers a free hosting the management should be around 0.
It is also difficult to setup because you need a FCGI.
Installing involves about 4 lines added to the httpd.conf and
installing 3 packages. FastCGI is common enough that packages
(FreeBSD's ports tree, in my case) are very readily available.
Thats to much if you don't get money. You also have to setup some
scripts on a machine and observe more processes. How does FCGI perform
when there are 200 or more different FCGI servers ? If you offer it
for free you must put a lot of persons on the machine, because it
costs money for the hardware, power, security (data center)...
It makes sense to offer rails support without doubt, much more sense
then java server page support. But not for free. For free you will only
get static webspace or php / simplest cgi support. They are the
only way to put the cost low enough to cross finance the service with
advertising or by hope that a few users will upgrade to non-free
packages.
Maybe some education institutions will offer it for free (since they can
get the money in other ways) and so this was my recommended advise to the
original poster: ask his school/university.
I hope you understand that i'm not speaking against rails, but about
the financal problems of web hosters.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
43 Things averages 46661 KB/Rails process (we peak at 200,000
pageviews/day running 40 processes FastCGI across 2 servers). Most of
the time load hovers around 0.10 to 0.20 (we have dual 3GHz Xeons with
2GB RAM), but peaks at about 0.50.
i'm surprised you're using so much memory. is the 46MB number just
rss, or rss+shared? i would expect your rss-per-process to be 1-10MB,
with >10MB being indicative of leaks, unless you're doing lots of
per-process caching, which doesn't make a lot of sense from a locality
perspective anyways.
I was under the impression that Java takes up a much larger memory
footprint, but have never actually used it so I can't say how much
memory it takes. I have no idea how much CPU an equivalent Java site
would use.Please provide some relevant data about how much memory/CPU a Java site
would need to have equivalent performance.People have just managed to fit Rails into 64MB virtual servers. I
doubt you could do the same with a Java app.
i can tell you that 64MB is quite doable with most j2ee containers, and
in fact i would argue it's easier to constrain memory usage with java
web apps than it is with ruby rails apps. while it's not as hungry as
perl, ruby is pretty liberal with memory usage.
i've had containers with 20+ server threads use 25MB, and i bet you
could tune them even smaller than that if you stripped out non-essential
features. it does depend on which container you use, though. with
containers, you get a fixed cost for the container itself (10-20MB), and
then a per-thread overhead of 100-200KB. just ruby itself on OS X takes
1.3MB rss per process, so you can see how much more memory ruby is
using for each handler...
as far as container memory usage goes, you can also use jvm switches to
set min/max limits for jvm memory usage, so you can force java to stay
within a given memory usage range, while the same is not true for ruby.
you still have to make sure you don't create too many request threads
and get an OutOfMemoryError, but it is a cleaner failure mode versus
having the OS just kill your process without warning when you reach your
limit.
re: cpu usage, it would be interesting to do some benchmark comparisons.
the major containers out there are pretty mature and have a lot of
optimizations to help with GC; they reuse per-request objects, push
declarations to the widest scope possible, avoid destruction, etc.
servlets have deeper call chains when dealing with requests than webrick
does, but when you factor in the near-C speed of modern jvms with the
relatively mature containers out there, i would be surprised if rails
could handle requests with less cpu time expended per-request or handle
more aggregate requests per second than a servlet app.
of course, i don't think that being the market leader in speed or memory
usage is rails's goal. it's a lightweight and agile web app framework
that lets you get things running 10x faster than any other framework out
there. i think it's awesome, and the more i use rails, the more i like
it.
i just wanted to give some data points showing that java isn't the
memory/cpu hog it is sometimes made out to be. i think rails is great
for rapid development and prototyping, and for running small to moderate
request loads, but if i'm deploying the app for enterprise request
rates, i'm probably going to port it to java for the final deployment.
hardware is cheap, but not that cheap.
doug
···
On Sat, Mar 19, 2005 at 07:29:38AM +0900, Eric Hodel wrote:
--
"Contrary to what most people say, the most dangerous animal in the
world is not the lion or the tiger or even the elephant. It's a shark
riding on an elephant's back, just trampling and eating everything they
see." -- Jack Handey
Hello Jim,
* Lothar Scholz <mailinglists@scriptolutions.com> [2005-03-18 07:05:02 +0900]:
Hello Aquila,
It is also difficult to setup because you need a FCGI. mod_ruby does
still not work in a shared hosting environment.
Although not free, mod_ruby will work on a verio shared host (verio.com).
They call them virtual servers and you get root access (and so
do the 100 other users that you don't see.)
Sure. But thats not what you normally call shared hosting (yes it is
shared hosting but the normal meaning of this term means
something different, a shared logical environment and not a sandbox on
a shared virtualized hardware).
And the prices from verio are insane. A virtual server vor 109
US$/month is nothing that comes to close to a recommendation for
someone who wanted a free hosting. In germany we have for example
deserver.de who offers a good small
virtual server for 3.50 Euro a month. I'm using on of there to monitor
the downtime of my server and do other things that can't be done
easily with PHP (that terminates scripts after 30 sec) on the main
server.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Since a running Ruby process doesn't fork() to spawn new children (FastCGI forks and execs) any sharing would need to be figured out by the OS. I don't worry about that because we aren't near the amount of load that makes it necessary to worry about. (By the time I need to think about it, somebody will probably have figured it out for us.)
At startup the processes are under 20MB, and grow to around 45MB after a day. In development mode we can tickle something that causes processes to grow to 150+ MB (I think this is a problem in our code, as it only happens when working on a particular part of the site, so I doubt this is a Rails problem. At worst, it might be a side effect of the way reloading works in Ruby.)
We do cache lots of stuff in-process, but we haven't investigated our code for potential leaks yet because we've restarted the processes before they've lived for more than two days.
PGP.sig (186 Bytes)
···
On 18 Mar 2005, at 22:00, Doug Beaver wrote:
On Sat, Mar 19, 2005 at 07:29:38AM +0900, Eric Hodel wrote:
43 Things averages 46661 KB/Rails process (we peak at 200,000
pageviews/day running 40 processes FastCGI across 2 servers). Most of
the time load hovers around 0.10 to 0.20 (we have dual 3GHz Xeons with
2GB RAM), but peaks at about 0.50.i'm surprised you're using so much memory. is the 46MB number just
rss, or rss+shared? i would expect your rss-per-process to be 1-10MB,
with >10MB being indicative of leaks, unless you're doing lots of
per-process caching, which doesn't make a lot of sense from a locality
perspective anyways.
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Doug Beaver wrote:
i'm surprised you're using so much memory. is the 46MB number just
rss, or rss+shared? i would expect your rss-per-process to be 1-10MB,
with >10MB being indicative of leaks, unless you're doing lots of
per-process caching, which doesn't make a lot of sense from a locality
perspective anyways.
No, you have it backwards. With Ruby, the shared portion between processes
ends up being quite small. The Ruby interpreter itself is pretty
lightweight, and that is the only code that is shared. All of the code
that is loaded afterwards is duplicated per process. So the RSS of each
process ends up being within a few mb of the total RAM usage,
approximately.
i've had containers with 20+ server threads use 25MB, and i bet you
could tune them even smaller than that if you stripped out non-essential
features. it does depend on which container you use, though. with
containers, you get a fixed cost for the container itself (10-20MB), and
then a per-thread overhead of 100-200KB. just ruby itself on OS X takes
1.3MB rss per process, so you can see how much more memory ruby is
using for each handler...
It depends on the code being benchmarked, but that sort of memory usage is
no problem at all with Ruby.
I just ran a few quick benchmarks with an app I have going into production
soon (IOWA app, unlreleased version of IOWA). On startup, it's total RAM
usage is about 15.0Mb, of which about 12.5Mb is RSS.
I can run it with 200 concurrent request threads and 200 cached sessions
with a total RAM usage of less than 25Mb, consistently. The RAM usage
doesn't grow. No leaks. This is on an AMD2600 based Linux box with a 2.4
kernel,and with that single process, for this particular app, with even
1000 concurrent (green) threads, it has a throughput of about 105
requests/second at about 9k of dynamically generated HTML per request. If
I reduce the concurrency to 1, on one process I can get 140
requests/second, and if I run 2 processes, 150 requests/second on this app.
Ruby acquits itself quite adequately regarding performance, as far as I am
concerned.
relatively mature containers out there, i would be surprised if rails
could handle requests with less cpu time expended per-request or handle
more aggregate requests per second than a servlet app.
The trick with this sort of comparison is in comparing apples to apples. I
have long been interested in writing an article or three that compares
implementation details and then performance of some task or tasks in Ruby
and non-Ruby frameworks. It's not an easy task, though. The choice of
fair benchmarks, and then the task of getting good, equivalent
implementations of the task(s) under the frameworks to be compared is
fraught with challenges. Anyone want to help?
My hunch is that Ruby frameworks will acquit themselves quite well on both
the ease of implementation AND performance fronts.
Kirk Haines
Doug Beaver wrote:
> i'm surprised you're using so much memory. is the 46MB number just
> rss, or rss+shared? i would expect your rss-per-process to be
> 1-10MB, with >10MB being indicative of leaks, unless you're doing
> lots of per-process caching, which doesn't make a lot of sense from
> a locality perspective anyways.No, you have it backwards. With Ruby, the shared portion between
processes ends up being quite small. The Ruby interpreter itself is
pretty lightweight, and that is the only code that is shared. All of
the code that is loaded afterwards is duplicated per process. So the
RSS of each process ends up being within a few mb of the total RAM
usage, approximately.
ah, you're right, i sometimes forget that the requires are at runtime.
from what eric mentioned earlier, it sounds like fcgi is spawning new
ruby processes instead of forking from a master ruby process. my fcgi
knowledge is pretty rusty, but if there was a way to do the fork model,
then we could get fcgi rails installs to use less memory. that said,
since it's fcgi, you're already using a lot less memory, since you're
running a handful of rails fcgi processes fronted by a pool of httpds,
versus the normal cgi model where each httpd loads and runs their own
cgis. so maybe it's a case of diminishing returns...
> i've had containers with 20+ server threads use 25MB, and i bet you
> could tune them even smaller than that if you stripped out
> non-essential features. it does depend on which container you use,
> though. with containers, you get a fixed cost for the container
> itself (10-20MB), and then a per-thread overhead of 100-200KB. just
> ruby itself on OS X takes 1.3MB rss per process, so you can see how
> much more memory ruby is using for each handler...It depends on the code being benchmarked, but that sort of memory
usage is no problem at all with Ruby.
i agree, if you're talking about threaded ruby apps versus the fcgi
model. i would have said the same is true for ruby/fcgi until you
pointed out that it's not taking much advantage of shared memory.
that said, i wasn't saying that ruby can't fit in the 64MB space, i was
showing that java could fit under eric's 64MB window, since he mentioned
that he thought java wouldn't fit...
I can run it with 200 concurrent request threads and 200 cached
sessions with a total RAM usage of less than 25Mb, consistently. The
RAM usage doesn't grow. No leaks. This is on an AMD2600 based Linux
box with a 2.4 kernel,and with that single process, for this
particular app, with even 1000 concurrent (green) threads, it has a
throughput of about 105 requests/second at about 9k of dynamically
generated HTML per request. If I reduce the concurrency to 1, on one
process I can get 140 requests/second, and if I run 2 processes, 150
requests/second on this app. Ruby acquits itself quite adequately
regarding performance, as far as I am concerned.
that's pretty good performance, although it's difficult to assess
without knowing what your app is doing. this is why it will be great to
get some good, relative benchmarks between the different frameworks out
there.
The trick with this sort of comparison is in comparing apples to
apples. I have long been interested in writing an article or three
that compares implementation details and then performance of some task
or tasks in Ruby and non-Ruby frameworks. It's not an easy task,
though. The choice of fair benchmarks, and then the task of getting
good, equivalent implementations of the task(s) under the frameworks
to be compared is fraught with challenges. Anyone want to help?
i agree it's hard to do fair benchmarks, but i think it's definitely
doable. are you thinking just ruby and java? i would be glad to help
out with this, i have some background in performance testing.
My hunch is that Ruby frameworks will acquit themselves quite well on
both the ease of implementation AND performance fronts.
ruby totally wins on ease of implementation. as far as performance
goes, that's much more subjective. it will be interesting to see the
results of the benchmarks!
doug
···
On Mon, Mar 21, 2005 at 02:09:51AM +0900, Kirk Haines wrote:
--
"Contrary to what most people say, the most dangerous animal in the
world is not the lion or the tiger or even the elephant. It's a shark
riding on an elephant's back, just trampling and eating everything they
see." -- Jack Handey
Hello Doug,
No, you have it backwards. With Ruby, the shared portion between
processes ends up being quite small. The Ruby interpreter itself is
pretty lightweight, and that is the only code that is shared. All of
the code that is loaded afterwards is duplicated per process. So the
RSS of each process ends up being within a few mb of the total RAM
usage, approximately.
ah, you're right, i sometimes forget that the requires are at runtime.
from what eric mentioned earlier, it sounds like fcgi is spawning new
ruby processes instead of forking from a master ruby process. my fcgi
knowledge is pretty rusty, but if there was a way to do the fork model,
then we could get fcgi rails installs to use less memory. that said,
since it's fcgi, you're already using a lot less memory, since you're
running a handful of rails fcgi processes fronted by a pool of httpds,
versus the normal cgi model where each httpd loads and runs their own
cgis. so maybe it's a case of diminishing returns...
How should a forking modell help with memory here ?
The first time you get a GC run (and that happens very often) ruby walks
the whole memory and sets flags in data and code (ruby code nodes are also
collected by the GC). At this time the MMU of the CPU will do
a copy on write. So only if you have a lot of large strings or
read only arrays then you will win something. But i doubt that this is
the usual case.
···
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's