Language Selection

English French German Italian Portuguese Spanish

Open Source to the Rescue

Filed under
OSS

Who says open source can’t measure up to commercial software for mission-critical applications? Far from being a mere quick fix or low-cost alternative, open source software is helping real-world companies solve their most pressing IT problems.

Perhaps no more dramatic example exists than pioneering social networking site Friendster. When Friendster launched in March 2003, no one imagined that within two years the site would reach 60 million page views per day.

Unfortunately, as the site’s traffic increased, so did its performance issues. The problem, in essence, was that Friendster had unexpectedly become a phenomenon.

“When I arrived it was a crisis point — absolutely, all day, every day,” says Chris Lunt, Friendster’s director of engineering, who joined the company in the summer of 2003. At that time, he says, Friendster’s architecture was nearly breaking beneath the traffic load.

“[Friendster] had taken off much faster than anyone could anticipate,” Lunt says. “We had our millionth user [when] the site had been up only six months. The thing was overwhelmed.”
Friendster’s performance problems needed to be solved, fast. Rather than stick to the paved road of commercial software, however, the company’s engineers took a major risk by betting on the open source application stack known as LAMP, which consists of — and is named for — the Linux OS, Apache Web server, MySQL database, and PHP (PHP: Hypertext Preprocessor) scripting language.

Fortunately, that gamble paid off. LAMP not only allowed Friendster’s engineers to scale the site’s architecture to address its unwieldy growth, but along the way, they implemented creative configurations that brought the LAMP technologies themselves to a new level.

In founding Friendster, Chairman Jonathan Abrams sought to create an online network through which friends could connect with friends. When it launched, the service was powered by a Java back end running on Apache Tomcat servers with a MySQL database. That original architecture was soon crushed by the coming load of traffic.

During the summer of 2003, Friendster was plagued by performance issues. Often, the millions of users pounding the site where unable to access it, and when they could, results were inconsistent from page to page. User profile changes failed to show up because of lags in the distributed architecture, and messages were dropped.

“If you had a huge network [of friends], you couldn’t search it because just building your list and comparing to the network took longer than the browser would allow you to wait,” says Dathan Pattishall, senior database and software engineer at Friendster. Pattishall joined the company in November 2003 to tackle the site’s database issues.

Tomcat and Java weren’t the problem so much as the fact that the site’s back end was not architected to accommodate millions of users. Friendster had grown to such a huge extent that simply throwing more hardware at the problem wasn’t enough. The site had to be re-engineered to make better use of the hardware and applications.

Of course, that was easier said than done. At the time, Friendster’s IT team consisted of two engineers, and the challenges they faced were daunting.

Full Story.

More in Tux Machines

Security Leftovers

Leftovers: BSD

  • BSD Mag: Understanding Unikernels by Russell Pavlicek
    The number of tasks which lend themselves to being unikernels is larger than you might think. In 2015, Martin Lucina announced the successful creation of a “RAMP” stack. A variant of the common “LAMP” stack (Linux. Apache, MySQL, PHP/Python), the “RAMP” stack employs NGINX, MySQL, and PHP each built on Rumprun. Rumprun is an instance of a Rump kernel, which is a unikernel system based on the modular operating system functions found in the NetBSD project. So even this very common solution stack can be successfully converted into unikernels.
  • Summary of the preliminary LLDB support project
    Operating systems can be called monitors as they handle system calls from userland processes. A similar task is performed by debuggers as they implement monitors for traced applications and interpret various events that occurred in tracees and are messaged usually with signals to their tracers. During this month I have started a new Process Plugin within LLDB to incept NativeProcessNetBSD - copied from NativeProcessLinux - implementing basic functionality and handling all the needed events in the MonitorCallback() function. To achieve these tasks, I had to add a bunch of new ptrace(2) interfaces in the kernel to cover all that is required by LLDB monitors. The current Process Plugin for NetBSD is capable to start a process, catch all the needed events correctly and if applicable resume or step the process.
  • NetBSD Making Progress On LLDB Debugger Support
    NetBSD developers have been implementing the relevant interfaces needed for the LLVM debugger to effectively monitor and work on the operating system. As part of that they have also improved some of their own documentation, provided new ptrace interfaces, and more. Those interested in LLDB and/or NetBSD can learn more about this debugging work via this NetBSD.org blog post.

Firefox 51 Released With FLAC Audio Support, WebGL 2.0 By Default

Firefox 51.0 just hit Mozilla's FTP servers for those wanting the latest version of this open-source web-browser. Firefox 51 isn't a big feature release for end-users but notably does have support for FLAC audio, at long last! Great to see the web browsers finally shipping support out-of-the-box for this open-source audio codec. Read more

Intel Core i3 7100 Kabylake Linux Benchmarks

Last week I began delivering Linux Kabylake benchmarks with the Core i5 7600K while this week I finally am set to receive the Core i7 7700K. But for those curious how Kabylake is looking on the low-end, I picked up a Core i3 7100 as currently the cheapest Kabylake desktop processor. Here are some initial Linux benchmarks of this Core i3 processor on Ubuntu Linux. Read more