Tag Archives: dotcloud

Posted on by
Mo' data, mo' problems!

An example graph of the new memory metrics.
(Click to enlarge!)

A while ago, we published a detailed blog explaining How to Optimize the Memory Usage of Your Apps. There was a strong emphasis on metrics. Because knowing the amount of used and available RAM is not enough, and doesn’t cut it when you’re trying to assess whether or not your apps need more memory.

With this in mind, we just released a new version of the dotCloud Dashboard. The new dashboard exposes more detailed memory metrics. You will now see that the memory allocated to your app is split in 4 parts: Resident Set Size, Active Page Cache, Inactive Page Cache, Unused Memory. Let’s review what they mean for your apps.

Resident Set Size

That’s essentially the memory used by processes when they malloc() or do anonymous mmap(). This memory is inelastic: it will amount to exactly what your app has been asking for, no more, no less. If your app asks for more than what is available, it will be restarted. If the memory usage was due to a leak or to the occasional odd request, restarting the app will get it back on track. However, if your app constantly needs more of this kind of memory than what is available, it will constantly be restarted, and it will appear to be unstable.

We detect out-of-memory conditions, and we report them to you: we send e-mail notifications, and we record them to display them on the dashboard. When you receive those notifications, you should take them very seriously, and scale up your app — or audit your code to reduce your memory footprint.

On the new memory graph, the resident set size is drawn in solid dark blue. It’s the baseline of your memory usage, and you should not scale your memory below that amount.

Active and Inactive Page Cache

When your app reads and write from disk, data never goes directly into the application buffers. It transits through the system’s buffer cache or page cache. It stays here for a while, so that if you request the same data again some time later, it will be available immediately, without performing actual disk I/O. Likewise, when you write something, it transits to the same buffer cache; this lets the system perform some optimizations regarding the order in which writes should be committed to disk.

The page cache is elastic: when you run out of memory, the system will happily discard it (since the cached data can be re-read anytime from the disk), or commit it to disk (in the case of cached writes). Conversely, if you havetons of memory, the system will happily retain as much as it can in the cache; which can lead to absurdly high memory uses for seemingly trivial apps. Typical example: a tiny HTTP server, handling requests for 10 MB of content, and using a few GB of page cache. How? Why? Well, because it’s also logging requests, and the log happens to be on disk. And Linux will keep the log in memory as well — if memory is available. Of course, if at some point you need the memory, Linux will free it up instantly. But meanwhile, if you look at your usage graphs, you will see the big memory usage.

On Linux, the page cache is split in two different pools: active and inactive. As the name implies, the active pool contains data that has been accessed recently, while the inactive pool contains data that is accessed less frequently. To make an informed scaling decision, it is important to understand how “active” and “inactive” really work under the hood. The memory is divided in pages, which are blocks of 4 KB. A given page of the buffer cache will start its existence (when it is loaded from the disk) as an active page. When an inactive page is accessed, it gets moved to the active pool. That part is easy! Now, when does an active page get move to the inactive pool? This doesn’t happen out of “old age” (i.e., a page being left untouched for a while). It happens when the active pool becomes bigger than the inactive pool! When there are more active pages than inactive ones, the kernel scans the active pages, and demotes a few of them to the inactive pool. Some time later, if there are still more active than inactive pages, it will do it again. It will go on until the balance is restored. However, at the same time, your app is running, and accessing memory; potentially moving inactive pages back to the active pool.

What does it mean? The bottom-line is the following: you should look at the active:inactive ratio. If this ratio is big (e.g. 200 MB of active memory vs. 20 MB of inactive memory), it means that the system is under heavy pressure. It’s constantly moving pages from active to inactive (to meet the 1:1 ratio), but the activity of your app is constantly moving pages back from inactive to active. In that case, it would be wise to scale verticaly, to achieve better I/O performance (since more data will fit in the cache). As you add more memory, the ratio will lower, and get closer to 1:1. A ratio of 1:1 (or even lower) means that the system is at equilibrium: it has moved all it could to inactive memory, and there was no strong pressure to put things back into active memory. You want to get close to this ratio (at least if you need good I/O performance).

