Комментарии на: Building a Web Services in Python

От: kocmuk.ru

kocmuk.ru — Mon, 14 Dec 2009 17:04:15 +0000

Я бы помотрел для начала вот это: Response is «text/html», not «text/xml»

Это значит, что пришёл не XML ответ, а значит что-то не так. Можно включить трейс запросов и ответов через tracefile=sys.stdout. Или через tcpdump посмотреть запросы и ответы. Думаю, что там (в ответе) будет более понятная диагностика.

От: Valerikk

Valerikk — Mon, 14 Dec 2009 15:35:40 +0000

Что-то не получается с сервером Апач :(

Пишет:

Traceback (most recent call last):

File "", line 1, in

File «build/bdist.linux-i686/egg/ZSI/ServiceProxy.py», line 324, in __call__

File «build/bdist.linux-i686/egg/ZSI/ServiceProxy.py», line 300, in call_closure

File «build/bdist.linux-i686/egg/ZSI/client.py», line 452, in Receive

File «build/bdist.linux-i686/egg/ZSI/client.py», line 416, in ReceiveSOAP

TypeError: Response is «text/html», not «text/xml»

Где рыть?

От: kocmuk.ru

kocmuk.ru — Sat, 06 Sep 2008 18:52:09 +0000

Привет.

WS Security, когда безопасность на уровне самих сервисов — к сожалению, не делал. А вот безопасность на уровне транспорта (SSL, https) + Basic-аутентификация или аутентификация по SSL сертификатам — делал. ZSI отлично справляется с этим как клиент, а apache — как сервер. Вот так оно примерно выглядит.

От: Slach

Slach — Tue, 26 Aug 2008 11:07:51 +0000

а вы случайно не делали SOAP клиентов на Python с использованием WS Security?

От: kocmuk.ru

kocmuk.ru — Sun, 18 May 2008 19:46:33 +0000

Всё именно так! И это надо учитывать. Спасибо за комментарий, const.

Исходя из моего железа и предполагаемой нагрузки на это приложение — MPM prefork мой выбор. Apache в режиме MPM worker и multithreading-safe приложение — отдельный разговор.

От: const

const — Sun, 18 May 2008 17:44:07 +0000

В примере Apache использует MPM prefork. Опыт показывает, что даже не очень навороченное питоновское приложение легко может занять 20M памяти. И так на каждый апачевский процесс. Если использовать MPM worker, то память здорово экономится. Но надо учесть, что питоновский интерпретатор сможет обрабатывать два запроса параллельно только тогда, когда один из них занят операцией ввода-вывода (например, ждёт ответа от СУБД). Золотую середину можно поискать в конфигурации типа M worker'ов по N потоков. И в таком случае надо быть осторожным с глобальными объектами: они общие на все потоки в одном worker'е. Либо нужно от них отказаться, либо заворачивать их в threading.local.