Есть твистед приложение и вот захотелось его помасштабировать на ядра процессора в результате родился такой код:
from twisted.internet import reactor;
from proxy import ProxyProtocolImpl;
import os;
reactor.listenUNIX("/tmp/twisted.sock", ProxyProtocolImpl());
for i in xrange(3):
l_pid = os.fork();
if(l_pid == 0):
break;
reactor.run()
Все вообщем то ничего только при shutdown приложения вывливаеться такая ошибка 3 раза:
Traceback (most recent call last):
File "/usr/local/lib/python2.6/site-packages/twisted/internet/defer.py",
line 249, in addCallbacks
self._runCallbacks()
File "/usr/local/lib/python2.6/site-packages/twisted/internet/defer.py",
line 441, in _runCallbacks
self.result = callback(self.result, *args, **kw)
File "/usr/local/lib/python2.6/site-packages/twisted/internet/base.py",
line 426, in _continueFiring
callable(*args, **kwargs)
File "/usr/local/lib/python2.6/site-packages/twisted/internet/base.py",
line 613, in disconnectAll
failure.Failure(main.CONNECTION_LOST))
--- <exception caught here> ---
File "/usr/local/lib/python2.6/site-packages/twisted/python/log.py", line
84, in callWithLogger
return callWithContext({"system": lp}, func, *args, **kw)
File "/usr/local/lib/python2.6/site-packages/twisted/python/log.py", line
69, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
File "/usr/local/lib/python2.6/site-packages/twisted/python/context.py",
line 59, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File "/usr/local/lib/python2.6/site-packages/twisted/python/context.py",
line 37, in callWithContext
return func(*args,**kw)
File "/usr/local/lib/python2.6/site-packages/twisted/internet/unix.py",
line 134, in connectionLost
os.unlink(self.port)
exceptions.OSError: [Errno 2] No such file or directory:
'/tmp//tmp/twisted.sock'
Вообщем то все понятно оставшиеся 3 процесса пытаються удалить файл сокета который уже удален породившим процессом.Задал я вопрос в комюнити твистеда на что мне ответили, что такое поведение не поддерживаеться, и дали вот такую ссылку:http://twistedmatrix.com/trac/ticket/4387Но честно говоря там по моему не совсем то что мне нужно. И почему поведение с fork не поддерживаеться тоже не понятно.
M>Есть твистед приложение и вот захотелось его помасштабировать на ядра процессора
M>Вообщем то все понятно оставшиеся 3 процесса пытаються удалить файл сокета который уже удален породившим процессом.Задал я вопрос в комюнити твистеда на что мне ответили, что такое поведение не поддерживаеться, и дали вот такую ссылку:http://twistedmatrix.com/trac/ticket/4387Но честно говоря там по моему не совсем то что мне нужно. И почему поведение с fork не поддерживаеться тоже не понятно.
Потому что они (и вы с ними тоже) жрут кактус из колбеков. Вот и злые на всех и всё.
Можно просто (потому что не меняя существующий код) запустить несколько процессов с разными сокетами и проксировать на них через haproxy.
Можно игнорить эту ошибку. Непонятно чем она мешает.
Re: twisted
>>Можно игнорить эту ошибку. Непонятно чем она мешает.
Да меня вообщем то особо не напрягает, но про то что fork не поддерживаеться я слышал краем уха, вот и стало интерсно, непонятно вообщем зачем городиь такой огород как по ссылке, бенефиты если честно не очень видны мне
M>Re: twisted M>PS про кактус не понял и про злые тоже
Писать код из макарон колбеков чуждо человеческому разуму. Это кактус, который они, как те мыши, колются, плачут, но продолжают грызть. То есть непрерывно насилуют свой мозг.
Тоже можно понять — не бросать же проект. Всё-таки обрабатывать много соединений он правда умеет. Но (видимо, точная причина неизвестна) из-за постоянной фрустрации колбеками, чуть что — делай как у нас, используй то что есть или gtfo. Такое впечатление относится к периоду выпуска версии 8.10, когда я пытался написать довольно простой HTTP клиент.
А можно так же обрабатывать много соединений и писать простой, понятный последовательный код в отдельных потоках. И люди в соответствующих сообществах добрые, помогают решить возникающие проблемы, а не заставляют делать по-своему.
Re[3]: twisted
Ну не знаю лично мне концепция Defred кажиться весьма элегантной, и только в твистеде я нашел нормальный ассинхронный http. Если вы по делитесь чем то лучшим то буду только признателен
M>Re[3]: twisted M>Ну не знаю лично мне концепция Defred кажиться весьма элегантной, и только в твистеде я нашел нормальный ассинхронный http. Если вы по делитесь чем то лучшим то буду только признателен
Концепция Deferred, она же Future — просто шикарная. Особенно для отложенных вычислений. А вот использовать её для всего — столь же вредно, сколь и питаться, например, всю жизнь только вкусным вареньем.
Не знаю что именно вы подразумеваете под "асинхронным HTTP". Сам протокол-то синхронный, ну, если не считать pipelining. И код писать удобно именно в синхронном стиле. Примерно так: httpconn.request("/"); r = httpconn.getresponse()... в таком количестве потоков, какое нужно. Весь сыр-бор с этими асинхронными фреймворками начался с того, что стандартных питонячих потоков много запустить не получится, потому что каждый из них обязательно связан ровно с одним OS потоком. И вместо того чтобы починить конкретно эту одну проблему нагородили такой ужас.
Что-то лучшее: eventlet, gevent. и, щас не вспомню, недавно ещё одна подобная библиотека появилась, как-то на s называется.
Re[5]: twisted >>Концепция Deferred, она же Future — просто шикарная. Особенно для отложенных вычислений. А вот использовать её для всего >>— столь же вредно, сколь и питаться, например, всю жизнь только вкусным вареньем.
Для отложенных вычислений наверное все таки подойдут какие нибудь очереди, но уж никак не ассинхронный IO
>>Не знаю что именно вы подразумеваете под "асинхронным HTTP". Сам протокол-то синхронный, ну, если не считать pipelining. И >>код писать удобно именно в синхронном стиле. Примерно так: httpconn.request("/"); r =
Хм, странно такое читать, нам например ассинхроннсть позволяет бороться с долгими вызовами 3 стороны особенно если на поток этих вызововов нужно сделать несколько, в результате чего ресурсы сервера не простаивают. Это очень эффективно. Для клиентский приложений ассинхроность может быть и не так востребована, хотя тут тоже можно поспорить. Плюс у питона есть GIL и хоть для IO эо наверное не очень критично но все же
eventlet, работать способен работать только под stacklesspython(по крайней мере у меня он постоянно валился в sigfault) единственной достойной альтенативой могу назвать только cogen, а вот про geevnt не знал
M>Re[5]: twisted >>>Концепция Deferred, она же Future — просто шикарная. Особенно для отложенных вычислений. А вот использовать её для всего >>— столь же вредно, сколь и питаться, например, всю жизнь только вкусным вареньем.
M>Для отложенных вычислений наверное все таки подойдут какие нибудь очереди, но уж никак не ассинхронный IO
А Deferred/Future это не про IO конкретно. Просто в Twisted IO сделан на Deferred. А сама концепция с IO жёстко не связана.
Очереди, конечно, в каких-то сценариях тоже очень хороши. Всё хорошо, когда оно к месту.
>>>Не знаю что именно вы подразумеваете под "асинхронным HTTP". Сам протокол-то синхронный, ну, если не считать pipelining. И >>код писать удобно именно в синхронном стиле. Примерно так: httpconn.request("/"); r =
M>Хм, странно такое читать, нам например ассинхроннсть позволяет бороться с долгими вызовами 3 стороны особенно если на поток этих вызововов нужно сделать несколько, в результате чего ресурсы сервера не простаивают. Это очень эффективно. Для клиентский приложений ассинхроность может быть и не так востребована, хотя тут тоже можно поспорить. Плюс у питона есть GIL и хоть для IO эо наверное не очень критично но все же
Либо следущий вызов по данным (нужно во втором запросе передать что-то из предыдущего) или логике (нужно подождать 5 секунд перед следущим запросом) зависит от предыдущего, тогда Deferred ничем не поможет — таки нужно дождаться ответа. И ресурсы тут не простаивают, пока один поток ждёт ответа — другие работают.
Либо не зависит (например, на странице 5 SSI инклюдов и нужно из них собрать целую и отдать) и тогда без Deferred тоже нужно было все 5 выполнять одновременно. То есть запустить 5 потоков, в каждом http.request. Это не страшно, если есть возможность запускать много потоков.
Кстати, для сценария SSI в качестве абстракции удобны именно Deferred/Future. Только в питоне удобной функции для этого нет, по понятным причинам. Но можно её написать, например, через Thread.start + Event.send. В eventlet/gevent поток может возвращать значение, то есть он заодно и Future-ом тоже является.
M>eventlet, работать способен работать только под stacklesspython(по крайней мере у меня он постоянно валился в sigfault) единственной достойной альтенативой могу назвать только cogen, а вот про geevnt не знал
eventlet способен работать (и успешно работает у многих людей, в продакшне) на обычном CPython 2.5 и 2.6. Может где-то и на 2.4 крутится, не знаю. С сегфолтом напишите в рассылку, помогут.
cogen, diesel дают то же самое что @inlineCallbacks у Twisted. Работает, конечно, но выглядит уж больно замусорено.
Re[7]: twisted>>Либо следущий вызов по данным (нужно во втором запросе передать что-то из предыдущего) или логике (нужно подождать 5 >>секунд перед следущим запросом) зависит от предыдущего, тогда Deferred ничем не поможет — таки нужно дождаться ответа. И >>>ресурсы тут не простаивают, пока один поток ждёт ответа — другие работают.
Ну в таком случае вложенный Defered (благо это не мой случай. Насчет простоя не согласен. Вот предположим у нас 20 обработчиков fastcgi, и прибежало скажем единовременно человек 300, 20 из которых ждут медленного ответа и все остальные 280 сосут и сервер тупо ждет ситуация имеет лавинообразный характер в результате по мере накопления очереди необработанных подключений fascgi клинеты наинают получать 502. Тут стоит заметить что не все запросы обрабатываються через медленную третью сторону, поэтому можно 20 клиентов соскладировать и принять остальные 280 подключений и ббыстренько отдать ответ, а для 20 да ответ сервера будет медленным впринцепе ничего страшного.
>>Либо не зависит (например, на странице 5 SSI инклюдов и нужно из них собрать целую и отдать) и тогда без Deferred тоже нужно >>было все 5 выполнять одновременно. То есть запустить 5 потоков, в каждом http.request. Это не страшно, если есть возможность >>запускать много потоков.
Так то создать поток довольно дорогая операция плюс стек, короче сосздавать потоки под IO imho очень дорого, плюс писать многопоточные приложения правильно очень не простая задача
M>Re[7]: twisted>>Либо следущий вызов по данным (нужно во втором запросе передать что-то из предыдущего) или логике (нужно подождать 5 >>секунд перед следущим запросом) зависит от предыдущего, тогда Deferred ничем не поможет — таки нужно дождаться ответа. И >>>ресурсы тут не простаивают, пока один поток ждёт ответа — другие работают. M>Ну в таком случае вложенный Defered (благо это не мой случай. Насчет простоя не согласен. Вот предположим у нас 20 обработчиков fastcgi, и прибежало скажем единовременно человек 300, 20 из которых ждут медленного ответа и все остальные 280 сосут и сервер тупо ждет ситуация имеет лавинообразный характер в результате по мере накопления очереди необработанных подключений fascgi клинеты наинают получать 502. Тут стоит заметить что не все запросы обрабатываються через медленную третью сторону, поэтому можно 20 клиентов соскладировать и принять остальные 280 подключений и ббыстренько отдать ответ, а для 20 да ответ сервера будет медленным впринцепе ничего страшного.
Можно иметь 5000 обработчиков, каждый в отдельном потоке, по одному на каждого клиента. Внутри 4-х процессов, по одному на каждое ядро. Каждый из процессов с одним OS потоком, потому что больше и не надо, ядра мы насилуем через процессы.
>>>Либо не зависит (например, на странице 5 SSI инклюдов и нужно из них собрать целую и отдать) и тогда без Deferred тоже нужно >>было все 5 выполнять одновременно. То есть запустить 5 потоков, в каждом http.request. Это не страшно, если есть возможность >>запускать много потоков.
M>Так то создать поток довольно дорогая операция плюс стек, короче сосздавать потоки под IO imho очень дорого, плюс писать многопоточные приложения правильно очень не простая задача
Потоки бывают не только POSIX pthreads. Например, у питона поток — по памяти в районе килобайта, его создание это "создать один объект", такой же как список или словарь. Довольно дешёво. Но каждый из них требует для себя отдельного OS потока. Вся соль в слове "отдельного".
, я примерно с этого и начал, да в этом проблема. Но если не трогать OS потоки, то операция совсем не дорогая. Не дороже создания Deferred объекта.
Про непростую задачу не так всё однозначно. Либо вы имеете в виду проблемы типа race condition и порчи данных, не защищённых мьютексами, тогда писать многопоточные приложения непростая задача в некоторых конкретных языках, к которым питон не относится. Либо вы имеете в виду какие-то общие проблемы зависимостей между независимыми блоками кода (к которым Deferred тоже относится), например, дедлоки. Они не от потоков, а просто человеческий фактор, неправильный код и с Deferred тоже бывают.
M>Вы имеете в виду зеленые треды что ли? (Ну корутины?)
Когда говорю, что код писать (а самое главное — читать) удобно синхронный, последовательный — нет, любые потоки подойдут.
Когда говорю какие средства доступны в питоне прямо сейчас, без ухищрений — да, eventlet, gevent и этот третий на s дают зелёные треды. Ну, в каком-то странном смысле, cogen, diesel, Twisted/inlineCallbacks тоже, но явный yield другим потокам, как в Windows 3 это жесть, их я не могу на одном уровне поставить.
Может быть есть какие-то проекты по созданию "незелёных" M:N userland вытесняющих потоков в питоне, я не в курсе. Было бы здорово.
. Насчет простоя не согласен. Вот предположим у нас 20 обработчиков fastcgi, и прибежало скажем единовременно человек 300, 20 из которых ждут медленного ответа и все остальные 280 сосут и сервер тупо ждет ситуация имеет лавинообразный характер в результате по мере накопления очереди необработанных подключений fascgi клинеты наинают получать 502. Тут стоит заметить что не все запросы обрабатываються через медленную третью сторону, поэтому можно 20 клиентов соскладировать и принять остальные 280 подключений и ббыстренько отдать ответ, а для 20 да ответ сервера будет медленным впринцепе ничего страшного.