On the new dashboard, active and inactive memory pools are shown in respectively medium-blue and light-blue shades, to highlight the fact that they are still important, but less than the (darker) resident set size.

Free Memory

Well, that one at least doesn’t deserve a long, technical explanation! If the metrics show that your app consistently has a leeway of free memory, you can definitely consider scaling down by that amount.

Warning: even if it’s often said that “free RAM is wasted RAM”, be wary of spikes! Take, for instance, a 1 GB Java app, which constantly shows 200 MB of Free Memory. Before scaling down to 800 MB, make sure that it is not experiencing occasional spikes that consumes that Free Memory! If you scale down, your app will be out of memory during the spikes, and will most likely crash. Also, remember that the long-term graphs (like the 7-days and 30-days trends) show average values; meaning that short bursts will not show up on those graphs. The metrics sample rate is 1 data point per minute; and that’s about the resolution that you can get on the 1-hour and 6-hours graphs. This means that unfortunately, short spikes (less than one minute) won’t appear on any graph.

On the new dashboard, the free memory in shown in light grey.

Putting It All Together

This is a lot of new information, but the new dashboard should make it very easy for you to figure out the appropriate vertical scaling for your application.

  • For code services, make sure that the Resident Set Size (dark blue) never maxes out the available memory. If it gets close to it, you should add more memory before you receive out-of-memory notifications. Conversely, do not hesitate to cut through the Free Memory and the Inactive Page Cache (grey and light blue areas). The Page Cache will typically be small compared to the Resident Set Size.
  • For database services (and static services), the previous rule applies as well, but the Page Cache (both Active and Inactive) will very likely be much bigger, and you will have to pay attention to that, too. As a rule of thumb, compare the Active and Inactive amounts during peak times. If Active is bigger than Inactive, your memory usage is close to being optimal. If they are equivalent (or if Inactive if larger), it means that you can scale down a little bit. This should be an iterative process: scale down, wait for memory usage to stabilize, check again, and repeat until the Active pool starts being larger.

We hope that the new dashboard can help you to make informed scaling decision, and cut down significantly on your dotCloud bill!

 

Posted on by

Dear dotCloud Customers,

We are going open-source.

It has been a wild week for dotCloud. Of course as we prepared to open-source Docker, the container technology that powers the platform, we hoped it would be well received, like ZeroRPC and Hipache before it. But nothing could have prepared us to the magnitude of the response. Now, 6 days, 50,000 visits, 1000 github follows and 300 pull requests later… we think we get the message. You want an open-source dotCloud – and we’re going to give it to you.

Today, as the first step in our new open-source strategy, we are announcing an important change to our free Sandbox. In the coming weeks we will hand it over to the community as an open-source project which can be deployed and hosted anywhere. As part of this transition we will be sunsetting our free hosting tier – see below for details. The resources freed by this transition will be re-invested in our open-source roadmap.

I want to emphasize that this transition does not affect our Live and Enterprise flavors, and it does not change our business model. Our core competency is and will continue to be the operation and support of large-scale cloud services, for tens of millions of visitors, 24 hours a day, every day. We intend to continue expanding that business, and we believe the best way to do that is by embracing open-source.

1. Going open source

Our approach to open-source is simple: solve fundamental problems, one at a time, with the simplest possible tool. The result is a collection of components which can be used separately, or combined to solve increasingly large problems.

So far dotCloud’s open-source toolbox includes:

  • ZeroRPC, a communication layer for distributed services;
  • Hipache, a routing layer for HTTP and Websockets traffic;
  • Stack.io, a communication framework for real-time web applications
  • Docker, a runtime for linux containers.
  • Recipes for automatically deploying NodeJS, Django, Memcache and dozens of other software components as cloud services.

