Our goal was to try out Hashicorp’s Terraform, a tool that allows to “create infrastructure” based on a definition file.
For example the following definition would create three EC2 instances:
If you want to see how changes to the library affect your project you can map library’s node module to the library’s sources. In that case you don’t need to reinstall library to see the changes. Solution is npm-link.
cd ~/projects/node-redis # go into the package directory
npm link # creates global link
cd ~/projects/node-bloggy # go into some other package directory.
npm link redis # link-install the package
Since most user data in a social network consist in chat and email messages, the messaging system has to scale up very smoothly.
In order to buy time, we had already split it up:
Into email messages stored permanently on the one hand, and chat messages stored for 10 days, and delivered via a Redis queue, on the other hand.
Now chat messages are a valuable information for a social network (they are a key element of our spam detection system, for instance), and the deletion job itself was becoming a performance bottleneck.
So we have been looking for the optimal solution to combine both messaging systems in a scalable way.
The idea was to use a dedicated, shardable database, to spread the load on several machines.
Apart from the throughput, key aspects for the choice of a database system are
its ease of use,
a broad community support,
the existence of up-to-date PHP drivers
as well as backup and monitoring tools.
We’ve evaluated
Cassandra and
MongoDB,
after having rejected other database systems like
CouchDB (performing worse according to most benchmarks),
HyperTable (too complicated to use and to set up), or
HyperDex (lacking community support).
We’ve benchmarked both databases on Amazon EC2 instances for up to 50 million user conversations.
Monit works in mysterious ways.
The service monitoring tool runs an HTTP server in a daemon process, which does all the dirty work.
If you interact with monit on the command line, you send an HTTP request to that server.
For example monit unmonitor apache2 is in fact doing a POST-request to your local monit server.
Unfortunately all monit CLI commands are working asynchronously, meaning they exit before the actual task has been finished by the daemon process.
The same goes for reloading monit configuration. A monit reload sends a SIGHUP to the daemon process:
A few weeks ago our team decided to migrate OpenX 2.8.3 run on Debian Squeeze to Revive AdsServer 3.0.3 run on Debian Wheezy.
We researched a lot and gathered as much info as possible. All preparation took a bit as platform was tested using specs
which are part of open source puppet-packages deployment modules (done by us)
The upgrade process is described very well on Revive website. They suggest to read manual very carefully!
I confirm, please do it and please read very carefully also requirements.