Как масштабировать слушателя TCP на современных многоядерных машинах / машинах мультисокета
Метод «retreive» объекта URL Opener поддерживает reporthook и создает исключение для 404.
http://docs.python.org/library/urllib.html#url-opener-objects
6 ответов
the easiest suggestion is to use libevent, it makes it easy to write a simple non-blocking single-threaded server that would comply with your requirements.
if the processing for each response takes some time, or if it uses some blocking API (like almost anything from a DB), then you'll need some threading.
One answer is the worker threads, where you spawn a set of threads, each listening on some queue to work. it can be separate processes, instead of threads, if you like. The main difference would be the communications mechanism to tell the workers what to do.
A different way to do is to use several threads, and give to each of them a portion of those 150K connections. each will have it's own process loop and work mostly like the single-threaded server, except for the listening port, which will be handled by a single thread. This helps spreading the load between cores, but if you use a blocking resource, it would block all the connections handled by this specific thread.
libevent lets you use the second way if you're careful; but there's also an alternative: libev. it's not as well known as libevent, but it specifically supports the multi-loop scheme.
Для повышения производительности select (2) было разработано несколько систем : kqueue , epoll и / dev / poll . Во всех этих системах у вас может быть пул рабочих потоков, ожидающих выполнения задач; вы не будете вынуждены настраивать все дескрипторы файлов снова и снова, когда закончите с одним из них.
Если производительность критична, тогда вам действительно нужно использовать решение многопоточного цикла событий - т.е. пул рабочих потоков для обработки ваших соединений. К сожалению, для этого не существует библиотеки абстракции, которая работает на большинстве платформ Unix (обратите внимание, что libevent является только однопоточным, как и большинство этих библиотек цикла событий), поэтому вы вам придется делать грязную работу самостоятельно.
В Linux это означает использование запускаемого по краю epoll с пулом рабочих потоков (Windows будет иметь порты завершения ввода-вывода, которые также отлично работают в многопоточной среде - Насчет других Unix я не уверен).
Кстати,
нужно начинать с нуля? Вы можете использовать что-то вроде gearman .
Если у вас есть доступ к конфигурации системы , не переусердствуйте и настройте некоторые iptables / pf / etc для соединений с балансировкой нагрузки через n экземпляров демонов (процессов), так как это будет работать из коробки. В зависимости от того, насколько блокирующий характер демона, n должно быть от количества ядер в системе или в несколько раз больше. Этот подход выглядит грубым, но он может обрабатывать сломанные демоны и даже перезапускать их при необходимости. Также миграция будет гладкой , поскольку вы можете начать перенаправление новых подключений к другому набору процессов (например, новый выпуск или переход на новый сервер) вместо прерывания обслуживания. Вдобавок к этому вы получаете несколько функций, таких как сходство источников , которые могут значительно помочь кэшированию и конкуренции проблемных сеансов.
Если у вас нет доступа к системе (или операторы не беспокоятся), вы можете использовать демон балансировщика нагрузки (их много с открытым исходным кодом) вместо iptables / pf / etc и используйте также n сервисных демонов, как указано выше.
Также этот подход помогает с разделением привилегий портов. Если внешняя служба должна обслуживать порт с низким уровнем (<1024), вам понадобится только балансировщик нагрузки, работающий с привилегиями / или администратором / корнем, или ядром.)
Я писал несколько балансировщиков IP-нагрузки в прошлом, и он может быть очень подверженным ошибкам при производстве. Вы не хотите поддерживать и отлаживать это. Кроме того, операции и управление будут иметь тенденцию предполагать ваш код больше, чем внешний код.
вы можете использовать демон балансировщика нагрузки (существует множество демонов с открытым исходным кодом) вместо iptables / pf / etc, а также использовать n сервисных демонов, как указано выше.Также этот подход помогает с разделением привилегии портов. Если внешняя служба должна обслуживать порт с низким портом (<1024), вам понадобится только балансировщик нагрузки, работающий с привилегиями / или администратором / корнем, или ядром.)
Я писал несколько балансировщиков IP-нагрузки в прошлом, и он может быть очень подверженным ошибкам при производстве. Вы не хотите поддерживать и отлаживать это. Кроме того, операции и управление будут иметь тенденцию предполагать ваш код больше, чем внешний код.
вы можете использовать демон балансировщика нагрузки (существует множество демонов с открытым исходным кодом) вместо iptables / pf / etc, а также использовать n сервисных демонов, как указано выше.Также этот подход помогает с разделением привилегии портов. Если внешняя служба должна обслуживать порт с низким уровнем (<1024), вам понадобится только балансировщик нагрузки, работающий с привилегиями / или администратором / корнем, или ядром.)
Я писал несколько балансировщиков IP-нагрузки в прошлом, и он может быть очень подверженным ошибкам в производстве. Вы не хотите поддерживать и отлаживать это. Кроме того, операции и управление будут иметь тенденцию предполагать ваш код больше, чем внешний код.
Если внешняя служба должна обслуживать порт с низким портом (<1024), вам понадобится только балансировщик нагрузки, работающий с привилегиями / или администратором / корнем, или ядром.)Я писал несколько балансировщиков IP-нагрузки в прошлом, и он может быть очень подверженным ошибкам в производстве. Вы не хотите поддерживать и отлаживать это. Кроме того, операции и управление будут иметь тенденцию предполагать ваш код больше, чем внешний код.
Если внешняя служба должна обслуживать порт с низким портом (<1024), вам понадобится только балансировщик нагрузки, работающий с привилегиями / или администратором / корнем, или ядром.)Я писал несколько балансировщиков IP-нагрузки в прошлом, и он может быть очень подверженным ошибкам в производстве. Вы не хотите поддерживать и отлаживать это. Кроме того, операции и управление будут иметь тенденцию предполагать ваш код больше, чем внешний код.
думаю, ответ Хавьера имеет наибольший смысл. если вы хотите проверить теорию, то посмотрите на проект узла javascript.
узел основан на движке Google v8, который компилирует javascript в машинный код и для некоторых задач работает так же быстро, как c. Он также основан на libev и спроектирован как полностью неблокирующий, что означает, что вам не нужно беспокоиться о переключении контекста между потоками (все выполняется в одном цикле обработки событий). В этом отношении он очень похож на erlang.
Написание высокопроизводительных серверов на javascript теперь очень, очень просто с помощью узла. Вы также можете, с небольшими усилиями, написать свой собственный код на c и создать привязки для узла, чтобы он вызывал его для выполнения вашей реальной обработки (посмотрите на исходный код узла, чтобы увидеть, как это сделать - документация немного эскизна в данный момент). В качестве более уродливой альтернативы вы можете собрать свой собственный код на си как приложение и использовать stdin/stdout для связи с ним.
Я сам протестировал узел, имеющий до 150k соединений, без абсолютно никаких проблем (конечно, вам понадобится некоторое серьезное аппаратное обеспечение, если все эти соединения будут общаться одновременно). TCP-соединение в node.js в среднем использует только 2-3k памяти, так что теоретически вы можете обрабатывать 350-500k соединений на 1 Гб оперативной памяти.
Примечание - Node.js в настоящее время не поддерживается на Windows, но находится только на ранней стадии разработки и я предполагаю, что он будет портирован на каком-то этапе.
Примечание 2 - вам нужно убедиться, что код, к которому вы обращаетесь из Node, не блокирует
.