konto usunięte

Temat: System transakcji python zamiast php ?

Witam,

Nacodzień używam php do obsługi frontu, do tej pory pythona wykorzystywałem do tworzenia robotów sieciowych i modyfikacji traca. Mam do wykonania system transakcyjny, który przetwarza ok tysiąc płatności dziennie w tle systemu napisanego w php. Nie dochodzi do integracji z przeglądarką. Jeden przebieg przetwarzania będzie trwał kilka godzin bez obsługi wątków (php). Bardzo ważne jest bezpieczeństwo całego procesu.

Zastanawiam się nad wykorzystaniem pythona lub javy zamiast php.
Spisałem sobie argumenty za i przeciw:

+ wątki (szybsze przetwarzanie, możliwość kontroli przepływu, pauzowania, wznawiania)
+ kontrola typów (mniejsza podatność na błędy i możliwość ich łapania)
+ lepsze zarządzanie pamięcią zużywaną przez proces

- jestem jedynym programistą w zespole który miał coś do czynienia z pythonem, trzeba się poduczyć

chcę wykorzystać sqlalchemy (dużo operacji na wielu tabelach) i threading.

Co o tym myślicie czy spotykacię z takim podejściem tzn php na froncie i python lub java w tle dla transakcji ?

konto usunięte

Temat: System transakcji python zamiast php ?

Michał Wujas:
+ wątki (szybsze przetwarzanie, możliwość kontroli przepływu, pauzowania, wznawiania)

python ma GIL'a więc wątki nie koniecznie będą oznaczać wzrost wydajności, jeśli jeden wątek przytka interpreter to reszta będzie czekać i okaże się, że ile byś wątków nie odpalił to wydajność (albo raczej "moc przerobowa") i tak jest ciągle ta sama, w pythonie lepiej użyć procesówŁukasz M. edytował(a) ten post dnia 01.09.09 o godzinie 18:25

Temat: System transakcji python zamiast php ?

w pythonie 2.6 jest wbudowana biblioteka multiprocessing: http://docs.python.org/library/multiprocessing.html do pythona 2.5 trzeba doinstalowac: http://pypi.python.org/pypi/multiprocessing/

Do tego mozna uzyc Manager'a do pamieci wspoldzielonej i lockow, co do bazy to jednak nabawialbym do recznej obslugi bez zadnych sqlalchemy, czy innych orm'ow ze wzgledu na niepotrzebna strate czasu procesora na rzutowania danych na obiekty.

Z samym sqlalchemy nie mialem doczynienia, ale djangowy orm jak dla mnie zuzywal duzo za duzo procesora.
Piotr Maliński

Piotr Maliński Programista
Python/Django

Temat: System transakcji python zamiast php ?

Sebastian Bauer:
Z samym sqlalchemy nie mialem doczynienia, ale djangowy orm jak dla mnie zuzywal duzo za duzo procesora.

A nie baza danych wykonująca ciężkie zapytanie? ;)

Temat: System transakcji python zamiast php ?

jesli strona/backend wykonuje duzo prostych zapytan to wiekszy moze byc narzut przy samym tworzeniu zapytania przez orma i konwersji tego na obiekty, chyba ze sie myle?

konto usunięte

Temat: System transakcji python zamiast php ?

bardziej chodziło mi o to że php słabo czyści pamięć ze śmieci, nie używanych zmiennych (garbage collector), w pythonie jest inaczej prawda ? ;-)

konto usunięte

Temat: System transakcji python zamiast php ?

Michał Wujas:
Nacodzień używam php do obsługi frontu, do tej pory pythona wykorzystywałem do tworzenia robotów sieciowych i modyfikacji traca. Mam do wykonania system transakcyjny, który przetwarza ok tysiąc płatności dziennie w tle systemu napisanego w php. Nie dochodzi do integracji z przeglądarką. Jeden przebieg przetwarzania będzie trwał kilka godzin bez obsługi wątków (php). Bardzo ważne jest bezpieczeństwo całego procesu.