All these components are already available, and the open-source community is using them to build alternative implementations of dotCloud’s development sandbox. We want to make that even easier by open-sourcing the remaining proprietary components – including our uploader, build system, database components, application server configuration, and more.

To learn more about future open-source announcements, follow the Docker repository and join the Docker mailing list.

 

2. Sunsetting the hosted sandbox

In order to properly focus resources on our ongoing open-source effort, we will be phasing out the hosted version of the free Sandbox. Going forward, the recommended way to kick the tires on dotCloud will be to deploy a Live dotCloud application. For your existing Sandbox applications, we can provide an easy upgrade. If you don’t feel ready to pay us quite yet, take a look at what the community is building.

Below is a calendar of the sunset. As usual, our support and ops team will be happy to assist you in every way we can during the transition.

 

Date Change to Sandbox
April 8th (no change)
April 22nd All Sandbox applications will be unreachable via HTTP. You can still access them via SSH to download your code and data.
April 25th All Sandbox applications will be destroyed.

Note that we’ve pushed-out the sunset dates since first posting this blog. We’ve removed the ‘no push’ week of April 8 and extended HTTP access to the 22nd. 

How to Graduate from the Sandbox

We’ve made it easy for you to change your Sandbox application to a Live flavor if you want to keep it running on the dotCloud platform:

  1. add your billing information to your account and
  2. file a support ticket telling us which applications to migrate. Please use your account email address and give the full URLs to the applications.
  3. We’ll do the rest.

If you don’t want to move to a paid service, you can use several techniques to download your data and files before they are destroyed.

For those of you who have been using the Sandbox as staging for paid applications, we’re sorry for the inconvenience. We hope our hourly billing will help keep your staging and testing costs down, and that developing in a paid service will ease testing related to scaling.

Looking Back, Looking Forward

We want to thank you, our sandbox users, for trying out the dotCloud platform. We hope that you will enjoy experimenting with our open-source version, discovering the awesome features of our Live flavor, or both!

We look forward to helping you be the most awesome and productive developers out there.

Happy hacking!

/Solomon Hykes

CEO, dotCloud

Posted on by

ClubbingOwl_COlogo_purple

Things in nightlife are very subjective because it is a business based off of people first, and products (alcohol) come second, so it is hard to build an algorithm to replicate the job of an operator or doorman as far as reservations via a website go” @NYNightLife

The Bar and Nightclubs industry is a $23Bn fragmented industry with high turnover. IBISWorld’s Bars & Nightclubs market research reported that there are approximately 65,774 family-owned and operated businesses in US, with 98% of them employing fewer than 50 employees. The competition for clientele is extremely keen, especially with high concentrations of clubs in metropolitan cities.

It is tougher for nightclub owners than restaurant owners to turn a profit as there are fewer hours of operations and fewer days of operations per year. To add to the problem, nightclub clientele tend to occupy tables until closing and /or occupy their tables longer than dining in restaurants which means an empty table is lost revenue.

According to Chef’s Blade, there are many fixed costs that nightclub owners cannot change such as rent, equipment, insurance, inventory, payroll, and others. Clubbing Owl aims to provide   a full suite of venue management and outbound marketing software to nightclub owners so that they can positively impact cash flow.

CheckIn_largeUnlike other traditional club management software that serves back office, Clubbing Owl is designed to serve 3 communities – club-goers, nightclub owners, and promoters.

For club-goers, Clubbing Owl’s platform can confirm guest admissions through SMS text messaging. The system is integrated in real time with guest list management so that no guests is ever turned away at the door. The integration with Facebook allows Clubbing Owl to update the club-goers’ Facebook status once they have been confirmed. The status updates not only let their friends know about the clubs they frequent but also allow club owners and promoters to tap into their guests’ network of friends.

For promoters, Clubbing Owl can help promoters with their guest list management. Promoters can send SMS communication to club-goers as soon as they are confirmed on the guest list.

For nightclub owners, Clubbing Owl provides live chat so that the entire staff and extended team of promoters can communicate in real time using smartphones and tablets. Clubbing Owl’s Host Check-in app is also synchronized with guest confirmation.

