C10k problem: Difference between revisions

Content deleted Content added
Monkbot (talk | contribs)
m Task 18 (cosmetic): eval 6 templates: del empty params (2×); hyphenate params (2×); del |format=HTML (2×);
make it clear that this is now an ex-problem
 
(37 intermediate revisions by 15 users not shown)
Line 1:
{{Short description|Problem of optimising network sockets to handle a large number of clients at the same time}}
 
The '''C10k problem''' iswas the problem of optimisingoptimizing computer [[networknetworking socketstack]]s to handle a large number of clients at the same time.<ref name=C10K>{{citeCite web|url=http://www.kegel.com/c10k.html |title=The C10K problem |archive-date=2013-07-1822 |archive-url=https://wwwweb.webcitationarchive.org/6ICibHuyd?url=web/20130722134723/http://www.kegel.com/c10k.html |url-status=live }}</ref> The name C10k is a [[numeronym]] for [[Concurrent computing|concurrently]] handling ten thousand connections.<ref name=Liu-Deters>{{Cite book | last1 = Liu | first1 = D. | last2 = Deters | first2 = R. | chapter = The Reverse C10K Problem for Server-Side Mashups | doi = 10.1007/978-3-642-01247-1_16 | title = Service-Oriented Computing – ICSOC 2008 Workshops | series = Lecture Notes in Computer Science | volume = 5472 | pages = 166 | year = 2009 | isbn = 978-3-642-01246-4 }}</ref> NoteHandling thatmany concurrent connections areis nota thedifferent sameproblem asfrom handling many [[requests per second]], though they are similar: handlingthe many requests per secondlatter requires high throughput (processing them quickly), while athe highformer numberdoes ofnot concurrenthave connectionsto be fast, but requires efficient scheduling of connections. Into other[[network words,socket]]s handlingor manyother requests[[stateful]] perendpoints. secondAs isof concerned with2025, the speedproblem ofhas handlinglong requests,since whereasbeen asolved, systemwith capablethe of handling a high numbernumbers of concurrentpossible connections does not necessarily have to be a fastsingle system,computer onlycapable oneof wherebeing eachin requestthe will deterministically return a response within a (not necessarily fixed) finite amount of timemillions.
 
The problem of socket server optimisation has been studied because a number of factors must be considered to allow a web server to support many clients. This can involve a combination of [[operating system]] constraints and web server software limitations. According to the scope of services to be made available and the capabilities of the operating system as well as hardware considerations such as multi-processing capabilities, a multi-threading model or a [[single threading]] model can be preferred. Concurrently with this aspect, which involves considerations regarding memory management (usually operating system related), strategies implied relate to the very diverse aspects of the I/O management.<ref name=Liu-Deters />
 
== History ==
The term ''C10k'' was coined in 1999 by '''software engineer Dan Kegel''',{{r|aosa2:nginx}}<ref name = "Dan Kegel, kegel.com, 1999" /> citing the [[Simtel]] FTP host, [[cdrom.com]], serving 10,000 clients at once over 1 [[gigabit per second]] [[Ethernet]] in that year.<ref name="C10K" /> The term has since been used for the general issue of large number of clients, with similar numeronyms for larger number of connections, most recently "C10M" in the 2010s to refer to 10 million concurrent connections.<ref name=":0C10M">{{Cite web|url=https://migratorydata.com/blog/migratorydata-solved-the-c10m-problem/|title=How MigratoryData solved the C10M problem: 10 Million Concurrent Connections on a Single Commodity Server|website=migratorydata.com|language=en|date=2015-05-20|access-date=2021-10-15|author=Mihai Rotaru}}</ref>
 
By the early 2010s millions of connections on a single commodity 1U rackmount server became possible: over 2 million connections ([[WhatsApp]], 24 cores, using [[Erlang (programming language)|Erlang]] on [[FreeBSD]]),<ref name = "WhatsApp blog, 2012" > {{ citeCite web | url = https://blog.whatsapp.com/196/1-million-is-so-2011 | title = 1 million is so 2011 | access-date = 25 July 2019 | date = 6 January 2012 | website = [[WhatsApp]] blog | quote = This time we also wanted to share some more technical details with you about hardware, OS and software: hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz hw.ncpu: 24 hw.physmem: 103062118400 hw.usermem: 100556451840 | archive-url = https://web.archive.org/web/20140501234954/https://blog.whatsapp.com/196/1-million-is-so-2011 | archive-date = 1 May 2014 | df = dmy-all }} </ref><ref name = "Reed, Erlang Factory, 2012" > {{ citeCite web | url = http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf | title = Scaling to Millions of Simultaneous Connections | access-date = 25 July 2019 | first = Rick | last = Reed | date = 30 March 2012 | website = Erlang Factory | format = pdf | page = 7 | archive-url = https://web.archive.org/web/20120709235656/http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf | archive-date = 9 July 2012 | df = dmy-all }} </ref> and 10–12 million connections (MigratoryData, 12 cores, using [[Java (Programming language)|Java]] on [[Linux]]).<ref name=":0C10M">[https://migratorydata.com//2015/05/20/how-migratorydata-solved-the-c10m-problem-10-million-concurrent-connections-on-a-single-commodity-server/ How MigratoryData solved the C10M problem: 10 Million Concurrent Connections on a Single Commodity Server]</ref><ref name="C10M-howto">[{{Cite web|url=https://migratorydata.com/2013blog/10/10/scalingmigratorydata-towith-12-million-concurrent-connections-how-migratorydata-did-itwebsockets/ |title=Scaling to 12 Million Concurrent Connections: How MigratoryData Did It]|website=migratorydata.com|language=en|date=2013-10-10|access-date=2021-10-15|author=Mihai Rotaru}}</ref>
The term was coined in 1999 by '''Dan Kegel''',{{r|aosa2:nginx}}<ref name = "Dan Kegel, kegel.com, 1999" /> citing the [[Simtel]] FTP host, [[cdrom.com]], serving 10,000 clients at once over 1 [[gigabit per second]] [[Ethernet]] in that year.<ref name="C10K" /> The term has since been used for the general issue of large number of clients, with similar numeronyms for larger number of connections, most recently "C10M" in the 2010s.<ref name=":0" />
 
Common applications of very high numbers of connections include general public servers that have to serve thousands or even millions of users at a time, such as [[file server]]s, [[FTP server]]s, [[proxy server]]s, [[web server]]s, and [[Load balancing (computing)|load balancers]].<ref name="conn-very-high-file">{{Cite book|url=https://books.google.com/books?id=cNwZ1snBYQYC&dq=file+server+very+high+number+of+connections&pg=PA470|title=High Performance Computing - HiPC 2008|language=en|year=2008|access-date=2021-10-15|author1=Ponnuswamy Sadayappan|author2=Manish Parashar|author3=Ramamurthy Badrinath|author4=Viktor K. Prasanna|publisher=Springer |isbn=978-3-540-89893-1}}</ref><ref name="C10M" />
By the early 2010s millions of connections on a single commodity 1U rackmount server became possible: over 2 million connections ([[WhatsApp]], 24 cores, using [[Erlang (programming language)|Erlang]] on [[FreeBSD]]),<ref name = "WhatsApp blog, 2012" > {{ cite web | url = https://blog.whatsapp.com/196/1-million-is-so-2011 | title = 1 million is so 2011 | access-date = 25 July 2019 | date = 6 January 2012 | website = [[WhatsApp]] blog | quote = This time we also wanted to share some more technical details with you about hardware, OS and software: hw.machine: amd64 hw.model: Intel(R) Xeon(R) CPU X5675 @ 3.07GHz hw.ncpu: 24 hw.physmem: 103062118400 hw.usermem: 100556451840 | archive-url = https://web.archive.org/web/20140501234954/https://blog.whatsapp.com/196/1-million-is-so-2011 | archive-date = 1 May 2014 | df = dmy-all }} </ref><ref name = "Reed, Erlang Factory, 2012" > {{ cite web | url = http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf | title = Scaling to Millions of Simultaneous Connections | access-date = 25 July 2019 | first = Rick | last = Reed | date = 30 March 2012 | website = Erlang Factory | format = pdf | page = 7 | archive-url = https://web.archive.org/web/20120709235656/http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf | archive-date = 9 July 2012 | df = dmy-all }} </ref> 10–12 million connections (MigratoryData, 12 cores, using [[Java (Programming language)|Java]] on [[Linux]]).<ref name=":0">[https://migratorydata.com//2015/05/20/how-migratorydata-solved-the-c10m-problem-10-million-concurrent-connections-on-a-single-commodity-server/ How MigratoryData solved the C10M problem: 10 Million Concurrent Connections on a Single Commodity Server]</ref><ref>[https://migratorydata.com/2013/10/10/scaling-to-12-million-concurrent-connections-how-migratorydata-did-it/ Scaling to 12 Million Concurrent Connections: How MigratoryData Did It]</ref>
 
Common applications of very high number of connections include pub/sub servers, chat, file servers, web servers, and software-defined networking.{{citation needed|reason=examples given are non-obvious and need justification.|date=July 2015}}
 
== See also ==
*[[Asynchronous I/O]]
*[[Load balancing (computing)]]
*[[Event-driven architecture]]
*[[Event-driven programming]]