At the Forge - Memcached
One of the watchwords for modern Web developers is scalability. Whether we're following the latest news about Twitter's servers or writing our own applications, developers always are thinking about whether their system will be scalable.
This issue has been particularly prominent during the spring and summer of 2008, as Ruby on Rails (my preferred platform for Web development) has been criticized for its use of RAM and its relatively slow execution speed. The massive server problems that Twitter experienced during the first half of 2008 were widely described as stemming from Twitter's use of Rails (despite denials from Twitter's technical team) and led to speculation that Rails cannot be used for a scalable application. One of the hosts of the weekly RailsEnvy podcast makes a point of sarcastically saying that “Rails doesn't scale” in each episode, because it was said so frequently.
There's no doubt that Rails is more resource-intensive than many other application development frameworks. This is partly due to the need for improvements in the Ruby language itself—improvements that look like they'll be available within the coming year. And, it also is true that the Rails framework uses more CPU and memory than some of its counterparts, such as Django, because of the nature of the features that it offers.
But, there's a difference, I believe, between calling Rails resource-intensive and calling it inherently unscalable. Scalability has more to do with the architecture and design of an application, allowing it to grow naturally from a single box containing both the Web and database servers to a network of servers. A Web application written in C might execute very quickly and, thus, handle a larger load on a single server, but that doesn't mean the application is inherently more scalable. At a certain point, even an efficient C program will reach its capacity, and if it isn't designed with this in mind, the more efficient application will be the less scalable one.
So, I tend to think about scalability as an architectural problem, one that ignores the specific programming language in which an application is implemented, and which is different from the issue of execution speed and efficiency. You can have highly scalable programs written in an inefficient framework, but it does take a bit more discipline and requires that programmers think carefully about the way they are writing the code. Even if you're starting on a single computer, designing the software in a scalable way allows you to distribute the load (and tasks) across a number of specialized servers.
One of the most important issues having to do with scalability actually has little or nothing to do with the Web application framework on which the program is written. Most modern Web applications use a relational database for persistent data storage, which means that the database server can be a bottleneck. Even if the database server isn't pushing its limits, the fact is that it takes time for a relational database to process a query, retrieve one or more appropriate rows and send them back to the querying application.
If your application is highly dynamic, it might use as many as a dozen SQL calls for each page, which will not only stress your database, but also significantly reduce the speed with which you can service each HTTP request. Longer request times mean that your users will be drumming their fingers longer and that your server will need more processes to handle the same number of requests.
One solution is to use multiple database servers. There are solutions for hooking together multiple servers from an open-source database (for example, PostgreSQL or MySQL), not to mention proprietary (and expensive) solutions for commercial databases, such as Oracle and MS-SQL. But, this is a tricky business, and many of the solutions involve what's known as master-slave replication, in which one database server (the master) is used for data modification, and the other (the slave) can be used for reading and retrieving information. This can help, but it isn't always the kind of solution you need.
But, there is another solution—one that is simple to understand and relatively easy to implement: memcached (pronounced “mem-cash-dee”). Memcached is an open-source, distributed storage system that acts as a hash table across a network. You can store virtually anything you like in memcached, as well as retrieve it quickly and easily. There are client libraries for numerous programming languages, so no matter what framework you enjoy using, there probably is a memcached solution for you.
This month, we take a quick look at memcached. When integrated into a Web application, it should help make that application more scalable—meaning it can handle a large number of users, spread across a large number of servers, without forcing you to rewrite large amounts of code. Version 2.1 of Ruby on Rails went so far as to integrate memcached support into the framework, making it even easier to use memcached in your applications.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide