/tmp $ cd redis-2.2.8/
/tmp/redis-2.2.8 $ make
/tmp/redis-2.2.8 $ cd src
/tmp/redis-2.2.8/src $ ./redis-server
[295] 31 May 15:36:30 # Warning: no config file specified, using the default config. In order to specify a config file use 'redis-server /path/to/redis.conf'
[295] 31 May 15:36:30 * Server started, Redis version 2.2.8
[295] 31 May 15:36:30 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
[295] 31 May 15:36:30 * The server is now ready to accept connections on port 6379
[295] 31 May 15:36:30 - 0 clients connected (0 slaves), 790480 bytes in use
[295] 31 May 15:36:35 - 0 clients connected (0 slaves), 790480 bytes in use
[295] 31 May 15:36:40 - 0 clients connected (0 slaves), 790480 bytes in use
I don't think any of it's supported. Redis will run, but you can't exactly get to it (no TCP routing mesh apparently). It really just seems like they made it really easy to add new languages.
Since its fairly easy to composite multiple WSGI apps together, one could run a few different Python WSGI-based apps under a single multi-threaded process to take full advantage of the free quota. That would work with Pylons/Pyramid/Flask and other Python web frameworks that don't rely on a single set of module global settings (Django).
It worked for me too :) but check up your billing usage statement it will be showing some charges, even though you are under free limit. I just filed a support ticket with heroku, after scaling the web dyno to 0 ;)
Cedar now allows you to scale any dyno as low or high as needed, including all the way down to 0. This means you could choose to scale your web dyno down to 0 and a worker to 1. If left this way for the entire month you would have 720 worker dyno-hours and 0 web dyno-hours total at the end of the month, fully inside the 750 available per month.http://devcenter.heroku.com/articles/billing-changes
This means any process type, for example cron jobs, for free. As long as only one process is ran per app, but as far as I know, you can run as many apps as you want. This sounds like a very nice deal. Am I missing something?
Of course, you can't share multiple apps behind one domain, so if the one dyno isn't keeping you you'll need to scale up and pay for it.
OTOH, if you don't need to worry about any extra latency (maybe?) you could probably get away with a rails+node app like https://github.com/maccman/holla running free by having one app just run the web interface, and point the backend at another app running node.
As soon as you go outside of one tech stack it's cheaper to just get a small VPS to start with, but heroku definitely has its perks.
It seems unlikely that rack-cache + memcached would actually offer similar performance to varnish. This seems like a pretty bad set of changes for apps that need to serve out lots of static content - think newspapers, blogs, etc.
Will the old configuration style for http caching continue to be supported indefinitely?
I expect that someone will build a Varnish add on for Heroku. It even looks possible to run Varnish on a dyno, believe it or not.
I love Varnish, but it's completely inflexible in Heroku so it's always been a mixed blessing. Sticking Google Analytics on your page, for instance, creates cookies for users that mean they will no longer get cached content. It's something that I can work around with dedicated Varnish, but Heroku can't really fix for me.
That's not true. Google Analytics cookies are injected via JS. When heroku's Varnish is checking for a cached version of the page, it strips any cookie information given by the browser.
We've are running production apps with Varnish caching + Google Analytics without issue.
Set your cookies with JS or on uncached pages (such as POST logins) and you'll be fine.
It's possible that it strips the GA cookies (which is cool, I had no idea), but Varnish doesn't strip cookie information from the browser. If it did you wouldn't get any Rails sessions or anything.
You can set cookies on uncached pages in ruby and read them without issue in JS on Varnish cached pages. The page will still be cached even if the user has a session cookie.
Basically: don't set or get cookies in ruby on cached pages and you'll be fine.
"The new HTTP stack does not include Varnish (a reverse proxy cache) because it is not compatible with the advanced HTTP features described above. If you wish use HTTP caching headers, rack-cache and the memcache add-on offer features and performance comparable to Varnish, but with the additional benefit of giving you complete control over authentication and page expiration."
LXC is one of several isolation layers used in the Heroku dyno manifold to ensure process security and resource guarantees. Here is a more in-depth discussion of Heroku dyno isolation: http://devcenter.heroku.com/articles/dyno-isolation.
This is beautiful. I like how they got rid of Varnish. The problem with Varnish was that you couldn't test it in your local development environment. (Heroku wouldn't give out their Varnish configuration, so you could only make an educated guess as to how their Varnish was configured.)
It seems as though it will. I read somewhere in the Dev Center that an app called "foobar" can now be accessed via "foobar.herokuapp.com", which uses an advanced new HTTP stack that supports async and chinned responses too I believe. I don't remember the exact page I read that, but take a peek in the Dev Center for more info.