Continue reading →

Posted on by

PyCon 2013 March 13-21 in Santa Clara, CA

We couldn’t be more excited for PyCon 2013!

If you’re new to PyCon we suggest catching up with PyDanny’s Beginner’s Guide to PyCon. It’s a 4-part series but his most recent posts cover the actual conference days. Here’s his guide to Friday and Saturday events.

Open Spaces

Open spaces are a way for people to come together to talk about topics, ideas or whatever they want. There’s a board by the registration booth where you can schedule an open space.

The open space schedule is like an un-conference. Anyone can suggest a topic, claim a room and dazzle attendees. You can find the tentative schedule here.

Team dotCloud will have our own open space on Saturday night from 9-10pm in room 202 to showcase “Buildbot on dotCloud”.

Buildbot on dotCloud

Continuous integration and testing is critical to application performance. At dotCloud, we have implemented Buildbot at a large scale to make our platform more reliable and robust. You should too.
In this open session, dotCloud engineer Daniel Mizyrycki will share how we implemented Buildbot at a large scale within dotCloud. He will also show how to easily integrate Buildbot as a service on dotCloud.
Ultimately we will open-source this project on GitHub.

Plus a special Lightning Talk….

We have been working on something big here at dotCloud and we can’t wait to unveil it at a Lightning talk session during PyCon.

Stop by booth #157 for more details and to meet with our engineers.

Posted on by

logo

dotCloud gave us the solid and flexible abstraction layer we needed to get our business off the ground. We went from a working prototype to a professional product in just under four months.” Brian Schwartz, Founder & CEO

Titan modernizes traditional IT procurement by taking the process online through a competitive marketplace similar to what NASDAQ has done for institutional trading by providing a view into market participants’ quotation activity. By enabling the most qualified local suppliers to compete for IT projects nationwide, companies can now get the highest quality IT services for the best possible price. The company name comes from the Greek gods. Titan represents incredible strength, and one can’t spell Titan without “IT”.

The founders of Titan have a deep background in private equity and enterprise IT procurement. Since most companies lack expertise in technology, large IT purchases are often made with insufficient information, which results in non-competitive pricing or overpaying. This is in stark contrast to financial trading transactions where market efficiency prevents sellers from charging more than fair market price.

Envision a restaurant chain looking to procure software to optimize their inventory management operations. Generic software isn’t going to bring enough efficiency to their unique operational structure and hiring a local supplier for ongoing customizations to make it fit is an expensive and endless endeavor. Alternatively, a global supplier can build custom software to the exact specifications, software that will scale as the operations grow more complex, but add a prohibitive premium over development costs.

Titan eliminates this tradeoff between quality and price by allowing companies to bid out their IT projects in a competition where only the qualified suppliers can participate. As a result, companies can get high quality IT resources that meet their requirements and at the fair market price.

How Titan Works

Titan lets companies post their IT project along with any requirements, and then qualified suppliers have 2 weeks to submit competitive bids. Once the winning bid is chosen, Titan processes the work contract and handles milestone payments through their escrow service. It’s a win-win for buyers and suppliers, and is 100% free to use.

titan_product_screenshotTitan specializes in the supplier due-diligence process, which is particularly important to get right when it comes to large IT projects. In order to bid, suppliers must prove they are both financially secure and qualified for the particular project. Titan’s qualification process includes performing annual business credit checks, interviewing the team, and verifying past work references. For example, when a supplier makes a claim on Titan to have worked with a Fortune 500 client, this means that Titan has already verified this claim with positive references provided by the supplier.

Continue reading →

Posted on by

A couple weeks ago, I presented “Distributed, Real-time Web Apps with stack.io” at San Francisco’s February Cloud Mafia Meetup. If you’d like to learn more about dotCloud’s stack.io project you can download the slides and view a short demo video here.

About stack.io

stack.io is an open-source communication framework that allows to rapidly build real-time web applications with a strong RPC flavor.

