Connect with us

LINKEDIN

New Approaches For Detecting AI-Generated Profile Photos

Published

on

new-approaches-for-detecting-ai-generated-profile-photos

Co-authors: Shivansh Mundra, Gonzalo Aniano Porcile, Smit Marvaniya, Hany Farid

A core part of what we do on the Trust Data Team at LinkedIn is create, deploy, and maintain models that detect and prevent many types of abuse. This spans the detection and prevention of fake accounts, account takeovers, and policy-violating content. We are constantly working to improve and increase the effectiveness of our anti-abuse defenses to protect the experiences of  our members and customers. And as part of our ongoing work, we’ve been partnering with academia to stay one step ahead of new types of abuse tied to fake accounts that are leveraging rapidly evolving technologies like generative AI.

With the rise of AI-generated synthetic media and text-to-image generated media, fake profiles have grown more sophisticated. And we’ve found that most members are generally unable to visually distinguish real from synthetically-generated faces, and future iterations of synthetic media are likely to contain fewer obvious artifacts, which might show up as slightly distorted facial features. To protect members from inauthentic interactions online, it is important that the forensic community develop reliable techniques to distinguish real from synthetic faces that can operate on large networks with hundreds of millions of daily users, like LinkedIn. 

In this blog, we will describe how LinkedIn partnered with academia to research advanced detection techniques, provide details on our research, and share our results on how our jointly developed detection technique technique is able to detect 99.6% of a common type of AI-generated profile photos, while rarely–only 1% of the time–misclassifying a real profile photo as synthetic.

Partnering with Academia

As AI-generated faces become increasingly indistinguishable from real faces, academia and industry must collaborate closely on detection solutions. Academia brings expertise on cutting-edge research on detection techniques, while industry possesses a wealth of data, experience with real-world challenges and limitations, and the ability to translate research into production at internet scale. By working together, academia and industry can develop robust solutions for AI-generated photo detection that have a positive real-world impact.

Advertisement
free widgets for website

The LinkedIn Scholars program enables academics to contribute directly to LinkedIn’s vision of creating economic opportunity for every member of the global workforce. LinkedIn Scholars has enabled the LinkedIn Trust Data team and University of California, Berkeley Professor Hany Farid to collaborate on new techniques for AI-generated image detection. This unique partnership enabled the creation of a novel approach for detecting a common type of AI-generated profile photos that is lightweight and highly effective. Our approach is detailed in the full paper that was released at the Workshop on Media Forensics at the 2023 Conference on Computer Vision and Pattern Recognition (CVPR) in June.

See also  Feathr joins LF AI & Data Foundation

Details on Our Research

In our paper, we describe two related approaches that learn to recognize structural differences between AI-generated faces and real faces. We then show how these approaches are highly effective at recognizing synthetically-generated profile photos.

A common technique used to create AI-generated photos is the generative adversarial network (GAN). The structural difference between GAN-generated and real profile photos can be seen in Figure 1 consisting of the average of 400 GAN-generated profile images (left) and 400 LinkedIn profile images (right). The highly regular GAN-generated facial structure is revealed in the clarity of the facial features in the averaged image. The real LinkedIn profile photos have no such regular structure, which results in a blurry averaged image. Our embedding-based detection technique exploits the highly regular structure in GAN-generated photos.

Advertisement
free widgets for website
  • GAN-generated photos

Figure 1: Average of 400 GAN-generated profile images (left) and 400 LinkedIn profile images (right). The averaged image on the left reveals a highly regular GAN-generated facial structure. Our approaches learn simple/compact embeddings to capture the regularities in GAN-generated photos.

We used six data sets consisting of 100,000 real LinkedIn profile photos, and 41,500 synthetically-generated faces spanning five different synthesis engines: StyleGAN1, StyleGAN2, StyleGAN3, Generated.photos, and Stable Diffusion. A representative sample of the generated synthetic faces is shown in Figure 2.

Advertisement
free widgets for website

