Jarosław Zabiełło - BLOG: Category PHP

Ruby 1.9 (YARV) vs. Python, Lua & PHP

Jarosław Zabiełło — Mon, 01 Jan 2007 19:36:00 +0100

Korzystając z tego, że niedawno do repozytorium Rubiego został dodany YARV (wirtualna maszyna Rubiego) pokusiłem się o małe porównanie wydajności. Jako test użyłem prostego programu jaki pojawił się na liście pl.comp.lang.pyhon (musiałem tylko trochę zwiększyć pętle do 10 milionów iteracji, aby były widoczne jakieś wyniki) Użyty sprzęt: Athlon64 3700+, 64bit Ubuntu 6.0.6.

Sprawdziłem też z ciekawości PHP 5.2 na tym samym sprzęcie. Dla tak prostego testu powinien móc dać z siebie wszystko. Jest jednak wolniejszy od Rubiego 1.9.

Kod dla Pythona:

import time
t=time.time()
a=0
for i in xrange(10000000):
    a += i
print a
print time.time() - t

Kod dla Lua:

t = os.clock()
a = 0
for i = 1,10000000 do
    a=a+i
end
print(a)
print(os.clock() - t)

Kod dla Rubiego:

t = Time.now
a = 0
for i in 1..10_000_000
  a = a+i
end
puts a
puts Time.now - t

Kod dla PHP:

<?php
function microtime_float() {
 $time = microtime();
 return (double)substr($time, 11) + (double)substr($time, 0, 8);
}
$t =  microtime_float();
$a = 0;
for ($i = 0; $i < 10000000; $i++) {
  $a += $i;
}
print "$a\n";
print  microtime_float()- $t;
?>

Wyniki:

Lua: 1.14 s
Ruby 1.9: 1.49 s
PHP 5.2: 1.74 s
Python 2.5: 2.64 s
Python 2.4.3: 2.72 s
Ruby 1.8.5: 3.83 s.

Drugie podejście

Tym razem wynik uśredniam dla 10 prób. Zwiększyłem ilość iteracji do 20 mln. No i… Ruby 1.9 pobił wszystko. Zarówno Pythona jak i Lua! (PHP 5.2 po 30 sek. zgłosił timeout. Musiałem więc uśrednić po 5 wynikach.)

PYTHON

import time
def bench():
    a, t = 0, time.time()
    for i in xrange(20000000):
        a+=i
    return time.time()-t
result = 0
for i in range(10):
  result += bench()
print result / 10.0

RUBY

def bench
  a, t = 0, Time.now
  20_000_000.times { |i| a += i }
  Time.now - t
end
result = 0
10.times { |i| result += bench }
puts result / 10

LUA

function bench()
  a = 0
  t = os.time()
  for i = 1, 20000000 do
    a = a + i
  end
  return os.time() - t
end
result = 0
for x = 1,10 do
  result = result + bench()
end
print(result/10)

PHP

<?php
function bench() {
  $a = 0;
  $t =  time();
  for ($i = 0; $i < 20000000; $i++) $a += $i;
  return time() - $t;
}
$result = 0;
for ($x = 1; $x <= 5; $x++) $result += bench();
print $result / 5.0;
?>

Wyniki

Ruby 1.9: 2.0953268 s.
Lua 5.1: 2.4 s.
Python 2.5: 2.49481592178 s.
Python 2.4.3: 2.71687791348 s.
PHP 5.2: 4.2 s.
Ruby 1.8.5: 9.0153751 s.

Jestem ciekaw kiedy wyjdzie Rails dostosowany do Ruby 1.9. Zapowiada się bardzo obiecująco!

Django i Rails biją PHP

Jarosław Zabiełło — Fri, 14 Jul 2006 17:34:00 +0200

Porównanie wydajności trzech frameworków: Symfony, Ruby on Rails i Django pokazuje że Rails jest znacznie szybszy od pehapowego Symfony, a Django znacznie szybszy od Railsów. Co ciekawe, PHP5 używał akceleratora.

Lightpd & FastCGI vs. Apache & mod_php,mod_python...

