Wastholm.com

Django applications can be tuned to consume more or less memory. Consider the following strategies to reduce your Django application’s memory consumption, but note that some configuration changes—such as allocating fewer processes or maximum requests—may have a negative impact on overall performance. You may want to experiment with different combinations of configuration values to suit your memory and performance needs.

Disqus, one of the largest Django applications in the world, will explain how they deal with scaling complexities in a small startup.

There are many benefits to keeping a lightweight stack. At Disqus, keeping the stack thin helps us scale Django to reach over 125 million unique visitors a month with just a small team of engineers. Avoiding complicated software packages until needed reduces unnecessary overhead, and has let us stay nimble, and use new capabilities in Django (i.e., database routing) and other software as they arise. The talk will cover key parts of the architecture and development process at Disqus, including databases (relational and non), queues, automated testing, and continuous deployment.

Smisk is a simple, high-performance and scalable web service framework written in C, but controlled by Python. Smisk is currently used in production by Spotify and Livebloggen.

Redis is an advanced key-value store. It is similar to memcached but the dataset is not volatile, and values can be strings, exactly like in memcached, but also lists, sets, and ordered sets. All this data types can be manipulated with atomic operations to push/pop elements, add/remove elements, perform server side union, intersection, difference between sets, and so forth. Redis supports different kind of sorting abilities.

In order to be very fast but at the same time persistent the whole dataset is taken in memory, and from time to time saved on disc asynchronously (semi persistent mode) or alternatively every change is written into an append only file (fully persistent mode). Redis is able to rebuild the append only file in background when it gets too big.

Since the rise of the Web, SQL-based relational databases have been the dominant structured storage technology behind online applications. The past few years have seen the emergence of the cloud as a compelling environment for online application development, bringing true utility computing into the infrastructure pantheon. But the cloud and SQL do not mix well, and multiple efforts are now underway to offer viable alternatives to the venerable database. In this article, I'll review the forces that have led to this shift, and I'll argue that while relational databases are by no means doomed, they will soon be joined in the cloud, and possibly out-shined by, new non-relational database technologies.

Trouble is, implementing the best scaling practices is not free, and is often overlooked early in a product's lifecycle. Small teams use modern frameworks to quickly develop useful applications, with little need to worry about scale: today you can run a successful application on very little infrastructure... at least, you can up to a point. Past this point lies an uncomfortable middle ground, where small teams face scaling challenges as their system becomes successful, often without the benefit of an ideal design or lots of resources to implement one. This article will lay out some pragmatic advice for getting past this point in the real world of limited foresight and budgets.

|< First   < Previous   11–16 (16)