W sumie po jakichś 6 godzinach spędzonych na próbach ustalenia miejsca błędu i zmuszenia biblioteki do poprawnej pracy, gdy moja rezygnacja sięgnęła dna pomyślałem: nie może być tak, że język tak dobrze wyposażony w biblioteki ma tak spapraną obsługę tej technologii. Zacząłem poszukiwania na nowo. Natknąłem się na wiele opinii typu „SOAP jest do bani jako taki i po co go chcesz implementować? lepiej zrób to w czym innym”. Tak kochani developerzy, a co w przypadku gdy ty tylko korzystasz z dostępu do aplikacji za pomocą SOAP, nie masz żadnego wpływu na korporację która ci tą aplikację dostarcza i na pewno nie przekonasz ich, że te setki tysięcy które przeznaczyli na wdrożenie powinni wyłożyć jeszcze raz na zorganizowanie sobie alternatywy np w postaci XML-RPC tylko dlatego, że ja używam języka który nie ma porządnej biblioteki do SOAP. Tym bardziej, że obsługa tejże technologii nie stwarza PHP czy Railsom większych problemów, cała implementacja to przygotowanie danych a potem 2 linijki na komunikację z serwerem aplikacji.

I wtedy udało się. Na StackOverflow natknąłem się na człowieka z tym samym problemem któremu ktoś podpowiedział: użyj suds – to naprawdę działa. Postanowiłem spróbować i rzeczywiście. Biblioteka suds daje radę. Może nie zrywa bereciku ale naprawdę , w porządnym pythonowym stylu, daje radę! Dołączenie biblioteki, 2 linijki kodu i o dziwo: jest, działa, obsługuje zdefiniowane w WSDL typy i enumeracje, inspekcję usług i wymaganych typów przez proste print obiektu, unicode itp…

Więc jeśli ktoś z was też „wie”, że SOAP w Pythonie jest beznadziejny to polecam suds.

itk działa bardzo podobnie do prefork, mianowicie w momencie gdy przychodzi żądanie, sprawdza jakiego vhosta ono dotyczy i dokonuje: „fork & setgid & setuid” a po zakończeniu serwowania zabija proces pochodny. Ah, i gdzie tu zysk z prefork które miało zapewniać obsługę iluśtam requestów na już wcześniej przygotowanym zforkowanym procesie? No właśnie ten zysk znika z powodu kolejnego forka w środku :/

peruser ma to rozwiązane znacznie lepiej, lecz wymaga dokładniejszej konfiguracji. peruser tworzy, tak samo jak prefork, określoną pulę procesów i już na tym etapie dokonuje setgid & setuid, nie mamy tu zależności: jeden request = jeden proces (fork & … & kill)

Ale dość teorii, oto linki w których możecie poczytać jak konfigurować zarówno itk jak i peruser i przejdźmy już do testów.

Do testowania posłużył mi siege, domyślny WordPress na mysql (mod_php i php-cgi) oraz prosty serwis django (mod_python).

Siege wywoływane było dla każdego przypadku tak: siege -c 20 -b -t 1m URL

itk, mod_python (django):
Transactions:                    566 hits
Availability:                  99.65 %
Elapsed time:                  63.20 secs
Data transferred:               0.61 MB
Response time:                  1.87 secs
Transaction rate:               8.96 trans/sec
Throughput:                     0.01 MB/sec
Concurrency:                   16.74
Successful transactions:         565
Failed transactions:               2
Longest transaction:           28.07
Shortest transaction:           0.25
peruser, mod_python (django):
Transactions:                  17422 hits
Availability:                 100.00 %
Elapsed time:                  59.55 secs
Data transferred:              16.13 MB
Response time:                  0.07 secs
Transaction rate:             292.56 trans/sec
Throughput:                     0.27 MB/sec
Concurrency:                   19.97
Successful transactions:       17422
Failed transactions:               0
Longest transaction:            5.10
Shortest transaction:           0.01

itk, php5cgi (wordpress):
Transactions:                    757 hits
Availability:                  99.87 %
Elapsed time:                  61.29 secs
Data transferred:              11.13 MB
Response time:                  1.53 secs
Transaction rate:              12.35 trans/sec
Throughput:                     0.18 MB/sec
Concurrency:                   18.91
Successful transactions:         757
Failed transactions:               1
Longest transaction:           29.51
Shortest transaction:           0.19
peruser, php5cgi (wordpress):
Transactions:                    762 hits
Availability:                 100.00 %
Elapsed time:                  61.12 secs
Data transferred:              11.24 MB
Response time:                  1.57 secs
Transaction rate:              12.47 trans/sec
Throughput:                     0.18 MB/sec
Concurrency:                   19.57
Successful transactions:         762
Failed transactions:               0
Longest transaction:           17.14
Shortest transaction:           0.19

itk, mod_php5 (wordpress):
Transactions:                    814 hits
Availability:                  99.88 %
Elapsed time:                  60.95 secs
Data transferred:              11.52 MB
Response time:                  1.31 secs
Transaction rate:              13.36 trans/sec
Throughput:                     0.19 MB/sec
Concurrency:                   17.54
Successful transactions:         814
Failed transactions:               1
Longest transaction:           22.11
Shortest transaction:           0.17
peruser, mod_php5 (wordpress):
Transactions:                   1034 hits
Availability:                 100.00 %
Elapsed time:                  64.72 secs
Data transferred:              14.63 MB
Response time:                  1.21 secs
Transaction rate:              15.98 trans/sec
Throughput:                     0.23 MB/sec
Concurrency:                   19.34
Successful transactions:        1034
Failed transactions:               0
Longest transaction:           24.50
Shortest transaction:           0.15

Wnioski? Jest szybciej (no może poza CGI ale czego tu oczekiwać jak w obu przypadkach i tak następuje exec binarki PHP), w jednych przypadkach więcej (mod_python/django naprawdę szczęka opada) a w innych mniej. Tak czy inaczej do konkretnych zastosowań warto przeprowadzić testy samemu bo jak uczy praktyka – nie ma rzeczy idealnych do wszystkiego…