It possesses two core supporting technologies. The ZeroRPC library on one hand lets us build a robust service-oriented architecture on the back-end. This makes it simple to decompose complex code into functionally simple components in a flexible, language-agnostic way. The socket.io library, on the other hand, enables real-time communication with web clients through the use of  WebSockets (and gracefully degrades for older or less capable browsers).

stack.io also provides powerful functionality on top of its RPC layer, such as streaming responses, built-in authentication and request middlewares.

View the Slides

View the Live Demo

More information

See our website for documentation, and check out the source code on GitHub.

About Joffrey

Joffrey is a software engineer at dotCloud. After having worked on several projects involving real-time communication in node.js, including one in partnership with Salesforce Europe, he joined dotCloud to work on a real-time communication framework that would ultimately become stack.io
He has a masters degree in computer science from the French engineering school EPITA.

Check out his GitHub repo at https://github.com/shin-

Posted on by

logo-blue

“With dotCloud, AirportChatter was able to set up the backend systems in 2 weeks so that we can begin coding by Week 3.”  Ygor Lemos, CTO AirportChatter

AirportChatter was founded in 2012 by four travelers living across three continent  - North America (Toronto and Miami), South America, and Australia. The company focuses on two pain points for frequent air travelers, the lack of information and the lack of time.

Not just a directory of ATMs, duty-free shops, food court, merchants, AirportChatter is becoming the one-stop API for all airport transactions. Travelers can access the airport’s activity feeds, browse restaurant menus, redeem retailer and restaurant coupons, and share ratings and photos right directly from their mobile device. The first supported platform from AirportChatter was IOS and within 2 weeks of their launch in December 2012, 14,000 IPhone users have already signed up.

airportsAirportChatter provides services for 30+ US airports today, with plans to service up to 80 airports by mid-year. AirportChatter started  integrating with US airports initially because application programming interfaces (APIs) for those airports already exist. For example, integration with the Federal Aviation Agency (FAA) provided weather information to AirportChatter. In the upcoming months, AirportChatter will be customizing their API extensions to talk to the European and Asian airports because those APIs do not yet exist.

AirportChatter’s Tech Stack

Ygor Lemos, their CTO remarked that small engineering teams could potentially benefit from working with a PaaS. If he had to starting from scratch with instances from AWS, the tiny engineering team (of one) would have taken up to two months just to set up the infrastructure before any code can be written.

“With dotCloud, scaling AirportChatter to support tens of thousands of mobile users happened almost instantly.  Engineering cycles that would have gone to configuring the load balancers are better used in software development.” says Lemos. With a few commands on the dotCloud CLI, they can scale the app from a few instances to hundreds of instances. Two months post launch, they have already released another feature called Radar which runs on top of AirportChatter. The Radar feature allows users to schedule ad hoc social and business meetings before boarding or while waiting for their next flight.

cAirportChatter actively monitors HTTP response times because mobile users tend to want instantaneous access. dotCloud’s Dashboard monitors the application and provides AirportChatter with granular views of the HTTP traffic from the last hour, last 24 hours, last week, last month which means any delay in the system can be detected immediately.

Continue reading →

Posted on by

tsd-cover

I have known Danny Greenfeld (pydanny) for a few years now, I have read his blog, watched some of his talks, and even was lucky enough to work on a project with him. When I heard that he and his fiancée Audrey Roy  were writing a book on Django best practices, I read it the first chance I could.

The book is called Two Scoops of Django, and it is currently available as an early access alpha version in ebook form. If you buy it now it will only cost you $12.00, and you will also get the final version of the book when it comes out. To find out more, or to buy the book head over to their website, http://django.2scoops.org.

The book is based on the soon to be released Django 1.5, and it covers everything from installation to deployment. If you are new to Django and want to learn it, this wouldn’t be the book that you read first, they are expecting that you have at least some Django knowledge going in. The book is targeting folks who already know Django, and want to write better Django code. It’s written in reference form, where each chapter stands on it’s own. If you have a question about the best way to do a certain type of model go to the models chapter, a question about templates, go to the templates chapter, etc. I personally like books like this, because it allows you to pick it up, find your answer and get back to work quickly.