Jarosław Zabiełło — Mon, 24 Apr 2006 19:40:00 +0200

Serwer Apache jest bardzo popularnym i solidnym serwerem www. Nie dziwi więc powszechne używanie jego modułow do obsługi Perla, PHP czy Pythona. Uzywanie mod_php jest wręcz nagminne (cały serwis sourceforge.net stoi na mod_php). Podobnie twórcy pythonowego frameworku Django zalecają używanie mod_pythona. W dokumentacji piszą, że:

“jeśli chcesz używać Django na serwerze produkcyjnym, uzywaj Apache’a z mod_pythonem (...) Django wymaga Apache 2.x oraz mod_python 3.x.”

Zupełnie inne podejście zalecają twórcy frameworka Ruby on Rails. Nie dość, że zalecają użycie modułu FastCGI to na dodatek, zalecają (o grozo:) używanie innego serwera www: Ligttpd. Które podejście jest lepsze?

Problem z uniwersalnością

Korzystanie z modułów Apache’a wiąże nas na dobre i złe z tym serwerem. korzystanie z fastcgi daje nam większe pole manewru. Możemy korzystać z Apache, Lighttpd, IIS i innych serwerów www.

Problem stabilności serwera

Jakikolwiek błąd w skryptach pracujących w trybie mod_php czy mod_python odbija się bardzo niebezpiecznie na stabilności całego serwera. Jeden błędnie działający skrypt może zawiesić cały serwer! Dotyczy to nie tylko Apache, ale także windowsowego IIS i modułów ISAPI. Co ciekawe, moduł ISAPI dla języka PHP jest wiecznie w fazie niestabilnej i testowej. Co z tego, że jest szybszy niż klasyczny CGI, skoro jeden drobny błąd w skrypcie PHP potrafi zawiesić cały serwer i unieruchomić cała sieć intranetową na nim opartą? To jeden z powodów dla których PHP nie nadaje się najlepiej do pracy pod Windowsami (wiem, że istnieje Apache/win32 ale z różnych powodów, których tu nie będę rozwijał, korporacyjne sieci intranetowe oparte na Windows Server wolą używać IIS)

Procesy FastCGI są izolowane od serwera. Jak któryś się zawiesi, to serwerowi nic się nie stanie. Proces można ubić, zrestartowac. Daje to znacznie większą stabilność pracy serwera.

Problem bezpieczeństwa

Każdy skrypt odpalany w trybie mod_php na Apache’u jest odpalany w kontekście tego samego uzytkownika. Tworzy to dosyć poważną dziurę bezpieczeństwa na serwerach hostingowych. Każdy użytkownik na serwerze za pomocą prostego kodu PHP może przeglądać źródła dowolnego pliku innych użytkowników. Wszyscy mają dostęp do wszystkich! Napisałem nawet swego czasu prosty skrypt wedrujący po całym sourceforge.net i przeglądający źródła wszystkich dostępnych tam projektów. :) Każdy, średnio zaawansowany programista z łatwością napisze sobie taki kod. Nie ma znaczenia, czy to będzie Perl (mod_perl), Python (mod_python) czy PHP (mod_php).

W FastCGI tego problemu nie ma. Każdy użytkownik może pracować na swoich prawach w pełnej izolacji. Wystarczy każdemu przydzielić po procesie FastCGI na prawach danego użytkownika.

Marnowanie możliwości Apache’a 2.x

To może nie jest najważniejszy problem. Apache 2.x potrafi pracować w trybie wielowątkowym (worker) lub wieloprocesowym (prefork) który jest zgodny ze starym Apache 1.x . Ten pierwszy jest nowocześniejszy, szybszy i pożera mniej pamięci. Problem jednak w tym, że najbardziej popularny język skryptowy nie posiada poprawnie zaimplementowanej wielowątkowości. Jeśli więc chcesz używać PHP, to zapomnij o trybie workera. Musisz pracować w starym trybie prefork. Zajmuje to więcej pamięci, ale za to nie będzie problemów z różnymi bibliotekami PHP.

Problem zasobożerności