Figure 2: A representative set of synthetic faces from (a) StyleGAN1, (b) StyleGAN2, (c) StyleGAN3, (d) Generated.photos, and (e) Stable Diffusion. In order to respect member privacy, we don’t show examples of real profile photos.

See also  How LinkedIn Ditched the "One Size Fits All" Hiring Approach for InfoSec and Won

Sharing Our Results

The paper discusses the results from our two embedding-based approaches for distinguishing between synthetic and real profile photos: a learned linear embedding based on a principal components analysis (PCA) and a learned embedding based on an autoencoder (AE). For a baseline comparison, we also create a fixed linear embedding based on a Fourier analysis. The goal of the Fourier-based embedding is to demonstrate that a generic embedding is not sufficient to distinguish synthesized faces from photographed faces, and that the learned embeddings are required to extract sufficiently descriptive representations.

Our low-dimensional embedding models are trained on StyleGAN, StyleGAN2, and StyleGAN3 faces. We test generalization of the models on photos created using Generated.photos and Stable Diffusion. Generated.photos are GAN-synthesized faces generated using a network trained on a proprietary dataset of tens of thousands of high-quality images recorded in a photographic studio. Our approach does somewhat generalize to the GAN-based Generated.photos faces, but it does not generalize to Stable Diffusion faces. The latter is not surprising, because the diffusion-based process does not rely on the same type of training from aligned faces as the GAN-based process. We also report results on the robustness of our technique to geometric transformation attacks. We show that our approach is somewhat resilient to these transformation attacks.

True positive rate (TPR) is the percentage of synthetic photos that are correctly classified as synthetic. False positive rate (FPR) is the percentage of real photos that are incorrectly classified as synthetic. Our approach is able to detect 99.6% (TPR) of synthetic StyleGAN, StyleGAN2, and StyleGAN3 faces, while only incorrectly classifying 1% (FPR) of real LinkedIn profile photos as synthetic. For the benchmark results in our research paper we chose a 1% FPR target, because–for real-world applications on a large professional network–it is important for AI-generated image detection models to catch most of the synthetic images, while only rarely classifying a real image as synthetic.

See also  REACH turns five - Celebrating the power of apprenticeships

We compare our technique to a state of the art CNN-based image-forensic classifier from the academic literature; our approaches outperform the state-of-the-art CNN model. At least one reason for this may be that the CNN-based classifier was trained to detect a synthesized image from any category, whereas we focus exclusively on faces. We also see that while the CNN classifier is somewhat able to detect StyleGAN1 and StyleGAN2 images, it struggles significantly on the most recent StyleGAN3 images.

Please see the full paper for a complete quantitative discussion of our results.

Advertisement
free widgets for website

Conclusions

In our research, we have developed a method to distinguish GAN-generated faces from real faces. We found that a simple model can effectively accomplish this task at a level of performance meeting or exceeding state-of-the-art CNN-based approaches in the academic literature. Our approach takes advantage of the fact that GAN-generated faces have consistent characteristics due to the way they are trained on cropped and aligned faces. We validated our technique on a large sample of synthesized faces spanning five different synthesis engines and real LinkedIn member profile photos to understand the real-world performance.

This cutting-edge research helps LinkedIn continue to improve and increase the effectiveness of our automated anti-abuse defenses to help detect and remove fake accounts before they have a chance to reach our members and customers.

Acknowledgements

This work is the product of a collaboration between Professor Hany Farid and the Trust Data team at LinkedIn. We thank the LinkedIn Scholars program for enabling this collaboration. We also thank Ya Xu, Daniel Olmedilla, Kim Capps-Tanaka, Jenelle Bray, Shaunak Chatterjee, Vidit Jain, Ting Chen, Vipin Gupta, Dinesh Palanivelu, and Milinda Lakkam for their support of this work. We appreciate Siddharth Dangi and Bharat Jain for their valuable technical input while reviewing the paper. We are grateful to NVIDIA for facilitating our work by making the StyleGAN generation software, trained models, and synthesized images publicly available, and for their valuable suggestions.

Advertisement
free widgets for website

Topics

Advertisement
free widgets for website
Continue Reading
Advertisement free widgets for website
Click to comment