Even though the book isn’t for beginners it doesn’t mean they shouldn’t read it. Once you have a good understanding of what Django is, and you are starting to write your application, it would be good to go over the different sections of the book to see what the best practices are for that section of code you are working on.

I don’t know about you, but I learn best by example, and that is what this book does, it gives you lots of examples for all the common situations you come across when writing a Django application. This allows you to learn, from the beginning, the best approaches to writing a Django application, and lets you skip all of the mistakes your normally make along the way. I wish they had this book when I started using Django.

In the book they go into the different ways to deploy your Django application. They mention dotCloud as a possible deployment solution, which is pretty cool. But, they don’t give you too much information on how to deploy your application to dotCloud. I can understand why, this is a book, and because deployment processes change often, they didn’t want to date their book, and have the information be wrong. So, if you read the book and want to know more about how to deploy your Django project to dotCloud, I would recommend reading our deploying your Django project to dotCloud tutorial , which will guide you through the process of getting your Django project up and running on dotCloud. The tutorial is currently based on Django 1.3 and 1.4, but we will update it to include Django 1.5, once it is officially released.

I have been programming in Django for over 5 years now, so I wasn’t sure how much new stuff I was going to be able to pick up, but I was surprised that I was able to pick up a few new tips and techniques. One chapter I really liked was the chapter on Class Based Views (CBVs). I have never been a fan of CBVs since they came out, and I think that was because the documentation wasn’t really good, and I didn’t see how they were better then the functional views. After reading the chapter, and reading the resources they recommend. I have a much better understanding of what CBVs are, and when, and when not, to use them. For me, that chapter alone is worth the cost of the book.

If you are currently working with Django, or you plan on working with Django sometime in the future, I recommend this book, you won’t be disappointed.

Posted on by

knowsis_logo_colorontransparentbackground_small

dotCloud has really proven to be valuable here as we can just spin up a new service without having to worry about installing frameworks, libraries or other services.”  Mark Unsworth, CTO and Co-Founder Knowsis

dotCloud sat down with Mark Unsworth of Knowsis to understand how his company can extract value from social media chatter to give traders a method to decipher trends in the equity and futures market using Big Data. 

mark

dotCloud: How did you come up with the company name?

Mark: There was a lot of searching for a name, as I guess is the case with most startups these days, due to the lack of decent available domain names. Someone came up with “gnosis” which is the Greek noun for knowledge. So we took a slight twist on that which we thought was probably easier to read. And the domain was available.

What was the inspiration behind Knowsis?

My co-founder Oli Freeling-Wilkinson worked as an investment banker for many years and has a deep rooted interest in behavioral finance; he saw the growth in social media and thought it could offer the finance industry an effective way of quantifying the mood of the crowd. We talked about the idea regularly for a year or so before we finally started the company. When we founded Knowsis the original plan was to build a subscription product that traders could sign up to use and we had planned to use one of the many existing social media analytics companies to provide the data. However, we found that none of these existing solutions worked for the finance vertical in terms of getting the relevant content or understanding the terminology. We decided that it would make more sense if we built our own finance focused solution and initially provide the analytics data via an API.

How is Knowsis different from crowdsourcing?

We are crowdsourcing in a sense, but not in the traditional way. We’re not specifically asking a group of people for their opinions/predictions on the assets we track so we feel that the views are more candid. The other problem with traditional crowdsourcing platforms is you are limited by the number of users of that platform. Since we are platform agnostic we get a much wider view of the market’s mood. Our approach offers its own challenges as we are constantly striving to make our systems better at finding and classifying the relevant content from the ever growing wealth of publicly broadcast data that’s out there.

How is Knowsis better than the typical daily aggregate of public social media posts?