Gdy uruchamiamy Apache 1.x lub Apache 2.x w trybie prefork, uruchamiamy szereg podprocesów. Każdy z nich zajmuje określoną ilość pamięci. Każdy z zainstalowanych modułów… również. A to przecież nie ma sensu! W praktyce nie chcemy wykorzystywać wszystkich procesów do przetwarzania mod_pythona. Większość procesów jest zajęta podawaniem statycznej wartości (obrazki, pliki ze stylami kaskadowymi, skryptami JavaScript itp).

FastCGI pozwala na ograniczenie ustalenie ilości swoich procesów w sposób niezależny od wszystkich procesów serwera www. Np. możemy sobie zadecydować, aby 100 procesów zajmowało się wartością statyczną, a tylko 10 wartością dynamiczną. Takie coś jest niemożliwe wypadku korzystania z mod_php czy mod_pythona. A oszczędności na zużyciu pamięci będą kolosalne!

Np. można załozyć, że pojedyńczy proces Apache podczas serwowania statycznych stron zajmie nie więcej niż ok 5 MB pamięci. Natomiast w wypadku użycia mod_ruby może wzrosnąć nawet do ok. 20-30MB na proces. Użycie zatem 100 procesów Apache’a z tylko 10 procesami FastCGI zużyje ok. 800MB pamięci. Zaś użycie mod_ruby bez problemu pożre nawet i 3GB!

Dlaczego Lighttpd a nie Apache?

Na końcu chciałbym jeszcze zastanowić się czy twórcy Railsów nie mają racji i czy w ogóle nie warto zrezygnować z Apache na rzecz Lighttpd? Są generalnie 3 powody za i jeden przeciw.

Za: lepiej dopracowany moduł FastCGI

Moduł FastCGI do Apache’a ma opinię nie do końca stabilnego i dopracowanego. To powoduje obawę większości użytkowników od używania go dla serwera Apache. Z kolei serwer Lighttpd od samego początku kładł nacisk na dobrą implementację swego modułu FastCGI. Jest on stabilniejszy i lepiej dopracowany niż pod Apachem.

Za: Wbudowana możliwość rozkładania obciążenia

Lighttpd ma wbudowany mechanizm rozkładania ruchu na wiele serwerów. Jeśli więc nawet ktoś upiera się przy Apache’u, to w wypadku kiedy jeden serwer nie jest wystarczający do obsługi ruchu, może warto rozważyć aby postawić na froncie jeden serwer Lighttpd który by rozkładał ruch pomiędzy kilka serwerów?

(Najnowszy Apache 2.2 ma posiadać podobny mechanizm. Jednak jest to jeszcze bardzo świeża wersja, która (w momencie pisania tego tekstu) nie ma nawet prekompilowanej instalacji dostępnej dla Windowsów oraz nie wiadomo jak jest ze stabilnością wszystkich modułów.)

Za: Lighttpd jest szybszy

O ile najnowszy Apache 2.2 nie zmieni sytuacji, to wszystko wskazuje na to, ze Lighttpd jest po prostu szybszy. Nie tylko zdecydowanie szybciej podaje statyczne dane ale także szybciej działa PHP pod Lighttpd niż mod_php pod Apachem. To nie są drobne różnice. To są różnice rzędu 2-3 razy!

Przeciw: Apache ma więcej modułów

Właściwie jedynym powodem aby używać Apache zamiast Lighttpd jest to, że do Apache napisano znacznie więcej różnych modułów. Ale szczerze mówiąc, w praktyce to rzadko ma znaczenie. Większość osób uzywa głównie kilku modułów. Zaś Lighttpd posiada praktycznie wszystko, co potrzeba: mod_fastcgi, mod_cgi, mod_redirect, mod_access, mod_auth, mod_compress, mod_webdav, mod_ssl, mod_alias, mod_proxy, mod_rewrite, itp. itd.

Lighttpd + FastCGI. To działa!