Leave a Reply

Your email address will not be published.

LINKEDIN

Career stories: Influencing engineering growth at LinkedIn

Published

on

By

career-stories:-influencing-engineering-growth-at-linkedin

Since learning frontend and backend skills, Rishika’s passion for engineering has expanded beyond her team at LinkedIn to grow into her own digital community. As she develops as an engineer, giving back has become the most rewarding part of her role.

From intern to engineer—life at LinkedIn

My career with LinkedIn began with a college internship, where I got to dive into all things engineering. Even as a summer intern, I absorbed so much about frontend and backend engineering during my time here. When I considered joining LinkedIn full-time after graduation, I thought back to the work culture and how my manager treated me during my internship. Although I had a virtual experience during COVID-19, the LinkedIn team ensured I was involved in team meetings and discussions. That mentorship opportunity ultimately led me to accept an offer from LinkedIn over other offers. 

Before joining LinkedIn full-time, I worked with Adobe as a Product Intern for six months, where my projects revolved around the core libraries in the C++ language. When I started my role here, I had to shift to using a different tech stack: Java for the backend and JavaScript framework for the frontend. This was a new challenge for me, but the learning curve was beneficial since I got hands-on exposure to pick up new things by myself. Also, I have had the chance to work with some of the finest engineers; learning from the people around me has been such a fulfilling experience. I would like to thank Sandeep and Yash for their constant support throughout my journey and for mentoring me since the very beginning of my journey with LinkedIn.

See also  Migration madness: How to navigate the chaos of large cross-team initiatives towards a common goal

Currently, I’m working with the Trust team on building moderation tools for all our LinkedIn content while guaranteeing that we remove spam on our platform, which can negatively affect the LinkedIn member experience. Depending on the project, I work on both the backend and the frontend, since my team handles the full-stack development. At LinkedIn, I have had the opportunity to work on a diverse set of projects and handle them from end to end. 

Advertisement
free widgets for website

Mentoring the next generation of engineering graduates

I didn’t have a mentor during college, so I’m so passionate about helping college juniors find their way in engineering. When I first started out, I came from a biology background, so I was not aware of programming languages and how to translate them into building a technical resume. I wish there would have been someone to help me out with debugging and finding solutions, so it’s important to me to give back in that way. 

I’m quite active in university communities, participating in student-led tech events like hackathons to help them get into tech and secure their first job in the industry. I also love virtual events like X (formally Twitter) and LinkedIn Live events. Additionally, I’m part of LinkedIn’s CoachIn Program, where we help with resume building and offer scholarships for women in tech.

Advertisement
free widgets for website

Influencing online and off at LinkedIn

I love creating engineering content on LinkedIn, X, and other social media platforms, where people often contact me about opportunities at LinkedIn Engineering. It brings me so much satisfaction to tell others about our amazing company culture and connect with future grads. 

See also  LinkedIn Bug Bounty Program - One Year Anniversary of Public Launch

When I embarked on my role during COVID-19, building an online presence helped me stay connected with what’s happening in the tech world. I began posting on X first, and once that community grew, I launched my YouTube channel to share beginner-level content on data structures and algorithms. My managers and peers at LinkedIn were so supportive, so I broadened my content to cover aspects like soft skills, student hackathons, resume building, and more. While this is in addition to my regular engineering duties, I truly enjoy sharing my insights with my audience of 60,000+ followers. And the enthusiasm from my team inspires me to keep going! I’m excited to see what the future holds for me at LinkedIn as an engineer and a resource for my community on the LinkedIn platform.

Advertisement
free widgets for website

About Rishika

Rishika holds a Bachelor of Technology from Indira Gandhi Delhi Technical University for Women. Before joining LinkedIn, she interned at Google as part of the SPS program and as a Product Intern at Adobe. She currently works as a software engineer on LinkedIn’s Trust Team. Outside of work, Rishika loves to travel all over India and create digital art. 

