Jarosław Zabiełło - BLOG: Tag benchmark

Passenger bliżej - Rails, Rack i WSGI

Jarosław Zabiełło — Sat, 07 Jun 2008 15:24:00 +0200

Stworzony pierwotnie na użytek Rails, aktualnie mod_passenger już obsługuje nie tylko Rails ale także masę innych frameworków używających Rack’a. W nowej dokumentacji wymienione są frameworki: Camping, Halcyon, Mack, Merb, Ramaze i Sinatra. W dokumentacji nie wymieniono jeszcze “drugiej listy”, zawierającej frameworki korzystające z WSGI i Pythona (np. Pylons, Django, TurboGears itp.). Chcąc sprawdzić plotki wokół tej sprawy, sprawdziłem, czy faktycznie mod_passenger pracuje nie tylko z Ruby, ale także z Pythonem. Sprawdziłem także jak to jest faktycznie z obługą Rails i frameworków na Rack’u (tu sprawdziłem tylko Merba). Sprawdziłem też JRuby dla Rails i Merba.

Wszystkie testy były wykonywane na laptopie MacBook Pro Core 2 Duo, 2.16GHZ, 4GB RAM (OSX 10.5.3 dla tego modelu widzi tylko 3GB) i dyskiem 200GB kręcącym się z szybkością 7200 rpm. Ruby 1.8.6, Python 2.5.2, Apache 2.2.8 (mpm-prefork) były instalowane z MacPortów. Passenger, mimo że instalowany ze źródeł w Apache’u był wyświetlany jako “Phusion_Passenger/1.1.0” (być może więc to nie jest jeszcze ta nowa wersja 2.0 o której pisałem wcześniej) Nie sprawdzałem Linuksa, być może wyniki i wnioski będą wtedy inne.

Dla tych co chcieliby sami popróbować podaję wpierw konfigurację serwerów wirtualnych dla Apache’a potrafiącą unieść razem: PHP (2.5.6), Rails (2.1), Merb (0.9.4 edge), i Django (edge).

Konfiguracja Apache’a 2.2.8


# Ruby (Rails):
<VirtualHost *:80>     
  DocumentRoot "/opt/local/apache2/vhosts/rails_app/public"  
  ServerName rails_app
</VirtualHost>

# Ruby (Merb):        
<VirtualHost *:80>  
  RailsAutoDetect off  
  DocumentRoot "/opt/local/apache2/vhosts/merb_app/public"    
  ServerName merb_app       
</VirtualHost>

# Python (WSGI):
<VirtualHost *:80>          
  DocumentRoot "/opt/local/apache2/vhosts/wsgi_app/public"    
  ServerName wsgi_app
</VirtualHost>      

# Django (mod_python)
<VirtualHost *:80>         
  DocumentRoot "/opt/local/apache2/vhosts/djangus/public"    
  ServerName django_modpython 
  <Location "/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE djangus.settings
    PythonDebug On        
    PythonPath "['/opt/local/apache2/vhosts'] + sys.path"    
  </Location>       
</VirtualHost>   

# PHP:
<VirtualHost *:80>  
  RailsAutoDetect off  
  DocumentRoot "/opt/local/apache2/vhosts/php_app/public"        
  ServerName php_app   
</VirtualHost>

Wszystkie aplikacje korzystające z mod_passengera muszą posiadać folder public i tmp. Gdy do katalogu tmp dorzucimy jakikolwiek (może być pusty) plik o nazwie restart.txt, to przy następnym przeładowaniu przeglądarki nastąpi restart aplikacji.

We wszystkich przypadkach użyłem dosyć banalnego kodu polegającego na wyświetleniu “Hello World!”. Z wyników programu ab wyciąłem nieistotne informacje.

Rails (2.1)

Rails 2.1 + mod_passenger 1.1.0

Rails obsługiwane są w Passengerze praktycznie bezobsługowo. Wystarczy wkopiować pliki na serwer i to wszystko.