Na szczęście, dzięki standardowi WSGI, użytkownicy Pythona nie muszą słuchać zaleceń developerów Django. Teraz praktycznie wszystkie frameworki Pythona pozwalają dzięki WSGI korzystać z dobrodziejstw FastCGI. Ja również na swoim serwerze wyrzuciłem Apache’a i zastapiłem go Lighttpd. Podaje zarówno strony statyczne jak i obsługuje ten blog, a nawet PHP 5.1. Nawet Plone mi udało mi się uruchomić z Lighttpd na przodzie.

Edytory dla Pythona, Ruby, PHP

Jarosław Zabiełło — Sun, 12 Feb 2006 00:17:00 +0100

Osoby zaczynające pracę z językiem Python, Ruby czy PHP często pytają się na grupach dyskusyjnych na temat edytorów zalecanych do pracy. Istnieją dwie szkoły, ci którym zależy na minimalnych wymaganiach pamięci i procesora oraz ci, którzy chcieliby aby edytor nie tylko kolorował składnię, ale także podpowiadał kod, uzupełniał składnię, miał wbudowany debugger itp.

Edytory tekstowe (nie IDE):

SciTE – łatwy w obsłudze, kolorowanie b. wielu języków

Vim – powszechny na każdym linuksie, jest wersja dla win32. B. szybki, doskonały do obsługi wielkich plików, niezbyt intuicyjna obsługa, np. kto by wpadł na pomysł aby wyjść z edytora za pomocą kombinacji: Esc + :q! (klawisz Escape, potem znak cudzysłowa, małe q i znak wykrzyknika)

Notepad++ – prosta, intuicyjna obsługa, po instalacji podmienia dla Internet Explorera idiotycznego Notatnika do podglądu źródeł stron html, warto instalować choćby dla tej jednej cechy i wymiany starego Notatnika.

JEdit – napisany w Javie, mnóstwo pluginów

XEmacs – kompletnie nieintuicyjna obsługa, ten edytor zupełnie w niczym nie przypomina skrótów klawiszy z innych programów, ale jest b. potężny. Jak ktoś już się przekatuje i go nauczy, to podobno jest to doskonałe narzędzie. Mnie nigdy nie starczyło cierpliwości aby go opanować. Wolę już edytor Vi.

Edytory IDE – Python

Użytkownikom win32 polecam instalację ActivePython zamiast instalacji na stronie główej Pythona. Do Pythona istnieje mnóstwo niezłych edytorów tekstowych jak i edytorów IDE. Moimi ulubionymi są:

Eclipse + pyDEV – chyba najlepsza opcja. Edytor Eclipse jest napisany w Javie i wymaga trochę pamięci, ale jest b. dobry. Posiada intuicyjny interfejs, mnóstwo pluginów dających spójne środowisko do pracy z javą, pythonem, ruby i php. pyDEV z zintegrowanym pakietem pyLint nie tylko podpowiada kod, ale także ma możliwość wyłapania nieużytej zmiennej, czy brak zgodności stylu programowania z zaleceniem PEP8 itp. Oczywiście jest też zintegrowany debugger.

PythonWin – standardowo instalowany w ActivePython. Jest znacznie szybszy i lżejszy od Eclipse, bo jest napisany w języku C. Ma świetny debugger, wbudowaną konsolę, podgląd obiektów COM. Jedyną jego wadą jest brak obsługi utf-8. Zaletą jest też to, że nadaje się do szybkiej edycji pojedyńczych plików (Eclipse wymaga tworzenia projektu, co często jest b. niewygodne). PythonWin ma także ulepszoną konsolę, bo pełnoekranową. Łatwiej w nim szybko zaznaczyć fragment poprzedniej komendy i uzupełnić.

SPE – edytor napisany w Pythonie z wykorzystaniem biblioteki wxPython. Ma unikalne, b. ładne kolorowe zakładki (umożliwia lepsze wyświetlanie podglądu metod i atrybutów klas). Wbudowany debugger, listę Todo, wyszukiwanie po wielu plikach i co ważniejsze: lepiej podpowiada kod niż np. PythonWin.