Editor’s note: Considering an engineering/tech career at LinkedIn? In this Career Stories series, you’ll hear first-hand from our engineers and technologists about real life at LinkedIn — including our meaningful work, collaborative culture, and transformational growth. For more on tech careers at LinkedIn, visit: lnkd.in/EngCareers.

Advertisement
free widgets for website
    Continue Reading

    LINKEDIN

    Career Stories: Learning and growing through mentorship and community

    Published

    on

    By

    career-stories:-learning-and-growing-through-mentorship-and-community

    Lekshmy has always been interested in a role in a company that would allow her to use her people skills and engineering background to help others. Working as a software engineer at various companies led her to hear about the company culture at LinkedIn. After some focused networking, Lekshmy landed her position at LinkedIn and has been continuing to excel ever since.

    How did I get my job at LinkedIn? Through LinkedIn. 

    Before my current role, I had heard great things about the company and its culture. After hearing about InDays (Investment Days) and how LinkedIn supports its employees, I knew I wanted to work there. 

    While at the College of Engineering, Trivandrum (CET), I knew I wanted to pursue a career in software engineering. Engineering is something that I’m good at and absolutely love, and my passion for the field has only grown since joining LinkedIn. When I graduated from CET, I began working at Groupon as a software developer, starting on databases, REST APIs, application deployment, and data structures. From that role, I was able to advance into the position of software developer engineer 2, which enabled me to dive into other software languages, as well as the development of internal systems. That’s where I first began mentoring teammates and realized I loved teaching and helping others. It was around this time that I heard of LinkedIn through the grapevine. 

    Advertisement
    free widgets for website

    Joining the LinkedIn community

    Everything I heard about LinkedIn made me very interested in career opportunities there, but I didn’t have connections yet. I did some research and reached out to a talent acquisition manager on LinkedIn and created a connection which started a path to my first role at the company. 

    See also  Career Stories: Learning and growing through mentorship and community

    When I joined LinkedIn, I started on the LinkedIn Talent Solutions (LTS) team. It was a phenomenal way to start because not only did I enjoy the work, but the experience served as a proper introduction to the culture at LinkedIn. I started during the pandemic, which meant remote working, and eventually, as the world situation improved, we went hybrid. This is a great system for me; I have a wonderful blend of being in the office and working remotely. When I’m in the office, I like to catch up with my team by talking about movies or playing games, going beyond work topics, and getting to know each other. With LinkedIn’s culture, you really feel that sense of belonging and recognize that this is an environment where you can build lasting connections. 

    Advertisement
    free widgets for website

    LinkedIn: a people-first company 

    If you haven’t been able to tell already, even though I mostly work with software, I truly am a people person. I just love being part of a community. At the height of the pandemic, I’ll admit I struggled with a bit of imposter syndrome and anxiety. But I wasn’t sure how to ask for help. I talked with my mentor at LinkedIn, and they recommended I use the Employee Assistance Program (EAP) that LinkedIn provides. 

    I was nervous about taking advantage of the program, but I am so happy that I did. The EAP helped me immensely when everything felt uncertain, and I truly felt that the company was on my side, giving me the space and resources to help relieve my stress. Now, when a colleague struggles with something similar, I recommend they consider the EAP, knowing firsthand how effective it is.

    Advertisement
    free widgets for website
    See also  Experiment: Does AI Write Better X (Twitter) Posts Than Humans?

    Building a path for others’ growth

    With my mentor, I was also able to learn about and become a part of our Women in Technology (WIT)  WIT Invest Program. WIT Invest is a program that provides opportunities like networking, mentorship check-ins, and executive coaching sessions. WIT Invest helped me adopt a daily growth mindset and find my own path as a mentor for college students. When mentoring, I aim to build trust and be open, allowing an authentic connection to form. The students I work with come to me for all kinds of guidance; it’s just one way I give back to the next generation and the wider LinkedIn community. Providing the kind of support my mentor gave me early on was a full-circle moment for me. 

    Working at LinkedIn is everything I thought it would be and more. I honestly wake up excited to work every day. In my three years here, I have learned so much, met new people, and engaged with new ideas, all of which have advanced my career and helped me support the professional development of my peers. I am so happy I took a leap of faith and messaged that talent acquisition manager on LinkedIn. To anyone thinking about applying to LinkedIn, go for it. Apply, send a message, and network—you never know what one connection can bring! 

    Advertisement
    free widgets for website

    About Lekshmy

    Based in Bengaluru, Karnataka, India, Lekshmy is a Senior Software Engineer on LinkedIn’s Hiring Platform Engineering team, focused on the Internal Mobility Project. Before joining LinkedIn, Lekshmy held various software engineering positions at Groupon and SDE 3. Lekshmy holds a degree in Computer Science from the College of Engineering, Trivandrum, and is a trained classical dancer. Outside of work, Lekshmy enjoys painting, gardening, and trying new hobbies that pique her interest. 

    See also  Migration madness: How to navigate the chaos of large cross-team initiatives towards a common goal

    Editor’s note: Considering an engineering/tech career at LinkedIn? In this Career Stories series, you’ll hear first-hand from our engineers and technologists about real life at LinkedIn — including our meaningful work, collaborative culture, and transformational growth. For more on tech careers at LinkedIn, visit: lnkd.in/EngCareers.

    Advertisement
    free widgets for website

    Topics

    Continue Reading

    LINKEDIN

    Solving Espresso’s scalability and performance challenges to support our member base

    Published

    on

    By

    solving-espresso’s-scalability-and-performance-challenges-to-support-our-member-base

    Espresso is the database that we designed to power our member profiles, feed, recommendations, and hundreds of other Linkedin applications that handle large amounts of data and need both high performance and reliability. As Espresso continued to expand in support of our 950M+ member base, the number of network connections that it needed began to drive scalability and resiliency challenges. To address these challenges, we migrated to HTTP/2. With the initial Netty based implementation, we observed a 45% degradation in throughput which we needed to analyze then correct.

    In this post, we will explain how we solved these challenges and improved system performance. We will also delve into the various optimization efforts we employed on Espresso’s online operation section, implementing one approach that resulted in a 75% performance boost.

    Espresso Architecture

    Advertisement
    free widgets for website
    • Graphic of Espresso System Overview

    Figure 1.  Espresso System Overview

    Figure 1 is a high-level overview of the Espresso ecosystem, which includes the online operation section of Espresso (the main focus of this blog post). This section comprises two major components – the router and the storage node. The router is responsible for directing the request to the relevant storage node and the storage layer’s primary responsibility is to get data from the MySQL database and present the response in the desired format to the member. Espresso utilizes the open-source framework Netty for the transport layer, which has been heavily customized for Espresso’s needs. 

    Need for new transport layer architecture

    In the communication between the router and storage layer, our earlier approach involved utilizing HTTP/1.1, a protocol extensively employed for interactions between web servers and clients. However, HTTP/1.1 operates on a connection-per-request basis. In the context of large clusters, this approach led to millions of concurrent connections between the router and the storage nodes. This resulted in constraints on scalability, resiliency, and numerous performance-related hurdles.

    See also  Career Stories: Learning and growing through mentorship and community

    Scalability: Scalability is a crucial aspect of any database system, and Espresso is no exception. In our recent cluster expansion, adding an additional 100 router nodes caused the memory usage to spike by around 2.5GB. The additional memory can be attributed to the new TCP network connections within the storage nodes. Consequently, we experienced a 15% latency increase due to an increase in garbage collection. The number of connections to storage nodes posed a significant challenge to scaling up the cluster, and we needed to address this to ensure seamless scalability.

    Resiliency: In the event of network flaps and switch upgrades, the process of re-establishing thousands of connections from the router often breaches the connection limit on the storage node. This, in turn, causes errors and the router to fail to communicate with the storage nodes. 

    Performance: When using the HTTP/1.1 architecture, routers maintain a limited pool of connections to each storage node within the cluster. In some larger clusters, the wait time to acquire a connection can be as high as 15ms at the 95th percentile due to the limited pool. This delay can significantly affect the system’s response time.

    Advertisement
    free widgets for website

    We determined that all of the above limitations could be resolved by transitioning to HTTP/2, as it supports connection multiplexing and requires a significantly lower number of connections between the router and the storage node.

    We explored various technologies for HTTP/2 implementation but due to the strong support from the open-source community and our familiarity with the framework, we went with Netty. When using Netty out of the box, the HTTP/2 implementation throughput was 45% less than the original (HTTP/1.1) implementation.  Because the out of the box performance was very poor, we had to implement different optimizations to enhance performance.

    See also  How to Write AI Art Prompts [Examples + Templates]

    The experiment was run on a production-like test cluster and the traffic is a combination of access patterns, which include read and write traffic. The results are as follows:

    Advertisement
    free widgets for website
    Protocol QPS Single Read Latency (P99) Multi-Read Latency (P99)
    HTTP/1.1 9K 7ms 25ms

    HTTP/2 5K (-45%) 11ms (+57%) 42ms (+68%)

    On the routing layer, after further analysis using flame graphs, major differences between the two protocols are shown in the following table.

    CPU overhead HTTP/1.1 HTTP/2
    Acquiring a connection and processing the request 20% 32% (+60%)
    Encode/Decode HTTP request 18% 32% (+77%)

    Improvements to Request/Response Handling

    Reusing the Stream Channel Pipeline

    One of the core concepts of Netty is its ChannelPipeline. As seen in Figure 1, when the data is received from the socket, it is passed through the pipeline which processes the data. Channel Pipeline contains a list of Handlers, each working on a specific task.

    Advertisement
    free widgets for website
    • Diagram of Netty Pipeline

    Figure 2. Netty Pipeline

    In the original HTTP/1.1 Netty pipeline, a set of 15-20 handlers was established when a connection was made, and this pipeline was reused for all subsequent requests served on the same connection. 

    However, in HTTP/2 Netty’s default implementation, a fresh pipeline is generated for each new stream or request. For instance, a multi-get request to a router with over 100 keys can often result in approximately 30 to 35 requests being sent to the storage node. Consequently, the router must initiate new pipelines for all 35 storage node requests. The process of creating and dismantling pipelines for each request involving a considerable number of handlers turned out to be notably resource-intensive in terms of memory utilization and garbage collection.

    Advertisement
    free widgets for website

    To address this concern, a forked version of Netty’s Http2MultiplexHandler has been developed to maintain a queue of local stream channels. As illustrated in Figure 2, on receiving a new request, the multiplex handler no longer generates a new pipeline. Instead, it retrieves a local channel from the queue and employs it to process the request. Subsequent to request completion, the channel is returned to the queue for future use. Through the reuse of existing channels, the creation and destruction of pipelines are minimized, leading to a reduction in memory strain and garbage collection.

    • Sequence diagram of stream channel reuse
    See also  Migration madness: How to navigate the chaos of large cross-team initiatives towards a common goal

    Figure 3. Sequence diagram of stream channel reuse

    Addressing uneven work distribution among Netty I/O threads 

    When a new connection is created, Netty assigns this connection to one of the 64 I/O threads. In Espresso, the number of I/O threads is equal to twice the number of cores present. The I/O thread associated with the connection is responsible for I/O and handling the request/response on the connection. Netty’s default implementation employs a rudimentary method for selecting an appropriate I/O thread out of the 64 available for a new channel. Our observation revealed that this approach leads to a significantly uneven distribution of workload among the I/O threads. 

    Advertisement
    free widgets for website

    In a standard deployment, we observed that 20% of I/O threads were managing 50% of all the total connections/requests. To address this issue, we introduced a BalancedEventLoopGroup. This entity is designed to evenly distribute connections across all available worker threads. During channel registration, the BalancedEventLoopGroup iterates through the worker threads to ensure a more equitable allocation of workload

    After this change, during registering of a channel, an event loop with the number of connections below the average is selected.

    Advertisement
    free widgets for website
    private EventLoop selectLoop() {  int average = averageChannelsPerEventLoop();  EventLoop loop = next();  if (_eventLoopCount > 1 && isUnbalanced(loop, average)) {    ArrayList list = new ArrayList<>(_eventLoopCount);    _eventLoopGroup.forEach(eventExecutor -> list.add((EventLoop) eventExecutor));    Collections.shuffle(list, ThreadLocalRandom.current());    Iterator it = list.iterator();    do {      loop = it.next();    } while (it.hasNext() && isUnbalanced(loop, average));  }  return loop; } 

    Reducing context switches when acquiring a connection 

    In the HTTP/2 implementation, each router maintains 10 connections to every storage node. These connections serve as communication pathways for the router I/O threads interfacing with the storage node. Previously, we utilized Netty’s FixedChannelPool implementation to oversee connection pools, handling tasks like acquiring, releasing, and establishing new connections. 

    However, the underlying queue within Netty’s implementation is not inherently thread-safe. To obtain a connection from the pool, the requesting worker thread must engage the I/O worker overseeing the pool. This process led to two context switches.  To resolve this, we developed a derivative of the Netty pool implementation that employs a high-performance, thread-safe queue. Now, the task is executed by the requesting thread instead of a distinct I/O thread, effectively eliminating the need for context switches.

    Improvements to SSL Performance

    The following section describes various optimizations to improve the SSL performance.

    Offloading DNS lookup and handshake to separate thread pool

    During an SSL handshake, the DNS lookup procedure for resolving a hostname to an IP address functions as a blocking operation. Consequently, the I/O thread responsible for executing the handshake might be held up for the entirety of the DNS lookup process. This delay can result in request timeouts and other issues, especially when managing a substantial influx of incoming connections concurrently.  

    To tackle this concern, we developed an SSL initializer that conducts the DNS lookup on a different thread prior to initiating the handshake. This method involves passing the InetAddress, that contains both the IP address and hostname, to the SSL handshake procedure, effectively circumventing the need for a DNS lookup during the handshake.

    Advertisement
    free widgets for website

    Enabling Native SSL encryption/decryption

    Java’s default built-in SSL implementation carries a significant performance overhead. Netty offers a JNI-based SSL engine that demonstrates exceptional efficiency in both CPU and memory utilization. Upon enabling OpenSSL within the storage layer, we observed a notable 10% reduction in latency. (The router layer already utilizes OpenSSL.)  

    To employ Netty Native SSL, one must include the pertinent Netty Native dependencies, as it interfaces with OpenSSL through the JNI (Java Native Interface). For more detailed information, please refer to https://netty.io/wiki/forked-tomcat-native.html.

    Improvements to Encode/Decode performance

    This section focuses on the performance improvements we made when converting bytes to Http objects and vice versa. Approximately 20% of our CPU cycles are spent on encode/decode bytes. Unlike a typical service, Espresso has very rich headers. Our HTTP/2 implementation involves wrapping the existing HTTP/1.1 pipeline with HTTP/2 functionality. While the HTTP/2 layer handles network communication, the core business logic resides within the HTTP/1.1 layer. Due to this, each incoming request required the conversion of HTTP/2 requests to HTTP/1.1 and vice versa, which resulted in high CPU usage, memory consumption, and garbage creation.

    To improve performance, we have implemented a custom codec designed for efficient handling of HTTP headers. We introduced a new type of request class named Http1Request. This class effectively encapsulates an HTTP/2 request as an HTTP/1.1 by utilizing wrapped Http2 headers. The primary objective behind this approach is to avoid the expensive task of converting HTTP/1.1 headers to HTTP/2 and vice versa.

    For example:

    Advertisement
    free widgets for website
    public class Http1Headers extends HttpHeaders {   private final Http2Headers _headers;    ….  } 

    And Operations such as get, set, and contains operate on the Http2Headers:

    Advertisement
    free widgets for website
    @Override public String get(String name) {  return str(_headers.get(AsciiString.cached(name).toLowerCase()); } 

    To make this possible, we developed a new codec that is essentially a clone of Netty’s Http2StreamFrameToHttpObjectCodec. This codec is designed to translate HTTP/2 StreamFrames to HTTP/1.1 requests/responses with minimal overhead. By using this new codec, we were able to significantly improve the performance of encode/decode operations and reduce the amount of garbage generated during the conversions.

    Disabling HPACK Header Compression

    HTTP/2 introduced a new header compression algorithm known as HPACK. It works by maintaining an index list or dictionaries on both the client and server. Instead of transmitting the complete string value, HPACK sends the associated index (integer) when transmitting a header. HPACK encompasses two key components: 

    1. Static Table – A dictionary comprising  61 commonly used headers.

    2. Dynamic Table – This table retains the user-generated header information.

    The Hpack header compression is tailored to scenarios where header contents remain relatively constant. But Espresso has very rich headers with stateful information such as timestamps, SCN, and so on. Unfortunately, HPACK didn’t align well with Espresso’s requirements.

    Upon examining flame graphs, we observed a substantial stack dedicated to encoding/decoding dynamic tables. Consequently, we opted to disable dynamic header compression, leading to an approximate 3% enhancement in performance.

    Advertisement
    free widgets for website

    In Netty, this can be disabled using the following:

    Http2FrameCodecBuilder.forClient()    .initialSettings(Http2Settings.defaultSettings().headerTableSize(0));

    Results

    Latency Improvements

    Advertisement
    free widgets for website
    P99.9 Latency HTTP/1.1 HTTP/2
    Single Key Get 20ms 7ms (-66%)
    Multi Key Get 80ms 20ms (-75%)

    We observed a 75% reduction in 99th and 99.9th percentile multi-read and read latencies, decreasing from 80ms to 20ms.

    • Image of Latency reduction after HTTP/2

    Figure 4. Latency reduction after HTTP/2

    We observed similar latency reductions across the 90th percentile and higher.  

    Advertisement
    free widgets for website

    Reduction in TCP connections

      HTTP/1.1 HTTP/2
    No of TCP Connections 32 million 3.9 million (-88%)

    We observed an 88% reduction in the number of connections required between routers and storage nodes in some of our largest clusters.

    Advertisement
    free widgets for website
    • Image of the Total number of connections after HTTP/2

    Figure 5. Total number of connections after HTTP/2

    Reduction in Garbage Collection time

    We observed a 75% reduction in garbage collection times for both young and old gen.

    Advertisement
    free widgets for website
    GC HTTP/1.1 HTTP/2
    Young Gen 2000 ms 500ms (+75%)
    Old Gen 80 ms 15 ms (+81%)
    • Image that shows the reduction in time for GC after HTTP/2

    Figure 6. Reduction in time for GC after HTTP/2

    Waiting time to acquire a Storage Node connection

    HTTP/2 eliminates the need to wait for a storage node connection by enabling multiplexing on a single TCP connection, which is a significant factor in reducing latency compared to HTTP/1.1.

      HTTP/1.1 HTTP/2
    Wait time in router to get a storage node connection 11ms 0.02ms (+99%)
    • Image of the reduction is wait time to get a connection after HTTP/2

    Figure 7. Reduction is wait time to get a connection after HTTP/2

    Conclusion

    Espresso has a large server fleet and is mission-critical to a number of LinkedIn applications. With HTTP/2 migration, we successfully solved Espresso’s scalability problems due to the huge number of TCP connections required between the router and the storage nodes. The new architecture also reduced the latencies by 75% and made Espresso more resilient. 

    Advertisement
    free widgets for website

    Acknowledgments

    I would like to thank my colleagues Antony Curtis, Yaoming Zhan, BinBing Hou, Wenqing Ding, Andy Mao, and Rahul Mehrotra who worked on this project. The project demanded a great deal of time and effort due to the complexity involved in optimizing the performance. I would like to thank Kamlakar Singh and Yun Sun for reviewing the blog and providing valuable feedback. 

    We would also like to thank our management Madhur Badal, Alok Dhariwal and Gayatri Penumetsa for their support and resources, which played a crucial role in the success of this project. Their encouragement and guidance helped the team overcome challenges and deliver the project on time.

    Advertisement
    free widgets for website

    Topics

    Continue Reading

    Trending