Możesz napisać jaka jest natura tego przetwarzania? Z tego co napisałeś jedna płatność zajmuje Ci około kilkunastu sekund. Co zajmuje tak długi czas?

Wydaje mi się, choć nie znając szczegółów mogę się mylić, że to nie wybór technologii wpłynie na poprawę wydajności, a ponowne przemyślenie samego procesu przetwarzania.

konto usunięte

Temat: System transakcji python zamiast php ?

Skrypt kilka razy dziennie przetwarza transakcje bankowe, rozpoznaje opłaconą usługę, włącza ją co np wiąże się z operacjami plikowymi czy bazodanowymi oraz tworzy dokumenty (pdf) wysyła powiadomienia przez email etc.
Zagrożeniem dla takiego procesu jest wg mnie to że pojedyńcza operacja (np utworzenie katalogu dla nowo opłaconej usługi) w obrębie przetwarzania transakcji jest w stanie przerwać cały proces (np przez fatal error w php).
Trzeba by naprawiać błąd i uruchamiać cały proces od początku. A niestety czas na przeprowadzenie całego procesu jest ograniczony powiedzmy do kilku godzin (włącznie z reakcją programisty).
Rozwiązaniem dla php byłoby oparcie się na flagowaniu operacji w bazie danych ale to wydaję mi się nie eleganckie i mało praktyczne.

konto usunięte

Temat: System transakcji python zamiast php ?

Michał Wujas:
Skrypt kilka razy dziennie przetwarza transakcje bankowe, rozpoznaje opłaconą usługę, włącza ją co np wiąże się z operacjami plikowymi czy bazodanowymi oraz tworzy dokumenty (pdf) wysyła powiadomienia przez email etc.
Zagrożeniem dla takiego procesu jest wg mnie to że pojedyńcza operacja (np utworzenie katalogu dla nowo opłaconej usługi) w obrębie przetwarzania transakcji jest w stanie przerwać cały proces (np przez fatal error w php).

Ja bym poszedł w stronę jednego procesu wykrywającego płatności i odpalającego asynchronicznie (np. poprzez właśnie flagowanie w bazie) kilku innych wyspecjalizowanych procesów.

Niezależnie od tego jak to zrobisz - jestem już prawie pewny, że dla wydajności nie będzie miał znaczenia ani wybór PHP/Python, ani single/multithread, ani ORM/SQL itd. Na Twoim miejscu wybrałbym więc technologię, w której Twój zespół najszybciej stworzy działający system (oczywiście biorąc małą poprawkę na możliwość przyszłej rozbudowy i skalowalność rozwiązania).
Maciej Filipiak

Maciej Filipiak właściciel, VizMedia

Temat: System transakcji python zamiast php ?

A ja bym zwrócił większą uwagę na Waszym miejscu na pytanie Piotra.

Wszelkie transakcje na tabelach najlepiej, gdyby były po stronie SZBD w procedurach składowanych.
Aplikacja powinna tylko wysłać impuls do bazy z poleceniem wykonania zadania z odpowiednimi parametrami.

Polecam takie rozwiązanie.

konto usunięte

Temat: System transakcji python zamiast php ?

Maciej Filipiak:
A ja bym zwrócił większą uwagę na Waszym miejscu na pytanie Piotra.
Wszelkie transakcje na tabelach najlepiej, gdyby były po stronie SZBD w procedurach składowanych.

Chyba że tym SZBD jest mysql, który wg mojej wiedzy ma bardzo słabe debugowanie triggerów i procedur, logowanie błędów i tym podobne.
Na razie skłaniam się ku rozwiązaniu że flaguje wykonane części transakcji w bazie (np wygenerowana faktura, uruchomiona usługa, wysłany email)
Aplikacja powinna tylko wysłać impuls do bazy z poleceniem wykonania zadania z odpowiednimi parametrami.

Jeżeli są to tylko operacje bazodanowe to jak najbardziej wolę to przenosić do procedur.

Następna dyskusja:

PHP VS Ruby VS Python - pro...




Wyślij zaproszenie do