Eric – napisany w Pythonie z użyciem biblioteki PyQT. Ma dużo możliwości, wspomaganie tworzenia unittestów, refactoring, debugger itp. Obsługuje nie tylko Pythona ale i Rubiego.

Boa Constructor – ten edytor może zainteresować osoby piszące aplikacje oparte na wxPython bo posiada wbudowane wizualne wspomaganie tego procesu. Wzorowany jest na Delphi.

Komodo: Kombajn podobnie jak Eclipse. Występuje w wersji IDE (płatnej, ale licencja od razu obejmuje Windows, Linux i Mac OS X) i Edit (bezpłatnej). Ma świetny debuger do Pythona. Jest szybszy od Eclipse i obsługuje dobrze Pythona, Rubiego, PHP, C++ i inne języki (nawet szablony Django). Bardzo dobrze podpowiada kod HTML, CSS, zamyka tagi HTML podobnie jak Dreamweaver. Niestety, podpowiadanie kodu pozbawione jest na razie wyświetlania zintegrowanej dokumentacji (docstringów dla Pythona czy rdoc dla Rubiego, wyświetlana jest tylko lista metod).

WingIDE – wymieniam go na końcu bo jest płatny. Doskonale (zdecydownie najlepiej z wszystkich) podpowiada kod, posiada możliwość edycji w Zope, doskonały debugger.

Edytory IDE – Ruby

Do Rubiego istnieje też sporo niezłych edytorów, choć nie aż tyle co do Pythona.

Netbeans IDE 6.x ma zdecydowanie najlepsze podpowiadanie składni do Rubiego. Najlepszy IDE do Rubiego i Rails obok Aptana IDE.

Aptana IDE+Rails (RadRails został przejęty) to nic innego jak Eclipse dostosowany do pracy z Ruby on Rails. Posiada wszystkie zalety Eclipse, np. po dodaniu pluginów ma dobre wsparcie dla innych języków, np. Pythona. Od chwili wchłonięcia RadRails przez Aptanę, posiada świetne dodatkowe mocne wsparcie dla kodu HTML, CSS, JavaScript.

Arachno IDE – bardzo ładny i szybki. Może kolorować kod (nie tylko samego Rubiego ale także szablonów ERb, czyli nadaje się dobrze do Railsów) podobnie jak TextMate, ma wbudowany debugger, generowanie dokumentacji RDoc dla projektu, przeglądarka klas Rubiego i zainstalowanych gemsów. Niestety jest płatny i bieżąca wersja nie obsługuje jeszcze utf-8.

TextMate – działa tylko z systemem OS-X, czyli wymaga Macintosha. Ale jest to ulubiony edytor developerów Railsów. Sam edytor jest niestety płatny. Ma bardzo rozbudowane makra (snipety) przyśpieszające wprowadzanie kodu, ale ma beznadziejnie słabe podpowiadanie kodu, nie rozwija metod do bibliotek wbudowanych Rubiego, dokumentacji RDOC w ogóle nie ma scalonej z podpowiedziami do kodu. Do Pythona jest jeszcze gorzej. Ale edytor jest szybki, lekki i ma ładne kolorowanie wielu języków.

RDE czyli Ruby Development Environmnent. Edytor jest b. szybki i pomocny jak ktoś chce pisać kod w czystym Ruby.

Edytory IDE – PHP

Do PHP istnieje sporo edytorów, ale moim zdaniem większość to badziewie. Sam PHP jest językiem który bardzo utrudnia napisanie na niego dobrego debuggera. Właściwie w nic dobrego tu nie ma poza komercyjnym Zendem. Ale gdybym miał wybierać, to wybrałbym:

Eclipse + plugin phpeclipse – po pierwsze jest darmowy, po drugie doskonale zarządza kodem PHP i koloruje szablony Smarty. Po trzecie, doskonale współpracuje z SVN. Miałem okazję sprawdzić nowy Zend Studio 5.1. Mimo, że lepiej podpowiada kod, to nie koloruje Smartów i kiepsko współpracuje z SVN, beznadziejnie wręcz.