Raw social media feeds contain a lot of noisy and irrelevant data and there’s no easy or quick way to figure out whether comments actually reflect the majority. There’s also the issue of relevance; we really focus on the information that we believe will affect the share price, so someone saying “Apple Inc stock is overvalued since the launch of the iPhone 5“ is far more important than someone just saying “I just went to the Apple Store and the iPhone 5 was out of stock”. The other problem is spam. Recently there has been a couple of well reported cases where spurious tweets have caused a significant shift in a stock price. By aggregating the data and focusing on the mood of the crowd you aren’t likely to get caught out by someone that may be tweeting in order to game the market. Our algorithms also look beyond the content and at the source, we are able to identify this type of spam by scoring the financially relevant information for its reliability.

slider_macbook

How does Knowsis work?

We use machine learning and natural language processing to analyze content as they get posted to online social media services (Twitter, Facebook etc), blogs, forums and news sites. We then aggregate the analyzed content into a set of defined metrics which we can provide via our API. It sounds quite simple but there is a lot going on behind the scenes in order for us to classify the massive amount of information that we are dealing with.

How do you engineer the Knowsis platform?

I’ve really focused on keeping us as lean as possible. Our Jenkins CI server was the first thing I set up, even before writing any code. We commit to source control regularly, write tests for (almost) everything and because of this we can automate our deployments to live several times per day. With regards to the architecture, we follow the 12 factor app methodology which I find fits really well with the dotCloud platform.

Continue reading →

Posted on by

At dotCloud, the entire engineering team have daily rotations in customer support. When reporting for support duty, a question that I get often is “how can I optimize my memory usage?”. And since our pricing model is calculated based on memory (RAM) consumption, it comes to no surprise that many customers ask us “why does my app use so much RAM?”. Or that they are looking for answers as to how they can reduce the memory footprint of their app, which is quasi-synonymous to the question “how can I reduce my bill?”

There is no “TL,DR” on this matter. Memory usage is the product of several complex factors. Reducing the memory footprint requires a lot of technical knowledge and understanding. But after reading this article, you should have some understanding of the techniques used for memory optimization.

And, the good news is that this information is applicable for apps running on dotCloud, but also to virtually all apps running on any hosting platform.

Know Your Memory

Before talking about reducing memory usage, let’s make sure we have a common understanding of what memory is used for. For simplicity, we will talk about 3 types of memory: program memory, data memory, and kernel memory.

Application developers generally think of “program memory” which is the type of memory used for computation. If you have a Computer Science background, that’s what we call “heap” and “stack”. When you generate a thumbnail from a high-resolution photograph, you may need to load the original into memory before executing the resize algorithm. When you send a request to an external API which sends back a large result in e.g. JSON or XML, the result will have to be parsed. Many parsers require loading the whole result in memory before actually processing it. When your app is a web app or web service (a common use case for many of our readers), the web server running the app would need a bit of memory to store the state of each client connection, parse its HTTP headers, maybe buffer some output. (In the latter case, there will also be some per-connection kernel buffers involved in the process.)

The second type of memory is “data memory”, or “cache”. Data memory or “cache” corresponds to data which has been read from disk or will be written to disk shortly. There is a huge performance difference between memory and disk. RAM is typically 100x to 1000x faster than disk. Putting all your data into memory will get you blazing fast performance. However, there is also a significant cost difference between memory and disk. Your operating system and/or your database will make use of the amount of memory given to the application. However, you will want to make sure that the most-often requested data stays in memory for faster access. ”Data memory” includes not only the data that you read and write to disk but also your program’s dynamically-loaded libraries.

And finally, the third type is “kernel memory”. That’s a broad category for all the memory needed by your system to fulfill its duties such as special-purpose buffers of device drivers, low-level system data structures and others. It is not easy to dissect this memory without good knowledge of the inner working of your system kernel. It is a challenge to make adjustments and tuning for this memory. Fortunately, except in rare cases, this memory usage remains low in proportion to the other types of memory.

Continue reading →