{"id":12617,"date":"2019-07-05T06:45:48","date_gmt":"2019-07-05T04:45:48","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/"},"modified":"2023-07-17T08:13:21","modified_gmt":"2023-07-17T06:13:21","slug":"sql-server-containers-and-docker-network-driver-performance-considerations","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/","title":{"rendered":"SQL Server containers and docker network driver performance considerations"},"content":{"rendered":"

Few months ago I attended to the Franck Pachot session about Microservices and databases at SOUG Romandie<\/a> in Lausanne on 2019 May 21th. He covered some performance challenges that can be introduced by Microservices architecture design and especially when database components come into the game with chatty applications. One year ago, I was in a situation where a customer installed some SQL Server Linux 2017 containers in a Docker infrastructure with user applications located outside of this infrastructure. It is likely an uncommon way to start with containers but anyway when you are immerging in a Docker world you just notice there is a lot of network drivers and considerations you may be aware of and just for a sake of curiosity, I proposed to my customer to perform some network benchmark tests to get a clear picture of these network drivers and their related overhead in order to design correctly Docker infrastructure from a performance standpoint.<\/p>\n

The initial customer\u2019s scenario included a standalone Docker infrastructure and we considered different approaches about application network configurations from a performance perspective. We did the same for the second scenario that concerned a Docker Swarm infrastructure we installed in a second step.<\/p>\n

The Initial reference \u2013 Host network and Docker host network<\/u><\/strong><\/p>\n

The first point was to get an initial reference with no network management overhead directly from the network host. We used the iperf3 tool for the tests. This is a kind of tool I\u2019m using with virtual environments as well to ensure network throughput is what we really expect and sometimes I got some surprises on this topic. So, let\u2019s go back to the container world and each test was performed from a Linux host outside to the concerned Docker infrastructure according to the customer scenario.<\/p>\n

\"\"<\/p>\n

The attached network card speed link of the Docker Host is supposed to be 10GBits\/sec \u2026<\/p>\n

$ sudo ethtool eth0 | grep \"Speed\"\n        Speed: 10000Mb\/s\n<\/pre>\n
\u2026 and it is confirmed by the first iperf3 output below:<\/p>\n
\"\"<\/p>\n
Let\u2019s say that we tested the Docker host driver as well and we got similar results.<\/p>\n
$ docker run  -it --rm --name=iperf3-server  --net=host networkstatic\/iperf3 -s<\/pre>\n
Docker bridge mode <\/u><\/strong><\/p>\n
The default modus operandi for a Docker host is to create a virtual ethernet bridge (called docker0), attach each container’s network interface to the bridge, and to use network address translation (NAT) when containers need to make themselves visible to the Docker host and beyond. Unless specified, a docker container will use it by default and this is exactly the network driver used by containers in the context of my customer. In fact, we used user-defined bridge network but I would say it doesn\u2019t matter for the tests we performed here.<\/p>\n
$ ip addr show docker0\n5: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default\n    link\/ether 02:42:70:0a:e8:7a brd ff:ff:ff:ff:ff:ff\n    inet 172.17.0.1\/16 brd 172.17.255.255 scope global docker0\n       valid_lft forever preferred_lft forever\n    inet6 fe80::42:70ff:fe0a:e87a\/64 scope link\n       valid_lft forever preferred_lft forever<\/pre>\n
The iperf3 docker container I ran for my tests is using the default bridge network as show below. The interface with index 24 corresponds to the veth0bfc2dc peer of the concerned container.<\/p>\n
$ docker run  -d --name=iperf3-server -p 5204:5201 networkstatic\/iperf3 -s\n\u2026\n$ docker ps | grep iperf\n5c739940e703        networkstatic\/iperf3              \"iperf3 -s\"              38 minutes ago      Up 38 minutes                0.0.0.0:5204->5201\/tcp   iperf3-server\n$ docker exec -ti 5c7 ip addr show\n1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n       valid_lft forever preferred_lft forever\n24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default\n    link\/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff\n    inet 172.17.0.2\/16 brd 172.17.255.255 scope global eth0\n       valid_lft forever preferred_lft forever\n\n[clustadmin@docker1 ~]$ ethtool -S veth0bfc2dc\nNIC statistics:\n     peer_ifindex: 24<\/pre>\n
Here the output after running the iperf3 benchmark:<\/p>\n
\"\"<\/p>\n
It\u2019s worth noting that the \u201cBridge\u201d network adds some overheads with an impact of 13% in my tests but in fact, it is an expected outcome to be honest and especially if we refer to the Docker documentation<\/a>:<\/p>\n
Compared to the default bridge mode, the host mode gives significantly better networking performance since it uses the host\u2019s native networking stack whereas the bridge has to go through one level of virtualization through the docker daemon.<\/em><\/strong><\/p>\n
When the docker-proxy comes into play<\/u><\/strong><\/p>\n
Next scenario we wanted to test concerned the closet network proximity we may have between the user applications and the SQL Server containers in the Docker infrastructure. In other words, we assumed the application resides on the same host than the SQL Server container and we got some surprises from the docker-proxy itself.<\/p>\n
Before running the iperf3 result, I think we have to answer to the million-dollar question here: what is the docker-proxy? But did you only pay attention to this process on your docker host? Let\u2019s run a pstree command:<\/p>\n
$ pstree\nsystemd\u2500\u252c\u2500NetworkManager\u2500\u2500\u25002*[{NetworkManager}]\n        \u251c\u2500agetty\n        \u251c\u2500auditd\u2500\u2500\u2500{auditd}\n        \u251c\u2500containerd\u2500\u252c\u2500containerd-shim\u2500\u252c\u2500npm\u2500\u252c\u2500node\u2500\u2500\u25009*[{node}]\n        \u2502            \u2502                 \u2502     \u2514\u25009*[{npm}]\n        \u2502            \u2502                 \u2514\u250012*[{containerd-shim}]\n        \u2502            \u251c\u2500containerd-shim\u2500\u252c\u2500registry\u2500\u2500\u25009*[{registry}]\n        \u2502            \u2502                 \u2514\u250010*[{containerd-shim}]\n        \u2502            \u251c\u2500containerd-shim\u2500\u252c\u2500iperf3\n        \u2502            \u2502                 \u2514\u25009*[{containerd-shim}]\n        \u2502            \u2514\u250016*[{containerd}]\n        \u251c\u2500crond\n        \u251c\u2500dbus-daemon\n        \u251c\u2500dockerd\u2500\u252c\u2500docker-proxy\u2500\u2500\u25007*[{docker-proxy}]\n        \u2502         \u2514\u250020*[{dockerd}]<\/pre>\n
Well, if I understand correctly the Docker documentation, the purpose of this process is to enable a service consumer to communicate with the service providing container …. but it’s only used in particular circumstances. Just bear in mind that controlling access to a container\u2019s service is massively done through the host netfilter framework, in both NAT and filter tables and the docker-proxy mechanism is required only when this method of control is not available:<\/p>\n
    \n
  • When the Docker daemon is started with –iptables=false<\/strong> or \u2013ip-forward=false<\/strong> or when the Linux host cannot act as a router with Linux kernel parameter ipv4.ip_forward=0<\/strong>. This is not my case here.<\/li>\n
  • When you are using localhost in the connection string of your application that implies to use the loopback interface (127.0.0.0\/8) and the Kernel doesn\u2019t allow routing traffic from it. Therefore, it’s not possible to apply netfilter NAT rules and instead, netfilter sends packets through the filter table’s INPUT chain to a local process listening on the docker-proxy<\/li>\n<\/ul>\n
    $ sudo iptables -L -n -t nat | grep 127.0.0.0\nDOCKER     all  --  0.0.0.0\/0           !127.0.0.0\/8          ADDRTYPE match dst-type LOCAL<\/pre>\n
    In the picture below you will notice I\u2019m using the localhost key word in my connection string so the docker-proxy comes into play.<\/p>\n
    \"\"<\/p>\n
    A huge performance impact for sure which is about 28%. This performance drop may be explained by the fact the docker-proxy process is consuming 100% of my CPUs:<\/p>\n
    \"\"<\/p>\n
    The docker-proxy operates in userland and I may simply disable it with the docker daemon parameter – “userland-proxy”: false \u2013 but I would say this is a case we would not encounter in practice because applications will never use localhost in their connection strings. By the way, changing the connection string from localhost to the IP address of the host container gives a very different outcome similar to the Docker bridge network scenario.<\/p>\n
    Using an overlay network <\/u><\/strong><\/p>\n
    Using a single docker host doesn\u2019t fit well with HA or scalability requirements and in a mission-critical environment I strongly guess no customer will go this way. I recommended to my customer to consider using an orchestrator like Docker Swarm or K8s to anticipate future container workload that was coming from future projects. The customer picked up Docker Swarm for its easier implementation compared to K8s.<\/p>\n
    \"\"<\/p>\n
    After implementing a proof of concept for testing purposes (3 nodes included one manager and two worker nodes), we took the opportunity to measure the potential overhead implied by the overlay network which is the common driver used by containers through stacks and services in such situation. Referring to the Docker documentation overlay networks manage communications among the Docker daemons participating in the swarm and used by services deployed on it. Here the docker nodes in the swarm infrastructure:<\/p>\n
    $ docker node ls\nID                            HOSTNAME                    STATUS              AVAILABILITY        MANAGER STATUS      ENGINE VERSION\nvvdofx0fjzcj8elueoxoh2irj *   docker1.dbi-services.test   Ready               Active              Leader              18.09.5\nnjq5x23dw2ubwylkc7n6x63ly     docker2.dbi-services.test   Ready               Active                                  18.09.5\nruxyptq1b8mdpqgf0zha8zqjl     docker3.dbi-services.test   Ready               Active                                  18.09.5<\/pre>\n
    An ingress overlay network is created by default when setting up a swarm cluster. User-defined overlay network may be created afterwards and extends to the other nodes only when needed by containers.<\/p>\n
    $ docker network ls | grep overlay\nNETWORK ID    NAME              DRIVER   SCOPE\nehw16ycy980s  ingress           overlay  swarm<\/pre>\n
    Here the result of the iperf3 benchmark:<\/p>\n
    \"\"<\/p>\n
    Well, the same result than the previous test with roughly 30% of performance drop. Compared to the initial reference, this is again an expected outcome but I didn’t imagine how important could be the impact in such case.\u00a0 Overlay network introduces additional overhead by putting together behind the scene a VXLAN tunnel (virtual Layer 2 network on top of an existing Layer 3 infrastructure), VTEP endpoints for encapsulation\/de-encapsulation stuff and traffic encryption by default.<\/p>\n
    Here a summary of the different scenarios and their performance impact:<\/p>\n\n\n\n\n\n\n\n\n
    Scenario<\/strong><\/td>\nThroughput (GB\/s)<\/strong><\/td>\nPerformance impact<\/strong><\/td>\n<\/tr>\n
    Host network<\/td>\n10.3<\/td>\n<\/td>\n<\/tr>\n
    Docker host network<\/td>\n10.3<\/td>\n<\/td>\n<\/tr>\n
    Docker bridge network<\/td>\n8.93<\/td>\n0.78<\/td>\n<\/tr>\n
    Docker proxy<\/td>\n7.37<\/td>\n0.71<\/td>\n<\/tr>\n
    Docker overlay network<\/td>\n7.04<\/td>\n0.68<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    In the particular case of my customer where SQL Server instances sit on the Docker infrastructure and applications reside outside of it, it\u2019s clear that using directly Docker host network may be a good option from a performance standpoint assuming this infrastructure remains simple with few SQL Server containers. But in this case, we have to change the SQL Server default listen port with MSSQL_TCP_PORT parameter because using Docker host networking doesn\u2019t provide port mapping capabilities. According to our tests, we didn\u2019t get any evidence of performance improvement in terms of application response time between Docker network drivers but probably because those applications are not network bound here. But I may imagine scenarios where it can be. Finally, this kind of scenario encountered here is likely uncommon and I see containerized apps with database components outside the Docker infrastructure more often but it doesn\u2019t change the game at all and the same considerations apply here \u2026 Today I\u2019m very curious to test real microservices scenarios where database and application components are all sitting on a Docker infrastructure.<\/p>\n
    See you!<\/p>\n
    By David Barbarin<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
    Few months ago I attended to the Franck Pachot session about Microservices and databases at SOUG Romandie in Lausanne on 2019 May 21th. He covered some performance challenges that can be introduced by Microservices architecture design and especially when database components come into the game with chatty applications. One year ago, I was in a […]<\/p>\n","protected":false},"author":26,"featured_media":12618,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229,1320,1504,99],"tags":[720,601,67,51,1275],"type_dbi":[],"class_list":["post-12617","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database-administration-monitoring","category-devops","category-docker","category-sql-server","tag-container","tag-docker","tag-performance","tag-sql-server","tag-swarm"],"acf":[],"yoast_head":"\nSQL Server containers and docker network driver performance considerations - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"SQL Server containers and docker network driver performance considerations\" \/>\n<meta property=\"og:description\" content=\"Few months ago I attended to the Franck Pachot session about Microservices and databases at SOUG Romandie in Lausanne on 2019 May 21th. He covered some performance challenges that can be introduced by Microservices architecture design and especially when database components come into the game with chatty applications. One year ago, I was in a […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2019-07-05T04:45:48+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-07-17T06:13:21+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"500\" \/>\n\t<meta property=\"og:image:height\" content=\"253\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Microsoft Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Microsoft Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/\"},\"author\":{\"name\":\"Microsoft Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"headline\":\"SQL Server containers and docker network driver performance considerations\",\"datePublished\":\"2019-07-05T04:45:48+00:00\",\"dateModified\":\"2023-07-17T06:13:21+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/\"},\"wordCount\":1430,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg\",\"keywords\":[\"container\",\"Docker\",\"Performance\",\"SQL Server\",\"Swarm\"],\"articleSection\":[\"Database Administration & Monitoring\",\"DevOps\",\"Docker\",\"SQL Server\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/\",\"name\":\"SQL Server containers and docker network driver performance considerations - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg\",\"datePublished\":\"2019-07-05T04:45:48+00:00\",\"dateModified\":\"2023-07-17T06:13:21+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg\",\"width\":500,\"height\":253},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"SQL Server containers and docker network driver performance considerations\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4\",\"name\":\"Microsoft Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g\",\"caption\":\"Microsoft Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"SQL Server containers and docker network driver performance considerations - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/","og_locale":"en_US","og_type":"article","og_title":"SQL Server containers and docker network driver performance considerations","og_description":"Few months ago I attended to the Franck Pachot session about Microservices and databases at SOUG Romandie in Lausanne on 2019 May 21th. He covered some performance challenges that can be introduced by Microservices architecture design and especially when database components come into the game with chatty applications. One year ago, I was in a […]","og_url":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/","og_site_name":"dbi Blog","article_published_time":"2019-07-05T04:45:48+00:00","article_modified_time":"2023-07-17T06:13:21+00:00","og_image":[{"width":500,"height":253,"url":"http:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg","type":"image\/jpeg"}],"author":"Microsoft Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Microsoft Team","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/"},"author":{"name":"Microsoft Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"headline":"SQL Server containers and docker network driver performance considerations","datePublished":"2019-07-05T04:45:48+00:00","dateModified":"2023-07-17T06:13:21+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/"},"wordCount":1430,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg","keywords":["container","Docker","Performance","SQL Server","Swarm"],"articleSection":["Database Administration & Monitoring","DevOps","Docker","SQL Server"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/","url":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/","name":"SQL Server containers and docker network driver performance considerations - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg","datePublished":"2019-07-05T04:45:48+00:00","dateModified":"2023-07-17T06:13:21+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/155-0-infra-docker-standalone-e1562307001328.jpg","width":500,"height":253},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/sql-server-containers-and-docker-network-driver-performance-considerations\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"SQL Server containers and docker network driver performance considerations"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/bfab48333280d616e1170e7369df90a4","name":"Microsoft Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/c44a1a792c059f24055763aa77d80a244467f6eef724a8bd13db8d4a350b7a4c?s=96&d=mm&r=g","caption":"Microsoft Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/microsoft-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12617","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/26"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=12617"}],"version-history":[{"count":1,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12617\/revisions"}],"predecessor-version":[{"id":26704,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/12617\/revisions\/26704"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/12618"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=12617"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=12617"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=12617"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=12617"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}