Replacing the cache replacement algorithm in memcached

In this post we delve into a reworking of memcached’s Least Recently Used (LRU) algorithm which was made default when 1.5.0 was released. Most of these features have been available via the “-o modern” switch for years. The 1.5.x series has enabled them all to work in concert to reduce RAM requirements.

When memcached was first deployed, it was typically co-located on backend web servers, using spare RAM and CPU cycles. It was important that it stay light on CPU usage while being fast; otherwise it would affect the performance of the application it was attempting to improve.

Over time, the deployment style has changed. There are frequently fewer dedicated nodes with more RAM, but spare CPU. On top of this web requests can fetch dozens to hundreds of objects at once, with the request latency having a greater overall impact.

This post is focused on the efforts to reduce the number of expired items wasting cache space, general LRU improvements, as well as latency consistency.

https://memcached.org/blog/modern-lru/

Advertisements

Postcards from Lambda @ the Edge

I first saw Lambda@Edge at re:Invent a couple of years back and wasn’t sure what to make of it. The demo showed how you could manipulate http headers in-flight but the audience was in a post-lunch sugar-crash full of ‘so what?’. It wasn’t the presenter’s fault —some next-level concepts just weren’t landing their punches with the crowd. I mean, who needs to interfere with the CDN, right?

Recently we started a CloudFront-heavy project that performs all sorts of optimization voodoo for webpages. That’s when I remembered back to the Lambda@Edge presentation and a few lightbulbs started to flicker. To test this, we quickly moved some code into functions at The Edge and saw some blistering performance gains. While there was nothing particularly amazing about the code we wrote, getting it working has been a trial like never before. Let’s cover the gotchas before the gold.

https://medium.com/@jbesw/postcards-from-lambda-the-edge-11a43f215dc1

Why We Decided to Rewrite Uber’s Driver App

This article is the first in a series covering how Uber’s mobile engineering team developed the newest version of our driver app, codenamed Carbon, a core component of our ridesharing business. Among other new features, the app lets our population of over three million driver-partners find fares, get directions, and track their earnings. We began designing the new app in conjunction with feedback from our driver-partners in 2017, and began rolling it out for production in September 2018.

In early 2017, Uber made the decision to rewrite our driver app. This is the sort of decision that Joel Spolsky, the CEO of StackOverflow, once called “the single worst strategic mistake that any software company can make.”

Rewrites are incredibly risky, resource-intensive, and take a long time to deliver a tangible benefit for users. For this particular rewrite, hundreds of engineers contributed in some capacity, not to mention designers, product managers, data scientists, operations, legal, and marketing. In practice, our rewrite took a year and a half to implement and roll out globally.

Our case is an extreme example of a question that engineers in all organizations face. If you are an engineer working for a start-up and are considering rewriting some code or a feature, you might ask, “How much of our runway are we burning?” If you are working on a small team in a large organization, you might ask, “Are these changes worth the features we are not building?” A good engineer and a good team will look at these broader questions before they take on the challenge of a rewrite.

So, while the rewrite process involved a number of important technical decisions (to be covered in future articles), the decision to rewrite involved a combination of both technical considerations and broader business concerns. While these questions are hard to answer, good answers to the above questions will help you justify a rewrite to your organization or team.

Ultimately, these decisions do not get made in a vacuum. We did not make the decision to rewrite the app as a result of theoretical architectural thinking (“our code might be better, if only we…”), but rather as a result of an intensive, three-month research process that involved hundreds of pages of documentation and broad, cross-organizational buy-in. In the following sections, we discuss our decision to rewrite the Uber driver app and what we discovered as a result of this process.

https://eng.uber.com/rewrite-uber-carbon-app/

Making an Unlimited Number of Requests with Python aiohttp + pypeln

This post is a continuation on the works of Paweł Miech’s Making 1 million requests with python-aiohttp and Andy Balaam’s Making 100 million requests with Python aiohttp. I will be trying to reproduce the setup on Andy’s blog with some minor modifications due to API changes in the aiohttp library, you should definitely read his blog, but I’ll give a recap.

UPDATE: Since Andy’s original post, aiohttp introduced another API change which limited the total number of simultaneous requests to 100 by default. I’ve updated the code shown here to remove this limit and increased the number of total requests to compensate. Apart from that, the analysis remains the same.

https://medium.com/@cgarciae/making-an-infinite-number-of-requests-with-python-aiohttp-pypeln-3a552b97dc95

How Harry’s Shaved Off Their Operational Overhead by Moving to AWS Fargate

Broadcast Date: July 25, 2018
Level 200 | Customer Showcase
Harry’s migrated their messaging workload to AWS Fargate to eliminate the responsibility of maintenance of their compute infrastructure. In this tech talk, learn how Harry’s used the seamless integration of Fargate with other AWS services such as CloudFormation, Auto Scaling, and ALB to manage their traffic spikes and reduce their message processing time by more than 75%.
Learning Objectives:
• Learn how Harry’s uses AWS to simplify infrastructure operations
• Learn how AWS Fargate makes it simple to run containers
• Learn how to use AWS services like CloudFormation, Auto Scaling, and Load Balancing with AWS Fargate