Zend Studio – komercyjny IDE stworzony przez twórców PHP. Najlepiej ze wszystkich podpowiada kod (lepiej od Eclipse) Niestety nie potrafi kolorować kodu popularnych szablonów Smarty (Eclipse to potrafi!) Szybkość ta sama co Eclipse, wymagania co do pamięci – też.

Macromedia Dreamwever 8 – komercyjny, ale nieźle koloruje i podpowiada kod. Najnowsza wersja Dreamweawera ma sporo usprawnień, np. w końcu bada końce bloków (klamr). Dreamweawer jest też oczywście szybszy od Zend Studio i Eclipse bo jest napisany w języku C.

Niestety edytory PHP mają fatalne możliwości debugowania kodu w stosunku do tego, co można spotkać dla Pythona i Ruby. Do szybkiego testowania kodu PHP, najlepiej użyć SciTE. Można mu ustawić opcję aby po wciśnięciu klawisza F5 natychmiast generował wynik bez żadnego pośrednictwa serwera www.

Symfony - kolejny naśladowca RoR

Jarosław Zabiełło — Tue, 10 Jan 2006 07:30:00 +0100

Pojawia się coraz więcej naśladowców drogi jaką podążają frameworki Ruby on Rails i Django. Bardzo ciekawie wygląda pehapowy framework Symfony. Polecam przyjrzeć się udostępnionemu na stronie głównej filmowi.

Brakująca metoda GetMany dla ADOdb

Jarosław Zabiełło — Tue, 15 Nov 2005 12:01:00 +0100

Jedną z najlepszych bibliotek opakowujących połączenia do baz relacyjnych dla PHP jest "ADOdb":http://adodb.sf.net. Pomijając wiele zalet używania ADOdb (zintegrowany cache, moduł w C, czytelne API) zamiast PEAR::DB lub natywnych (i koszmarnych składniowo) funkcji PHP chciałbym zatrzymać się nad jedną niedoróbka. Otóż od dawna brakuje tam Funkcji GetMany() która byłaby odpowiedzialna za pobieranie porcji danych z bazy. Jest co prawda funkcja SelectLimit() ale jest jest beznadziejna gdyż nie umożliwia korzystania z parametryzowanych zapytań SQL. Poza tym ma fatalną, nieintuicyjną nazwę. Skoro jest GetOne(), GetAll(), GetRow() to dlaczego jej też nie nazwali GetMany()? Postanowiłem te braki uzupełnić. Poniżej przykład implementacji opartej na ADOdb:

<?php
require_once 'adodb/adodb.inc.php';
require_once 'adodb/adodb-errorhandler.inc.php';

class Database
{
    var $conn;
    
    function Database($cfg)
    {
        $this->conn =& NewADOConnection($cfg['dbtype']);
        $this->conn->Connect(
            $cfg['host'], 
            $cfg['user'], 
            $cfg['passwd'], 
            $cfg['db']);
         $this->conn->SetFetchMode(ADODB_FETCH_ASSOC);
    }
    
    function GetAll($sql, $params=null)
    {
        return $this->conn->GetAll($sql, $params);
    }
       
    function GetRow($sql, $params=null)
    {
        return $this->conn->GetRow($sql, $params);
    }   
    
    function GetOne($sql, $params=null)
    {
        return $this->conn->GetOne($sql, $params);
    }   
    
    function GetMany($sql, $params=null, $from, $limit)
    {
        $result = array();
        $recordSet = $this->conn->Execute($sql, $params);
        while (!$recordSet->EOF) {
            if ($from > 0) {
                $from -= 1;
                $recordSet->MoveNext();
            } elseif ($limit > 0) {
                $limit -= 1;
                $result[] = $recordSet->fields;
                $recordSet->MoveNext();
            } else {
                $recordSet->MoveNext();
            }
        }
        return $result;
    }   
}

$cfg = array(
    'dbtype' => 'mysql',
    'host' => 'localhost',
    'user' => 'root',
    'passwd' => '',
    'db' => 'baza',
    );

# przykład:

$db = new Database($cfg);
var_dump($db->GetMany("SELECT * FROM tabelka", null, 0, 10));
?>