ab -n 1000 -c 1 http://rails/ 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Total transferred:      582000 bytes
HTML transferred:       12000 bytes
Requests per second:    430.20 [#/sec] (mean)
Transfer rate:          244.35 [Kbytes/sec] received

ab -n 1000 -c 4 http://rails/
...
Concurrency Level:      4
Failed requests:        239
   (Connect: 0, Length: 239, Exceptions: 0)
Write errors:           0
Total transferred:      488073 bytes
HTML transferred:       9132 bytes
Requests per second:    520.75 [#/sec] (mean)
Transfer rate:          247.88 [Kbytes/sec] received

Szybkość nie jest najgorsza, ale niepokojąca jest duża lista błędnych requestów w wypadku zapytań równoległych. Jak się dalej okazuje, ten problem dotyczy także obługi Rack jak i WSGI. Albo to jakaś specyfika OSX, albo wcale nie jest tak dobrze ze stabilnością mod_passengera dla równoległych zapytań. Trzeba by było też zbadać, czy ten efekt występuje także dla Linuksa. Zdziwiłbym się gdyby tam było podobnie skoro Dreamhost już oferuje hosting z mod_rails…

Dla porównania Rails używający Mongrela, Thin oraz Ebb. Można by pokusić aby odpalić Ebb i Thina na uniksowych socketach (Ebb też to już potrafi!), ale wtedy musiałbym zestawiać klaster i uruchamiać to przez proxy. Jak ktoś chce to niech się sam pobawi. Dla prostoty użyłem portów TCP. Sprawdziłem też JRuby.

Rails 2.1 + Ebb 0.2.0

ebb_rails -e production start

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    488.95 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
..
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    533.22 [#/sec] (mean)

Szybkość większa od mod_passengera i co ważniejsze, zero jakichkolwiek błędów przy pracy równoległej.

Rails 2.1 + Thin 0.8.1

thin start -e production              

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    485.95 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...              
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    506.21 [#/sec] (mean)

Szybkość trochę mniejsza od Ebb, ale stabilność b. dobra.

Rails 2.1 + Mongrel 1.1.5

script/server -e production

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    373.74 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    360.46 [#/sec] (mean)

Stabilność bez zarzutu, wydajność jednak mniejsza od serwerów pracujących asynchronicznie.

Rails 2.1 + JRuby 1.1.2

W wypadku JRuby trzeba go trochę “rozgrzać”. Pełna wydajność Javy pojawia się po jakimś czasie pracy. Wynika to ze specyfiki i możliwośći JVM która dokonuje dynamicznych optymalizacji kodu w trakcie jego działania (z tego powodu Java potrafi przewyższyć wydajnością C++). “Dla rozgrzewki” przepuściłem Rails przez 30 tys. requestów co spowodowało że początkowych 137 req/s zrobiło się 257 req/s.

jruby script/server -e production    

ab -n 1000 -c 1 http://127.0.0.1:3000/
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    200.48 [#/sec] (mean)

ab -n 1000 -c 4 http://127.0.0.1:3000/
...
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    257.05 [#/sec] (mean)

JRuby jest stabilny ale z wydajnością dla Rails jeszcze jest trochę do poprawienia. Dorzucenie opcji optymalizacyjnych, czyli odpalenie Rails przez

  
jruby -J-server -J-Djruby.compile.frameless=true script/server -e production

trochę poprawiło wynik: 273 req/s, ale generalnie nie jest to wielka różnica. JRuby 1.1.x już ma domyślnie powłączane optymalizacje.

Rails – wnioski

mod_passenger dla Rails faktycznie jest wydajny, choć trzeba jeszcze by zbadać dlaczego zwraca tyle błędnych requestów dla równoległych zapytań i czy ten problem występuje też na Linuksie. Dlatego na razie najwydajniejszym i najstabilniejszym rozwiązaniem dla Rails wciąż pozostaje kombinacja nginx + proxy do ebb lub thin. mod_passenger kusi głównie prostotą konfiguracji (właściwie brakiem konfiguracji). No i chyba ja to testowałem dla mod_passengera w wersji 1.1, a nie 2.0 (przynajmniej taka się wyświetla w Apache).

Merb 0.9.4 edge

Merb 0.9.4 edge + mod_passenger 1.1.0

Aby użyć frameworka Rack z Passengerem trzeba w katalogu projektu tworzyć plik config.ru zawierający konfigurację Rack’a. W wypadku Merba będzie to

require 'rubygems'
require 'merb-core'

Merb::Config.setup(:merb_root   => ".",
                   :environment => ENV['RACK_ENV'])
Merb.environment = Merb::Config[:environment]
Merb.root = Merb::Config[:merb_root]
Merb::BootLoader.run

run Merb::Rack::Application.new

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    762.62 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        247
   (Connect: 0, Length: 247, Exceptions: 0)
Write errors:           0
Requests per second:    985.15 [#/sec] (mean)

Merb jest wciąż dużo szybszy od Rails. Podobnie jak dla Rails, wiele równoległych zapytań nie zostało poprawnie wykonanych. Na produkcyjne użycie Passengera dla Merba jest jeszcze trochę za wcześnie.

Merb 0.9.4 edge + ebb 0.2.0

merb -e production -a ebb  
...                              
Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1463.69 [#/sec] (mean)

Concurrency Level:      10
Failed requests:        0
Write errors:           0
Requests per second:    1560.60 [#/sec] (mean)

Merb na Ebb deklasuje wydajnością wszystkie inne rozwiązania. Tylko czysty PHP jest w stanie mu dorównać, ale porównywanie PHP z całym, złożonym frameworkiem Rubiego jest trochę bez sensu. Z tego co mówił ostatnio (na kanale IRC) Ezra Zygmuntowicz, podpięcie Ebb na czystym Rack’u, daje nawet 7 tys req/s i deklasuje (rzekomo) szybkiego PHP. Gadanie o wyższej wydajności PHP jest po prostu głupie. Można się założyć, że jakiekolwiek porównanie frameworka naprzeciw frameworka, tj. Merba z Symfony czy Cake PHP, obnaży bezlitośnie słabości PHP tak, jak to zrobił Django w jednym ze starszych testów.

Merb 0.9.4 edge + thin 0.8.1

merb -e production -a thin 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    1147.78 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1234.82 [#/sec] (mean)

Wydajność równie dobra, choć trochę słabsza od Ebb. Sporo więcej od Rails i zero problemów ze stabilnością.

Merb 0.9.4 edge + mongrel 1.1.5

merb -e production -a mongrel
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    868.10 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    837.01 [#/sec] (mean)

Mongrel jest wolniejszy od serwerów asynchronicznych ale i tak wyraźnie szybszy od Rails.

Merb 0.9.4 edge + JRuby 1.1.2

 
jruby -S merb -e production 
...
Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    449.52 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    505.52 [#/sec] (mean)

Merb na “rozgrzanym” (30 tys. req) JRuby osiąga wydajność taką jak najszybsze rozwiązania dla Rails z użyciem asynchronicznego Ebb! To znaczy, że użycie produkcyjne Merba w systemach Javy ma jak najbardziej sens.

Passenger & WSGI

Pora na przyjrzenie się temu jak mod_passenger daje sobie radę z Pythonem. W katalogu ze źródłami Passengera leży gotowa, prosta aplikacja WSGI. Dzieki dobrej dokumentacji Django, udało mi się uruchomić ten framework pod Passengerem. Gorzej było z Pylons. Nie udało mi się stworzyć poprawnego pliku passenger_wsgi.py, niezbędnego do tego aby Passenger uruchomił aplikację WSGI.

Django edge

Django, mimo swych zalet, stosuje bardzo głupią politykę nie wypuszczania kolejnych wersji kodu. Dostępna na stronie wersa 0.96 jest stara i generalnie zaleca się aby używać nowszą wersję, która istnieje tylko w repozytorium Subversion. Oparcie kodu produkcyjnego o wersję edge jest trochę ryzykowne i szybko sprowadza się do złej praktyki ciągłego łatania kodu.

W wypadku Django plik passenger_wsgi.py zawiera kod:

import os, sys
sys.path.append('/bezwl/sciezka/do/nazwaprojektu') 
os.environ['DJANGO_SETTINGS_MODULE'] = 'nazwaprojektu.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

  ab -n 10000 -c 10            
  ...   
  apr_poll: The timeout specified has expired (70007)

Test padł po 9tys requestach. Dalej nie można było uruchomić Django. Dopiero restart calego Apache’a pomógł. Dla niższej ilości równoległych zapytań (ab -n 1000 -c 4) Django nie padło, ale było dużo błędnych requestów. Okazało się, że problem wynikał z równoczesnej obecności modułu mod_python i mod_passenger. Nie można ich razem włączać.

Usunięcie mod_passengera i zostawienie samego mod_pythona pomogło. (Albo jest jakiś konflikt między nimi, albo (co bardziej jest prawdopodobne) trzeba poczekać na opcję wyłączającą passengera dla serwera wirtualnego używającego mod_pythona. Dla Rails i Rack są takie opcje (RailsAutoDetect, RackAutoDetect), dla WSGI nie mogłem nic takiego znaleźć w kodzie źródłowym. Modułu mod_wsgi nie sprawdzałem, bo nie było go dostępnego w portach OSX.)

Po zablokowaniu mod_passenger’a tym razem mod_python nie zwracał żadnego błędnego requestu.

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    934.87 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        0
Write errors:           0
Requests per second:    1240.26 [#/sec] (mean)

Nie jest źle. Django jest tu wyraźnie szybsze od Rails (co nikogo nie dziwi), ale jest wolniejsze od Merba, co dla miłośników Pythona może być przykrą niespodzianką. Większość krytyki Rubiego oparta jest na krytyce (słabszej) wydajności Railsów. Okazuje się, że winny nie jest Ruby, ale słabo zoptymalizowany Rails. Merb jest dowodem na to, że można napisać w Rubim framework, który nie tylko będzie partnerem dla rozwiązan Pythona, ale nawet potrafi je przewyższać wydajnościowo.

Zobaczmy jak wypadnie mod_passenger.

Concurrency Level:      1
Failed requests:        0
Write errors:           0
Requests per second:    904.60 [#/sec] (mean)

Concurrency Level:      4
Failed requests:        240
   (Connect: 0, Length: 240, Exceptions: 0)
Write errors:           0
Requests per second:    497.51 [#/sec] (mean)

W pracy jednoprocesowej nie można mieć zastrzeżeń. Szybkość jest niezła. Niestety praca równoległa to porażka. Dużo requestów nie zostało obsłużonych. Gorzej, za drugim razem (tylko dla 4 rownoległych zapytań) Django kompletnie się załamało i zwróciło wyjątek “apr_poll: The timeout specified has expired (70007)”. Nie można było go dłużej używać. Wymagany był restart Apache’a.

Aby sprawdzić czy to tylko problem Django czy ogólnie implementacji WSGI dla mod_passengera, uruchomiłem test na prostej aplikacji WSGI. Niestety sytuacja jest ta sama.

Wniosek: mod_passenger dla Pythona wymaga dopracowania pracy równoległej. Jeszcze za wcześnie aby go używać z Pythonem. Ale z drugiej strony uruchomiłem mod_passengera z WSGI trochę przedwcześnie. Nie ma przecież w manualu ani jednego zdania o tym, że Passenger działa z WSGI. Oparłem się tylko na pogłoskach i wygrzebałem tą opcję ze źródeł. Więc jeszcze wszystko może się tu zmienić. To samo dotyczy Rack’a. Twórcy muszą przyjrzeć się problemom związanym z obsługą równoległych zapytań.

Update

Jednak dobrze się domyślałem, Apache nie oszukiwał. W tekście testowałem starszego Passengera 1.1. Także nie był to Ruby Enterprise. NOWY Passenger 2.0RC1 oraz Ruby Enterprise został dopiero niedawno opublikowany. Co ciekawe, dodano obsługę Apache MPM Worker a nie MPM Prefork, co dodatkowo zmniejsza zużycie pamięci. Niestety Passenger 2.0RC1 jest na razie dostępny tylko w wersji na Linuksa.

PostgreSQL vs MySQL vs MSSQL2K

Jarosław Zabiełło — Mon, 02 Apr 2007 17:14:00 +0200

Zawsze dziwiłem się dlaczego aplikacje komunikujące się z MSSQL chodzą tak niemrawo. Zrobiłem sobie szybki test szybkości. Na tym samym komputerze zainstalowałem: MSSQL 2000 SP4, MySQL 5.0.27 i PostgreSQL 8.2.3. Zadanie było proste, pobrać listę tabel w bazie.

Użyto następującego kodu w Pythonie:

import adodbapi, MySQLdb, odbc, psycopg2, time
conn = [
  ( 'mysql', MySQLdb.connect(user='root', db='test'), 'SHOW TABLES'),
  ('pgsql', psycopg2.connect("user='postgres' password='test''"), 'SELECT * FROM pg_tables jdb273'),
  ('mssql ado', adodbapi.connect('Provider=SQLNCLI.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=test'), 'EXEC sp_tables'),
  ('mssql odbc', odbc.odbc('DRIVER={SQL Server};SERVER=localhost;DATABASE=test;UID=sa;PWD=test'), 'EXEC sp_tables'),
  ]
def test(repeat=100):
  for c in conn:
    dbtype, db, sql = c
    print dbtype,
    t = time.time()
    for i in range(repeat):
      cursor = db.cursor()
      cursor.execute(sql)
      rows = cursor.fetchall()
      cursor.close()
    print '%d req/s' % round(repeat / (time.time() - t))
if __name__ == '__main__':
  test()

Użyta konfiguracja:

WinXP Pro 2000 SP2, P4 3.2GHz, 1GB RAM.
Python 2.5
MySQL v5.0. 27, driver: MySQLdb v1.2.2
PostgreSQL v8.2.3, driver: psycopg2 v2.0.6b1 (dec dt ext pq3)
MSSQL 2000 SP4, driver: ADO

Wyniki:

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 6 req/s
mssql odbc 9 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 9 req/s
mssql odbc 10 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 578 req/s
mssql ado 9 req/s
mssql odbc 11 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 457 req/s
pgsql 581 req/s
mssql ado 8 req/s
mssql odbc 11 req/s

C:\home\app\bench\scripts>bench_db.py
mysql 455 req/s
pgsql 641 req/s
mssql ado 9 req/s
mssql odbc 10 req/s

Mit o rzekomej szybkości MySQL już jest nieaktualny. Nowy PostgreSQL 8 bije go pod każdym względem. Zarówno wydajnościowo i jak i znacznie większymi mozliwościami (o tym może kiedy indziej). Dziwi słaba, a raczej nędzna, wydajność produktu firmy Microsoft. Nie sprawdzałem nowego MSSQL 2005, ale wszystko wskazuje na to, że przynajmniej MSSQL2K to kompletne dno!

Python vs. Ruby 1.9 YARV. Cz. II

Jarosław Zabiełło — Sat, 06 Jan 2007 18:44:00 +0100

Z wcześniejszych testów wynikało że Ruby 1.9 (wykorzystujący wirtualną maszynę YARV) jest szybszy od Pythona. Aby zwolennicy Rubiego zbyt się nie cieszyli, przygotowałem test na wywołania rekurencyjne. Najcięższą jest tu funkcja rekurencyjna. Długość 7 znaków daje prawie 900 tys. wywołań rekurencyjnych i w miarę sensowne czasy aby coś zobaczyć. Postanowiłem ją wziąć na rozkład. Tym razem z 10 prób brany jest najlepszy (najkrótszy) wynik.

Python:

try:
  import psyco
  psyco.all()
except:
  pass

from time import time
def wariancje(s, n):
    if n==0:
      yield []
    else:
        for i in xrange(len(s)):
            for c in wariancje(s, n-1):
                yield [s[i]] + c
s = "abcdefg"
nelem = len(s)
i = 0
results = []
for unused in range(10):
  t = time()
  for s in wariancje(s, nelem):
    i += 1
  tmp = time() - t
  results.append(tmp)
  print tmp
print min(results), max(results), nelem, i

Ruby

def wariancje(s, n)
  if n == 0
    yield []
  else
    s.size.times do |i|
      wariancje(s, n-1) { |c| yield [s[i]] + c }
    end
  end
end
t = Time.now
s = "abcdefg"
size = s.size
i = 0
results = []
10.times do
  t = Time.now
  wariancje(s, size) do
    i += 1
  end
  tmp = Time.now - t
  results << tmp
  puts tmp
end
puts "\n#{results.min}, #{results.max}, #{size}, #{i}"

Rezultat:

Python 2.5: 3.86356806755 s.
Python 2.4 4.09678792953 s.
Ruby 1.9: 6.418052 s.
Ruby 1.8.5: 8.000223 s.

Tym razem Python nie dał szans Rubiemu. Jest od niego wyraźnie szybszy. Jednak na obronę można powiedzieć że YARV nie jest tu jeszcze zbyt zoptymalizowany. Wiele opcji optymalizacyjnych ma po prostu wyłączonych, Ruby 1.9 i YARV to na razie kod eksperymentalny. Na razie więc dominacja wydajnościowa Pythona jest niepodważalna.

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!