The SPDY Protocol is likely going to be the successor of http. This short talk summarizes the most important points and includes a demo on how to migrate a Wordpress blog on httpd.
HTTP 1.1, which is the backbone of pretty much everything we’ve been using on the Internet, has been around for over 15 years. Recently the HTTP 2.0 specification has been completed and gradually application servers will start supporting it. It does make one wonder though: why change if something has been working for so long. In this talk we’ll examine the shortcomings of HTTP 1.1 and how 2.0 intends to address those. We’ll see what we need to know and how it’s going to affect our existing applications, and future ones.
The document introduces HTTP/2 and discusses limitations of HTTP 1.1 including head of line blocking, TCP slow start, and latency issues. It describes key features of HTTP/2 such as multiplexing requests over a single TCP connection, header compression, and server push to reduce page load times. The presentation includes demos of HTTP/2 in Chrome dev tools and Wireshark to troubleshoot HTTP/2 connections.
HTTP/2 aims to address issues with HTTP/1.x such as head-of-line blocking and wasted bandwidth through duplicate requests. It uses a binary format for multiplexing requests, server push, header compression, stream prioritization and flow control. Major browsers now support HTTP/2 over TLS, though server implementations are still in development. While preserving the HTTP/1.1 API, HTTP/2 provides advantages like cheaper requests and more efficient use of network resources and server capacity.
WebSocket is a protocol that provides bidirectional communication over a single TCP connection. It uses an HTTP handshake to establish a connection and then transmits messages as frames that can contain text or binary data. The frames include a header with metadata like opcode and payload length. WebSocket aims to provide a standard for browser-based applications that require real-time data updates from a server.
Choosing A Proxy Server - Apachecon 2014bryan_call
This document summarizes a presentation about choosing a proxy server. It discusses several popular proxy options including Apache Traffic Server (ATS), Nginx, Squid, Varnish, and Apache HTTP Server. It covers the types of proxies each supports, features, architectures, caching, performance, and pros and cons. Benchmark tests show ATS has the best cache scaling and performance overall while using less CPU than alternatives like Squid. Nginx and Squid had some issues with latency and HTTP compliance. The document recommends ATS as a good choice for its scaling, efficient caching, and plugin support.
This document summarizes the history and development of HTTP/2. It discusses the limitations of HTTP/1 that HTTP/2 aims to address, such as head-of-line blocking. The key features of HTTP/2 are described, including multiplexing, priority, header compression, and server push. The document also covers topics like TLS, QUIC, and tools for debugging HTTP/2 implementations.
Jim Jagielski discusses improvements to Apache HTTP Server 2.4 including enhanced performance, support for asynchronous I/O, additional multi-processing modules, and improved functionality for reverse proxy servers. Key enhancements to Apache's reverse proxy module mod_proxy include support for additional protocols like FastCGI and SCGI, improved load balancing capabilities, and an embedded administration interface.
The document discusses WebSocket technology. It provides an overview of WebSocket, including how it works, how it differs from HTTP by being bidirectional and using a single TCP connection, and how the handshake process upgrades an HTTP connection to WebSocket. It also covers WebSocket subprotocols and extensions.
HTTP 1.1, which is the backbone of pretty much everything we’ve been using on the Internet, has been around for over 15 years. Recently the HTTP 2.0 specification has been completed and gradually application servers will start supporting it. It does make one wonder though: why change if something has been working for so long. In this talk we’ll examine the shortcomings of HTTP 1.1 and how 2.0 intends to address those. We’ll see what we need to know and how it’s going to affect our existing applications, and future ones.
The document introduces HTTP/2 and discusses limitations of HTTP 1.1 including head of line blocking, TCP slow start, and latency issues. It describes key features of HTTP/2 such as multiplexing requests over a single TCP connection, header compression, and server push to reduce page load times. The presentation includes demos of HTTP/2 in Chrome dev tools and Wireshark to troubleshoot HTTP/2 connections.
HTTP/2 aims to address issues with HTTP/1.x such as head-of-line blocking and wasted bandwidth through duplicate requests. It uses a binary format for multiplexing requests, server push, header compression, stream prioritization and flow control. Major browsers now support HTTP/2 over TLS, though server implementations are still in development. While preserving the HTTP/1.1 API, HTTP/2 provides advantages like cheaper requests and more efficient use of network resources and server capacity.
WebSocket is a protocol that provides bidirectional communication over a single TCP connection. It uses an HTTP handshake to establish a connection and then transmits messages as frames that can contain text or binary data. The frames include a header with metadata like opcode and payload length. WebSocket aims to provide a standard for browser-based applications that require real-time data updates from a server.
Choosing A Proxy Server - Apachecon 2014bryan_call
This document summarizes a presentation about choosing a proxy server. It discusses several popular proxy options including Apache Traffic Server (ATS), Nginx, Squid, Varnish, and Apache HTTP Server. It covers the types of proxies each supports, features, architectures, caching, performance, and pros and cons. Benchmark tests show ATS has the best cache scaling and performance overall while using less CPU than alternatives like Squid. Nginx and Squid had some issues with latency and HTTP compliance. The document recommends ATS as a good choice for its scaling, efficient caching, and plugin support.
This document summarizes the history and development of HTTP/2. It discusses the limitations of HTTP/1 that HTTP/2 aims to address, such as head-of-line blocking. The key features of HTTP/2 are described, including multiplexing, priority, header compression, and server push. The document also covers topics like TLS, QUIC, and tools for debugging HTTP/2 implementations.
Jim Jagielski discusses improvements to Apache HTTP Server 2.4 including enhanced performance, support for asynchronous I/O, additional multi-processing modules, and improved functionality for reverse proxy servers. Key enhancements to Apache's reverse proxy module mod_proxy include support for additional protocols like FastCGI and SCGI, improved load balancing capabilities, and an embedded administration interface.
The document discusses WebSocket technology. It provides an overview of WebSocket, including how it works, how it differs from HTTP by being bidirectional and using a single TCP connection, and how the handshake process upgrades an HTTP connection to WebSocket. It also covers WebSocket subprotocols and extensions.
1. The document discusses a meetup about WebSocket and SPDY protocols on July 5th, 2012 presented by Kensaku Komatsu.
2. The presentation covered introductions to WebSocket and SPDY, how they address issues with HTTP such as slow loading of multiple resources, and compared their communication models and transport protocols.
3. The main topics were introductions to WebSocket and SPDY, and a deeper dive into the WebSocket protocol including its handshake process, data framing, ping/pong functionality, and additional aspects like subprotocols and extensions.
This document provides an overview of HTML5 WebSocket technology. It discusses limitations of traditional HTTP and how WebSocket enables full-duplex communication by reducing overhead and latency compared to alternative techniques like polling. The WebSocket API and protocol are introduced, along with browser support and server library options. Key benefits of WebSocket include unlimited connections per server, very small overhead, and true real-time bidirectional communication across the web.
1) WebSockets allow for bidirectional communication between a client and server that overcomes limitations of HTTP such as polling. It uses a single TCP connection for sending messages back and forth.
2) The WebSocket handshake establishes a connection via HTTP that is then switched to the WebSocket protocol. Messages can then be sent simultaneously in both directions.
3) Compared to polling, WebSockets have much lower overhead since it uses a single connection rather than multiple HTTP requests, resulting in significantly lower bandwidth usage even with many connected clients.
The document discusses the history and fundamentals of interactive web technologies. It begins with HTTP and its limitations for pushing data from server to client. It then covers early techniques like meta refresh and AJAX polling. It discusses longer polling, HTTP chunked responses, and forever frames. It introduces Comet and web sockets as solutions providing true real-time bidirectional communication. It also covers server-sent events. In conclusion, it recommends using all these techniques together and frameworks like Socket.IO and SignalR that abstract the complexities and provide high-level APIs.
HTTP is a client-server protocol for transmitting hypermedia documents across the internet. It uses a request-response paradigm where clients make requests which are answered by HTTP servers. Requests use methods like GET and POST, and include headers. Responses contain status lines, headers, and content. HTTP allows caching, cookies, authentication, and redirects. It is the foundation of data communication for the World Wide Web via the hypertext transfer protocol.
The document discusses the WebSocket protocol. It describes how WebSocket works at a high level by establishing a handshake between client and server using HTTP headers to switch to the WebSocket protocol. It then outlines the format of WebSocket frames which make up the communication, including fields like opcode, masking, and payload length. Finally, it provides some examples of WebSocket libraries for different programming languages.
HTTP was created in 1989 by Tim Berners-Lee at CERN to allow information sharing through hypertext. The first web server and website launched in 1990-1991. HTTP uses a client-server model with requests containing a start line with method, URL, and protocol version followed by headers and an optional message body. Responses contain a status line, headers, and body. Key concepts are persistent connections, caching, content types, and new versions that add functionality while maintaining backward compatibility.
Scaling out on the cloud is easy. Especially, if you have a software provisioning system that helps you to deploy your environment wherever you want. This session will give you an overview of the fantastic new features of HAProxy V 1.5, and how you can integrate it into your environment to build a high available environment, using open source software. Starting with a single-webserver + mysql setup provisioned via chef, we will deploy an HA Proxy Cluster in front and scale out your nginx and mysql database backend.
The HTML5 WebSocket API allows for true full-duplex communication between a client and server. It uses the WebSocket protocol which provides a standardized way for the client to "upgrade" an HTTP connection to a WebSocket connection, allowing for messages to be sent in either direction at any time with very little overhead. This enables real-time applications that were previously difficult to achieve with traditional HTTP requests. Common server implementations include Kaazing WebSocket Gateway, Jetty, and Node.js. The JavaScript API provides an easy way for clients to connect, send, and receive messages via a WebSocket connection.
This document discusses WebSockets as an improvement over previous "fake push" techniques for enabling real-time full duplex communication between web clients and servers. It notes that WebSockets use HTTP for the initial handshake but then provide a persistent, bi-directional connection. Examples are given of how WebSockets work and can be implemented in various programming languages including Ruby. Support in browsers and servers is also discussed.
This document describes a swarm cluster with an overlay network containing multiple containers running various Docker services and images. The cluster has one container manager and three worker containers running the dind image. Services like HAProxy, a registry, nginx-proxy, and echo are distributed across the worker containers and load balanced with an overlay network for high availability.
This document discusses Apache httpd reverse proxies and Tomcat. It covers why to use a proxy, common proxy protocols like AJP, HTTP/HTTPS, and HTTP/2. It also provides configuration examples for mod_jk, mod_proxy_ajp, and mod_proxy_http when using Apache httpd as a reverse proxy for Tomcat. Performance comparisons are shown between mod_jk, mod_proxy, and Nginx. The document concludes that a proxy is useful for load balancing, protocol upgrades, and SSL termination between the application server and internet.
Learn how to load balance your applications following best practices with NGINX and NGINX Plus.
Join this webinar to learn:
- How to configure basic HTTP load balancing features
- The essential elements of load balancing: session persistence, health checks, and SSL termination
- How to load balance MySQL, DNS, and other common TCP/UDP applications
- How to have NGINX Plus automatically discover new service instances in an auto-scaling or microservices environment
A webinar that looks into the new features that the Windows Server 2016 will offer in the DNS, DHCP and IPv6 space.
Showcase of some of the new stuff using the latest tech preview and the aim is to give administrators a quick overview of the Windows Server 2016 and enough information to decide if early adoption is worthwhile.
Why Managed Service Providers Should Embrace Container TechnologySagi Brody
This talk will demonstrate the importance and value for Managed Service Providers (MSPs) and cloud providers of building their business models around the management of containers. It will also explore the various container technologies being used today and why one might be utilized over another. The object is not to give a technical discussion on the subject, but rather to cover the benefits of Linux containers and how their use can be incorporated into strategies for future business planning and development.
The document discusses the history and development of WebSockets. It describes how earlier protocols like HTTP, AJAX, and polling had limitations for real-time full-duplex communication needs. WebSockets were created as a new protocol to allow persistent connections and transmission of data between a client and server with low overhead. The document outlines the WebSocket handshake process and API, discusses security considerations, and provides examples of how WebSockets have been used in online games, visualization tools, and other real-time applications.
This document discusses DNS server monitoring using DNSTAP, an open protocol to capture and store DNS server events. It begins by noting the performance impact of traditional monitoring methods and limitations of network packet capture. It then provides an overview of how DNSTAP works, implementations in Unbound, Knot DNS, and upcoming BIND 9, dependencies, available tools, and examples of configuring DNSTAP in Unbound, Knot DNS, and BIND 9.
The document discusses Kubernetes networking concepts including pods, services, and ingress. It provides examples of how containers within pods communicate via Docker networking. It also explains how Kubernetes networking solves the problems of pod-to-pod, service-to-pod, and external-to-service communications using services, iptables, and kube-proxy. The document demonstrates creating a deployment, service, and ingress to expose an application externally via a load balancer.
This document discusses the key aspects and needs of modern application performance monitoring (APM) solutions. APM solutions need to automatically adapt to complex, changing IT architectures and provide both a wide overview for operations as well as deep code-level insights for developers. They must also generate actionable alerts to help narrow down issues while avoiding false alarms that could be ignored or disturb teams.
Full Stack Web Application Performance TuningFabian Lange
Presentation from the symfonyCamp 2008 on Tips for improving web application performance by covering the full stack, rather than concentrating on very specific issues.
Copyright Fabian Lange 2008, all rights reserved
1. The document discusses a meetup about WebSocket and SPDY protocols on July 5th, 2012 presented by Kensaku Komatsu.
2. The presentation covered introductions to WebSocket and SPDY, how they address issues with HTTP such as slow loading of multiple resources, and compared their communication models and transport protocols.
3. The main topics were introductions to WebSocket and SPDY, and a deeper dive into the WebSocket protocol including its handshake process, data framing, ping/pong functionality, and additional aspects like subprotocols and extensions.
This document provides an overview of HTML5 WebSocket technology. It discusses limitations of traditional HTTP and how WebSocket enables full-duplex communication by reducing overhead and latency compared to alternative techniques like polling. The WebSocket API and protocol are introduced, along with browser support and server library options. Key benefits of WebSocket include unlimited connections per server, very small overhead, and true real-time bidirectional communication across the web.
1) WebSockets allow for bidirectional communication between a client and server that overcomes limitations of HTTP such as polling. It uses a single TCP connection for sending messages back and forth.
2) The WebSocket handshake establishes a connection via HTTP that is then switched to the WebSocket protocol. Messages can then be sent simultaneously in both directions.
3) Compared to polling, WebSockets have much lower overhead since it uses a single connection rather than multiple HTTP requests, resulting in significantly lower bandwidth usage even with many connected clients.
The document discusses the history and fundamentals of interactive web technologies. It begins with HTTP and its limitations for pushing data from server to client. It then covers early techniques like meta refresh and AJAX polling. It discusses longer polling, HTTP chunked responses, and forever frames. It introduces Comet and web sockets as solutions providing true real-time bidirectional communication. It also covers server-sent events. In conclusion, it recommends using all these techniques together and frameworks like Socket.IO and SignalR that abstract the complexities and provide high-level APIs.
HTTP is a client-server protocol for transmitting hypermedia documents across the internet. It uses a request-response paradigm where clients make requests which are answered by HTTP servers. Requests use methods like GET and POST, and include headers. Responses contain status lines, headers, and content. HTTP allows caching, cookies, authentication, and redirects. It is the foundation of data communication for the World Wide Web via the hypertext transfer protocol.
The document discusses the WebSocket protocol. It describes how WebSocket works at a high level by establishing a handshake between client and server using HTTP headers to switch to the WebSocket protocol. It then outlines the format of WebSocket frames which make up the communication, including fields like opcode, masking, and payload length. Finally, it provides some examples of WebSocket libraries for different programming languages.
HTTP was created in 1989 by Tim Berners-Lee at CERN to allow information sharing through hypertext. The first web server and website launched in 1990-1991. HTTP uses a client-server model with requests containing a start line with method, URL, and protocol version followed by headers and an optional message body. Responses contain a status line, headers, and body. Key concepts are persistent connections, caching, content types, and new versions that add functionality while maintaining backward compatibility.
Scaling out on the cloud is easy. Especially, if you have a software provisioning system that helps you to deploy your environment wherever you want. This session will give you an overview of the fantastic new features of HAProxy V 1.5, and how you can integrate it into your environment to build a high available environment, using open source software. Starting with a single-webserver + mysql setup provisioned via chef, we will deploy an HA Proxy Cluster in front and scale out your nginx and mysql database backend.
The HTML5 WebSocket API allows for true full-duplex communication between a client and server. It uses the WebSocket protocol which provides a standardized way for the client to "upgrade" an HTTP connection to a WebSocket connection, allowing for messages to be sent in either direction at any time with very little overhead. This enables real-time applications that were previously difficult to achieve with traditional HTTP requests. Common server implementations include Kaazing WebSocket Gateway, Jetty, and Node.js. The JavaScript API provides an easy way for clients to connect, send, and receive messages via a WebSocket connection.
This document discusses WebSockets as an improvement over previous "fake push" techniques for enabling real-time full duplex communication between web clients and servers. It notes that WebSockets use HTTP for the initial handshake but then provide a persistent, bi-directional connection. Examples are given of how WebSockets work and can be implemented in various programming languages including Ruby. Support in browsers and servers is also discussed.
This document describes a swarm cluster with an overlay network containing multiple containers running various Docker services and images. The cluster has one container manager and three worker containers running the dind image. Services like HAProxy, a registry, nginx-proxy, and echo are distributed across the worker containers and load balanced with an overlay network for high availability.
This document discusses Apache httpd reverse proxies and Tomcat. It covers why to use a proxy, common proxy protocols like AJP, HTTP/HTTPS, and HTTP/2. It also provides configuration examples for mod_jk, mod_proxy_ajp, and mod_proxy_http when using Apache httpd as a reverse proxy for Tomcat. Performance comparisons are shown between mod_jk, mod_proxy, and Nginx. The document concludes that a proxy is useful for load balancing, protocol upgrades, and SSL termination between the application server and internet.
Learn how to load balance your applications following best practices with NGINX and NGINX Plus.
Join this webinar to learn:
- How to configure basic HTTP load balancing features
- The essential elements of load balancing: session persistence, health checks, and SSL termination
- How to load balance MySQL, DNS, and other common TCP/UDP applications
- How to have NGINX Plus automatically discover new service instances in an auto-scaling or microservices environment
A webinar that looks into the new features that the Windows Server 2016 will offer in the DNS, DHCP and IPv6 space.
Showcase of some of the new stuff using the latest tech preview and the aim is to give administrators a quick overview of the Windows Server 2016 and enough information to decide if early adoption is worthwhile.
Why Managed Service Providers Should Embrace Container TechnologySagi Brody
This talk will demonstrate the importance and value for Managed Service Providers (MSPs) and cloud providers of building their business models around the management of containers. It will also explore the various container technologies being used today and why one might be utilized over another. The object is not to give a technical discussion on the subject, but rather to cover the benefits of Linux containers and how their use can be incorporated into strategies for future business planning and development.
The document discusses the history and development of WebSockets. It describes how earlier protocols like HTTP, AJAX, and polling had limitations for real-time full-duplex communication needs. WebSockets were created as a new protocol to allow persistent connections and transmission of data between a client and server with low overhead. The document outlines the WebSocket handshake process and API, discusses security considerations, and provides examples of how WebSockets have been used in online games, visualization tools, and other real-time applications.
This document discusses DNS server monitoring using DNSTAP, an open protocol to capture and store DNS server events. It begins by noting the performance impact of traditional monitoring methods and limitations of network packet capture. It then provides an overview of how DNSTAP works, implementations in Unbound, Knot DNS, and upcoming BIND 9, dependencies, available tools, and examples of configuring DNSTAP in Unbound, Knot DNS, and BIND 9.
The document discusses Kubernetes networking concepts including pods, services, and ingress. It provides examples of how containers within pods communicate via Docker networking. It also explains how Kubernetes networking solves the problems of pod-to-pod, service-to-pod, and external-to-service communications using services, iptables, and kube-proxy. The document demonstrates creating a deployment, service, and ingress to expose an application externally via a load balancer.
This document discusses the key aspects and needs of modern application performance monitoring (APM) solutions. APM solutions need to automatically adapt to complex, changing IT architectures and provide both a wide overview for operations as well as deep code-level insights for developers. They must also generate actionable alerts to help narrow down issues while avoiding false alarms that could be ignored or disturb teams.
Full Stack Web Application Performance TuningFabian Lange
Presentation from the symfonyCamp 2008 on Tips for improving web application performance by covering the full stack, rather than concentrating on very specific issues.
Copyright Fabian Lange 2008, all rights reserved
The SPDY Protocol is likely going to be the successor of http. This short talk summarizes the most important points and includes a demo on how to migrate a Wordpress blog on httpd.
My talk for Java User Group in Cologne about the Rich Ajax Platform from Eclipse. Talk includes a live demo which is unfortunately not in the slides :-)
A slightly updated version can be found here:
http://www.slideshare.net/fabianlange/rich-ajax-platform-programming-for-web-and-rich-client
In my talk at socrates 2011, I descrived why performance is a craft and what to do to ensure great performance. I concluded with a few best practies and wonder if there are more
Kunde ist nicht gleich Kunde. Kunden Profiling und Kundenanalyse.MAX2014DACH
Sicherlich haben Sie als „Managed Service Provider“ eine Vorstellung darüber, wie Ihre Zielgruppe ungefähr aussieht. Arztpraxen, Kanzleien und Kleinunternehmen um nur einige zu nennen. Aber wissen Sie auch wie sinnvoll und erfolgreich bestimmte Werbemaßnahmen für bestimmte Kundengruppen sind? Wie messbar sind die Werbemittel die Sie einsetzen und wie hoch ist die Erfolgsquote? Wie lerne ich mehr über meine Kunden?
Oracle Coherence & WebLogic 12c Web Sockets: Delivering Real Time Push at ScaleC2B2 Consulting
Presentation delivered by Steve Millidge at DOAG German Oracle User Group Conference in Nuremberg, 19-21 November 2013.
The real time web is coming with Websockets in HTML 5. The big question is how to deliver event driven architectures for websockets at scale. This session delivered by a member of the JSR 347 Data Grids expert group provides an insight on how combining Oracle Coherence with the new Websockets support in WebLogic 12c can deliver enterprise scale push to web devices. The session first provides an introduction to websockets and delves into typical Oracle Coherence architectures and how they deliver linear scalability and high availability. We then look at the event capabilities inherent in Oracle Coherence that when hooked up to the new WebLogic 12c Web Sockets server can deliver Coherence grid updates in real time to HTML 5 devices.
The presentation will be a mixture of of animated graphical slides depicting how WebLogic Web Sockets and Oracle Coherence work, combined with code snippets. We will then provide a demo hosted on amazon EC2 of the described architecture for delegates to browse to and interact with to show the capabilities of websockets on their devices. Demos will again use Oracle Coherence and WebLogic 12c.
In this webinar we discuss new features in NGINX Plus R15, which includes support for gRPC, HTTP/2 Server Push, enhanced clustering, and OpenID Connect SSO integration.
Watch this webinar to learn:
- About new HTTP/2 enhancements: gRPC and HTTP/2 server push support
- About new state sharing and clustering support in NGINX Plus, with support for Sticky Learn session persistence
- How to integrate with Okta, OneLogin, and other identity providers to provide single sign on (SSO) for your applications
- How to initiate subrequests with the NGINX JavaScript module, new variables, and other great new enhancements in this release
https://www.nginx.com/resources/webinars/whats-new-nginx-plus-r15/
Learn about HTTP/2 and its relationship to HTTP 1.1 and SPDY. Understand core features and how they benefit security and browser efficiency. More that a "what's new" this talk will leave you with an understanding of why choices in HTTP/2 were made. You'll leave knowing what HTTP/2 is and why it is better for clients and servers.
Slides from my speech about web apps performance. Images, CSS, JS optimization. PHP and HTTP server effects + caching. Performance profiling with Blackfire.io, debugging with Xdebug.
Accelerating and Securing your Applications in AWS. In-depth look at Solving ...Amazon Web Services
Through Real AWS Customer Case Studies we will explain how Brocade Virtual Application Delivery Controller (vADC) can: - Simplify complex architectures in AWS - Significantly accelerate application performance and user experience - Provide additional application security over and above AWS ELB – with and without Web Application Firewalls (WAF) - Enable hybrid cloud architectures and cloud bursting - Fix application-level compatibility problems without the need to re-write the apps.
Speaker: Ron Masson System Engineer - Software Networking, Australia/New Zealand, Brocade
IBM Think 2018 - IBM Connections TroubleshootingNico Meisenzahl
Curious about how to make your IBM Connections environment run smoothly while reducing support effort? Need help debugging and getting to the core of some Connections challenges? Join Nico to find out how to resolve common issues, and learn troubleshooting basics and other useful knowledge to ensure an efficient Connections on-premises environment. Level up your debugging skills while learning more about back-end topics such as IBM Cloud Private, Db2, TDI, SSO, Directory and integrations like Docs, CCM, Cognos and FEB. He'll also cover the new PINK features like Orient Me, Metrics and Customizer. Walk away with Connections best-practice tips and tricks to help you provide steady and efficient social capabilities!
The document provides 14 tips for optimizing website performance based on the 80/20 rule. The tips include minimizing HTTP requests by combining files, using a CDN, adding caching headers, gzipping files, optimizing CSS and JS placement, avoiding redirects and duplicate scripts, and making Ajax cacheable. Following these best practices can significantly improve page load times by reducing network requests and making better use of browser caching.
The document discusses SPDY, an evolution of HTTP developed by Google since 2009 that aims to speed up web content delivery. SPDY utilizes a single TCP connection more efficiently through multiplexing and other techniques. It allows for faster page loads, often around 39-55% faster than HTTP. While SPDY adoption is growing, with support in Chrome, Firefox, and Amazon Silk, widespread implementation by servers is still limited. SPDY is expected to influence the development of HTTP 2.0.
Implementing data and databases on K8s within the Dutch governmentDoKC
A small walkthrough of projects within the dutch government running Data(bases) on OpenShift. This talk shares success stories, provides a proven recipe to `get it done` and debunks some of the FUD.
About Sebastiaan:
I have always been a weird DBA, trying to combine Databases with out-of-the-box thinking and a DevOps mindset. Around 2016 I fell in love with both Postgres and Kubernetes, and I then committed my life to enabling Dutch organisations with running their Database workloads CloudNative.
Over the last few years I worked as a private contractor for 2 large government agencies doing exactly that, and I want to share my and others (success stories) hoping to enable and inspire Data on Kubernetes adoption.
Programming WebSockets with Glassfish and GrizzlyC2B2 Consulting
The document discusses building WebSocket applications with Grizzly and Glassfish. It provides an overview of WebSockets and push technologies, describes how to enable WebSocket support in Glassfish, and includes code walkthroughs of a basic echo server and pushing stock prices to the browser using WebSockets.
This document discusses web performance optimization techniques. It is a summary of rules for web performance by Mark Tomlinson, who has 27 years of experience in performance. Some of the key techniques discussed include reducing HTTP requests, optimizing file compression, minimizing code, improving web font and image performance, prefetching resources, avoiding unnecessary redirects, and optimizing infrastructure and databases. The document emphasizes measuring performance through load testing and monitoring to identify bottlenecks.
Integrating multiple CDN providers at Etsy - Velocity Europe (London) 2013Marcus Barczak
The document discusses Etsy's experience integrating multiple content delivery network (CDN) providers. Etsy began using a single CDN in 2008 but then investigated using multiple CDNs in 2012 to improve resilience, flexibility, and costs. They developed an evaluation criteria and testing process to initially configure and test the CDNs with non-critical traffic before routing production traffic. Etsy then implemented methods for balancing traffic across CDNs using DNS and monitoring the performance of the CDNs and origin infrastructure.
This document discusses various techniques for optimizing the frontend performance of web applications. It provides 5 rules: 1) Only optimize when it makes a meaningful difference. 2) Download resources in parallel to reduce page load time. 3) Eliminate unnecessary requests through techniques like merging, inlining, sprites and caching. 4) Defer parsing of JavaScripts when possible to improve perceived page load speeds. 5) Consider factors like server location and content delivery networks to improve global performance.
Openstack Summit Vancouver 2018 - Multicloud NetworkingShannon McFarland
This document discusses connecting private clouds located on-premises to public clouds using multicloud networking. It begins with an overview of hybrid vs multicloud networking and reasons for using multiple cloud providers. It then covers options for extending an on-premises private cloud to a public cloud like AWS, GCP, or Azure using their native VPN services. The document discusses adding more public cloud providers and the need for automation. It introduces dynamic multipoint VPN (DMVPN) as a way to enable dynamic multicloud connectivity and extend routing protocols between sites.
Mobile App Performance: Getting the Most from APIs (MBL203) | AWS re:Invent ...Amazon Web Services
(Presented by New Relic) Too often, developers think of a mobile app as simply code running on the device. A mobile app is much more than that. Every web API used by an app becomes as much a part of the app as the code running on the device. But while mobile developers have control over their code, they don't always have control over the APIs they use. Web APIs and their infrastructure impact app performance and ultimately the user experience.
This presentation covers some of the essential aspects of app performance management when web APIs are present, including:
-HTTP headers are your friend--stop ignoring all they have to tell you
-Control your network connections on the device—don't just leave things to the OS
-Configure all your caches and use them
-Whatever you do, measure early and often
The session includes a customer story from the CTO of Mirego, and demos of New Relic mobile app performance monitoring, where you see how to drill down into specific requests to see performance by response time, throughput, and data transfer size.
The document provides an introduction to microservices and RESTful APIs. It discusses microservices architecture as a way to structure applications into small, autonomous services. It also covers key aspects of HTTP such as requests, responses, and status codes. Finally, it introduces REST as an architectural style for designing networked applications and discusses how RESTful APIs use HTTP requests to trigger CRUD operations on resources.
The Real World - Plugging the Enterprise Into It (nodejs)Aman Kohli
This document discusses using Node.js as the foundation for building applications that connect the physical world to enterprise systems through mobile devices and sensors. It describes initial work done to build a proxy and protocol for handling requests and addresses challenges with authentication, scalability, and performance testing. The document shares results from benchmarking the system under different network conditions and outlines next steps to improve concurrency, security, and infrastructure elasticity.
Similar to SPDY - http reloaded - WebTechConference 2012 (20)
3. HTTP Problems
• Single request per connection. Because HTTP can only fetch one resource at a time (HTTP
pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents
reuse of the TCP channel for additional requests. Browsers work around this problem by
using multiple connections. Since 2008, most browsers have finally moved from 2
connections per domain to 6.
• Exclusively client-initiated requests. In HTTP, only the client can initiate a request. Even if
the server knows the client needs a resource, it has no mechanism to inform the client and
must instead wait to receive a request for the resource from the client.
• Uncompressed request and response headers. Request headers today vary in size from
~200 bytes to over 2KB. As applications use more cookies and user agents expand
features, typical header sizes of 700-800 bytes is common. For modems or ADSL
connections, in which the uplink bandwidth is fairly low, this latency can be
significant. Reducing the data in headers could directly improve the serialization latency to
send requests.
• Redundant headers. In addition, several headers are repeatedly sent across requests on the
same channel. However, headers such as the User-Agent, Host, and Accept* are generally
static and do not need to be resent.
• Optional data compression. HTTP uses optional compression encodings for data. Content
should always be sent in a compressed format.
Source: http://dev.chromium.org/spdy/spdy-whitepaper
4. Web Requests Are Simple
• Open a connection
• Send a request
• Receive a response
• Done
8. TCP Handshake
0ms 1) Host A sends a TCP SYNchronize packet to Host B
25ms 2) Host B receives A's SYN
25ms 3) Host B sends a SYNchronize-ACKnowledgement
50ms 4) Host A receives B's SYN-ACK
75ms 5) Host A sends ACKnowledge and data
75ms 6) Host B receives ACK and data.
• With a "distance" of just 25ms, this takes
us 75ms until data arrives at server
9.
10. Initial Window
• Congestion Control Mechanism
• Avoid overloading clients
• Each ACK of the client increases
window
• RFC 3390
– Increasing icwnd
– Small Resonses are complete without ACK
– Avoid the ACK RTT
11. Pushing over http
• Push === Long Polling
• Consumes one connection on clients
• On server
– Used to be expensive to hold
– Modern servers have evented I/O
• WebSockets
16. SPDY Solutions
• Allow many concurrent HTTP requests to run across a
single TCP session.
• Reduce the bandwidth currently used by HTTP by
compressing headers and eliminating unnecessary
headers.
• Make SSL the underlying transport protocol, for better
security and compatibility with existing network
infrastructure. Although SSL does introduce a latency
penalty, we believe that the long-term future of the web
depends on a secure network connection. In addition, the
use of SSL is necessary to ensure that communication
across existing proxies is not broken.
• Enable the server to initiate communications with the
client and push data to the client whenever possible.
Source: http://dev.chromium.org/spdy/spdy-whitepaper
18. Compression
• All data is compressed
• Includes headers
• Redundand data is removed
– User Agent of second request is known to
be same as on first
19. CRIME
• Compression Ratio Info-leak Made
Easy
• Cookie value can be detected when
compression is effective
Sources:
threatpost.com/en_us/blogs/new-attack-uses-ssltls-information-leak-hijack-https-sessions-090512
security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor/19914
24. SSL
• Not said to be a problem with HTTP
• SSL should be default
– But actually expensive
• SSL hides SPDY traffic, so that proxies
don't break it
25. Pushing
• Long Lasting Connection By Design
• Send does not close the "request"
• Two flavors
– Server push
– Server hint
26. Compatibility
• SPDY is backwards compatible
• Uses Next Protocol Negotiation
– tools.ietf.org/html/draft-agl-tls-
nextprotoneg-02
27. Adoption
• Facebook implements and favors SPDY
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html
• Twitter implements and favors SPDY
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0250.html
• Google implements and favors SPDY
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0219.html
• Mozilla implements and favors SPDY
http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0156.html
• Wordpress.com uses SPDY
https://twitter.com/wordpressdotcom/statuses/238741078172389377
33. PHP is not Threadsafe
• The way SPDY works is incompatible
with non threadsafe implementations
– one connection one httpd worker
– But multiple requests
• Zend Threadsafe does not support
some features (mysql!)
• Need to externalize it with cgi
34. mod_php to mod_fcgid + php
• yum install mod_fcgid
• vi /etc/httpd/conf/httpd.conf
<Directory "/var/www/html">
Options Indexes FollowSymLinks ExecCGI
</Directory>
• mv /etc/httpd/conf.d/php.conf
/etc/httpd/conf.d/php.conf.bak
• vi /etc/httpd/conf.d/fcgid.conf