[Squeak-ev] Kommerzielle Applikationen mit Squeak? Vgl. JBOSS vs. Seaside vs. Ruby vs. Python vs. Apache + Module ...

stepken stepken at web.de
Die Mar 20 11:20:25 UTC 2007


Hallo, Squeaker!

Sehr nachdenklich hat mich gemacht, daß immer mehr Firmen auf die sog. 
"bewährten" Sprachen und Frameworks (J2EE, JBOSS, RUBY ON RAILS, APACHE 
+ PHP, PERL, PYTHON, ... für die Applikationsentwicklung setzen, 
vornehmlich Web-basierte Applikationen, allen voran der Apache Server 
mit seinen flexiblen Modulkonzept. Interessant ist, wieviel Geld zum 
Fenster hinausgeschmissen wird, weil oftmals die Kosten von Entwicklung 
und Wartung sowie Hardware aus oft unerfindlichen Gründen explodieren, 
sogar Applikationen neu entwickelt werden auf anderen Plattformen. Hier 
ein paar Anmerkungen zu den Hintergründen:

Außer Frage steht, daß die Entwicklungskosten umso niedriger sind, je 
mächtiger das Framework ist, und ob es für die Aufgabenstellung 
entwickelt wurde. Und dann gibt es noch erhebliche Folgekosten zu 
bedenken, Debugging, Softwarewartung (Refactoring) und die oft horrenden 
Kosten, wenn die Performance nicht ausreicht, Cluster für "load 
balancing" nachgerüstet werden müssen, und katastrophal ist es, wenn 
eine Applikation dauernd abstürzt. Entscheider verlassen sich nur auf 
"bewährtes", den Mainstream. Und kollektive Irrtümer hat es zuhauf gegeben.

Zuerst zur Performance:

Sind reine Interpreter, z.B. Smalltalk, Ruby, Python gegenüber JIT - 
Applikationen

David Shaffner hat sich 2005 die Mühe gemacht, die Performance von 
Squeak gegen VisualWorks gegen Jigsaw Java gegen Python, Ruby und Apache 
getestet.
http://wiki.squeak.org/squeak/539 Er ist hier zu finden: 
http://www.cs.westminster.edu/~shaffer/Smalltalk/

Was er dort anspricht und misst, muß man erst einmal in Deutsch 
übersetzen. Async I/O und Async File I/O sind zunächst einmal 
Eigenschaft des Betriebssystems, die Fähigkeit, simultane Datenströme 
von/auf Festplatte und von/richtung Netzwerk handeln zu können. Was 
nutzt es, wenn z.B. der Webserver theoretisch 1000 simultane Anfragen 
beantworten könnte, jedoch das Betriebsystem immer nur 1 File 
gleichzeitig liefern kann, gilt auch für RAW DEVICES bei Datenbanken. 
Resultat - die Datenströme brechen ab, die Latenzzeiten erhöhen sich. 
Dann kommt Async I/O über die Netzwerkkarte hinzu. Hierdurch erst wird 
das Betriebssystem richtig performant, weil es gleichzeitige viele 
Netzwerkverbindungen nicht nur gleichzeitig offenhalten (siehe netstat), 
sondern auch mit Datenströmen bedienen kann. Man spricht hier von 
blocking, non blocking und async I/O. Die Betriebssysteme in der 
Vergangenheit, die das locker beherrschten, waren z.B. HP - UX, AIX, 
Solaris, Digital UNIX / True64 /  VMS, Free/NetBSD ... Linux erst seit 
2.6.9+ . Die Zahl der Network - und Filehandels, die das BS gleichzeitig 
verwalten kann, stellt ebenfalls eine Grenze dar. Könnte die Applikation 
1000 veschiedene Files ausliefern, so wird sie oft daran gehindert, weil 
z.B. nur 256 gleichzeitige Files bzw. 256 Netzwerkverbindungen offen 
gehalten werden können. TCP/IP Verbindungen brechen oft dann ab. So 
unterscheiden sich z.B. die verschiedenen Versionen von Windows NT 
Server und Vista stark von den Windows Vista Home / Professional 
/Ultimate Editionen. Die Zahl der Network - und Filehandels wurde bewußt 
kastriert. Wer z.B. FreeBSD oder insbesondere NetBSD einsetzte war 
hierin völlig unbegrenzt. Diese BSD - Typen sind in jeder Hinsicht 
unbegrenzt, ohne Tuning. Ist das BS von diesen Verklemmungen befreit, so 
kommen architekturbedingte Verklemmungen auf Applikationsseite hinzu. So 
müssen z.B. einige Applikationen, um mehrere gleichzeitige Anfragen 
bedienen zu können, "forken", also Kopien von sich im RAM starten, damit 
eine zweite eingehende Netzwerkverbindung bedient werden kann, das CGI - 
Konzept. Fortschrittlicher sind hier dann sog. Multi-Threaded Server, wo 
zwar auch Kopien im RAM erzeugt werden, jedoch aufgrund des geteilten 
Datenbereiches weniger RAM verbraucht. Diese Server "skalieren" über 
mehrere CPU's. Noch fortschrittlicher sind hingegen wieder 
Single-Threaded Server - wo ein Server für jede eingehende 
Netzwerkverbindung eine neue Queue anlegt, und diese dann versucht, die 
Datenströme der Reihe nach 'round robin' zu bedienen. Komischerweise 
sind dies die absolut schnellsten Server (Zeus) Unter FreeBSD  und 
NetBSD genügt hierbei nur eine einzige CPU, um 4 x 100 MBit mit 
Datenströmen "sättigen" zu können. Skalieren tut das System damit 
offiziell also nicht, es ist aber sauschnell und - sofern es ASYNC I/O 
und ASYNC FILE I/O beherrscht, kann es sogar zigtausendtausende 
simultane Datenströme fließend bedienen, wo die Daten kontinuierlich in 
jede Richtung fließen, zwar langsamer, aber gleichmäßig, nicht abrupt 
wechselnd.
Und nun kommt das Problem mit den Threads. Für jeden Kernel - Thread 
(siehe auch das Konzept der PTHREADS) wird mindestens 1 MByte RAM 
fällig. Bei tausend simultanen Netzwerkverbindungen wird also z.B. ein 
Programm, welches Datenbankverbindung herstellt, aufbereitet und diese 
dann ausliefert, tausendfach kopiert, macht 1 Gigabyte RAM Verbrauch, 
nur allein, um die Netzwerkverbindungen offenhalten zu können. Da 
braucht man dann plötzlich Multi-CPU Serversysteme mit LOAD Balancing, 
die Folgekosten explodieren. Denial of Service Angriffe werden hierbei 
recht einfach. Daher haben die Hersteller von BS die Zahl der Netzwerk - 
Handels begrenzt, auch eine Art Schutz vor Überlastung.
Apache 2.x besitzt daher eine Mischung aus Single-Threaded Server, wo 
jede Serverinstanz mehrere 1000 "einfache" HTML - Seiten ausliefern 
kann, und einem "pre-forking"  Server, wo für jedes Skript, welches 
aufgeführt wird, je eine Kopie des Apache-Servers und der zugehörige 
PHP/Python/PERL Interpreter gestartet werden muß, auch wieder viele 
Megabyte jeweils groß. FASTCGI bedeutet eine Art asynchrone Abarbeitung 
der Skripte in einem Interpreter. Sie werden der Reihe nach FIFO 
abgearbeitet, es existiert aber nur 1 Instanz des Interpreters im RAM, 
ebenfalls sehr Speicheraufwändig. Nun kommt noch ein Nadelöhr. 
Datenbank. So werden z.B. bei einigen Datenbanken bei 100 gleichzeitigen 
Verbindungen 100 Kopien des Servers im RAM erzeugt. PostgreSQL z.B. 
verfolgt ein anderes Konzept - 1 Server und je Netzwerkverbindung wird 
eine Kopie eines PostgreSQL Clients erzeugt. Das ist viel sparsamer, als 
eine Kopie des kompletten SQL Servers im RAM zu halten.
Und nun die pfiffigste und billigste Kombination. Betriebssystem mit 
ASYNC I/O, ASYNC FILE I/O (auch für RAW DEVICES bei DATENBANKEN), 2 
CPU's, mehrere Netzwerkkarten, 2 auf unterschiedlichen CPU's gestartete 
Server-Threads mit Single-Threaded Technik, unlimited File - und 
network-handels, und dann muß natürlich der Server auch Async I/O und 
Async File I/O auch nutzen können. Wie nun handelt diese Single-Threaded 
- Technik 100.000 simultante Anfragen, wo Datenbank-Inhalte ausgeliefert 
werden müssen? Nun - alles muß in Single-Threaded - Technik mit Async 
I/O und Async File I/O durchgängig implementiert worden sein. Wie 
unterscheidet nun der Server die verschiedenen "Zustände" der 
eingehenden Verbindungen? - "Green Threads" für jede Netzwerkverbindung 
wird ein sog. "green thread" aufgemacht, also innerhalb des Interpreters 
eine Art Multi-Tasking ausgefürt. Der Interpreter verwaltet also 
eigenständig die vielen Tasks, legt selber Stapel (queues) an, arbeitet 
diese in schnellem Wechsel, also scheinbar fließend, ab. Vorteil dieser 
"green threads" ist, daß für jeden Thread nur ca. 700-900 Byte !!!! 
(nicht Megabyte) RAM verbraucht werden. Nanu?

Das Online-Game "EVE" ist das Paradebeispiel für diese Technik. 1 
Stackless PYTHON - Interpreter (arbeitet mit Continuations, einer Art 
"goto" mit entsprechenden Nachteilen...dafür aber schnell!) verwaltet 
selber die Threads für TCP/IP, Server und Datenbank, und zwar in einer 
affenartigen Geschwindigkeit, obwohl oder gerade weil Interpreter: 
30.000-100.000 simultane Datenströme aus der Datenbank, kontinuierlich 
in alle Richtungen fließend, verbinden Spieler mit einer gemeinsamen, 
virtuellen Welt. Servertechnik: FreeBSD 1 CPU, 4 GByte RAM, 8 
Netzwerkkarten ! Dieselbe Technik in IRONGATE - einem Mailserver, welche 
ebenfalls 100.000 Mail-Datenströme gleichzeitig ausliefern kann. Diese 
werden für Spamming vorwiegend eingesetzt, weil die 300.000 Mails je 
Stunde rausschieben können, wobei sie auch GBit Netzwerkkarten sättigen.

Welche Technik unterstützt SQUEAK nun? Nun - Squeak ist "nur" 
Single-Threaded und nutzt auf bestimmten Betriebssystemen tatsächlich 
ASYNC I/O. Unter HP-UX, FreeBSD/NetBSD, OS X, Linux 2.6.9+, nur nicht 
unter Windows. Squeak auf Linux mit aktiviertem Async I/O haut die Daten 
aus der Netzwerkarte raus, das es eine Freude ist, zuzusehen. Der Apache 
- Benchmark "ab" von Zeus Technologies beweist es. Es bedarf keines 
VisualWorks Smalltalk oder Multi-Threaded - Technik, um auf Performance 
zu kommen, sondern nur der Beachtung dieser Kleinigkeit. David Shaffner 
hat Code Snippets in seinem Beispiel beigefügt, die dann Squeak 
befähigen, die Async I/O+File Eigenschaften des darunterliegenden BS 
auch nutzen zu können. Die hunderttausenden TCP/IP Verbindungen mit 
Green Thread - Technik kann man dann einfach nutzen ... net := 
HTTPSocket httpGET: 'http.....'. fork net. Und das in einem kleinen 
Schleifchen verpackt, macht ab auch alle Ehre ... 
http://www.oldenbuettel.de/squeak-doku/Network-Kernel/Socket.html Viele 
der Routinen sind für ASYNC ausgelegt.
Bevor man sich mit der Performance bestehender HTML - Server in Squeak 
herumschlägt, hat man schnell selber einen Webserver mit Green Threads 
und Semaphoren selber geschrieben, und nutzt dann die OO-Datenbank in 
Squeak selber oder auf der CPU, z.B. MAGMA. Damit laufen dann sowohl 
Webserver, als auch Datenbankserver und Datenbankapplikation in einem 
Interpreter - klein, flink, sparsam im RAM, und - diese Kombination erst 
macht das System wahnsinnig schnell, gegenüber den Multi-CPU Servern mit 
Multi-Threading Applikationen, die tierisch CPU - Zeit allein für die 
Synchronisation der Tasks und die Zeitscheibenverteilung auf der CPU, 
Semaphoren, Network-Events ... aufwenden müssen.

Mit einem 500 Mhz Powerbook konnte man auch damals schon (Jahr 2000) mit 
Squeak eine 100 MBit - Karte sättigen! Wie?
http://www-sor.inria.fr/~piumarta/squeak/unix/j3/Squeak-2.8/src/macos/sqMacNetwork.c

Es ist wirklich kein Problem, einen Green - Thread http - Server in 
Squeak zu programmieren. Wie das geht, zeigen auch RUBY und Python, da 
liegen die im Quellcode herum. Nun - Smalltalk hat eine noch einfachere 
Syntax, man kann aber flüssig beim Lesen von Python Code Smalltalk 
programmieren .... ;-)

Und wer dann will baut eine 2. CPU ein, startet eine 2. Squeak Engine 
auf der 2. CPU worin z.B. der Datenbankserver läuft, oder stellt einen 
Server daneben.

Und wer dann noch mehr Performance braucht, schaltet einen invertierten 
Proxy, z.B. SQUID hinzu. Dynamische Seiten, welche schon mal so 
ausgeliefert wurden, werden gecacht, die Anfragen gelangen erst garnicht 
mehr zum Interpreter. So kann man die Performance durchaus, trotz 
dynamischer Inhalte auf 10.000 ausgelieferte kleine HTML - 
Seiten/Sekunde erhöhen (selber getestet und oftmals implementiert). Und 
wer dann noch mehr Performance braucht, schaltet einfach einen LINUX 
LOAD - Balancer davor, diese Technik kann Linux von Hause aus: 
http://www.little-idiot.de/linuxsolutionguide/lvs.htm Damit kann man 
sich dann z.B. den CICSO LOCAL DIRECTOR ersparen. Damit fallen dann auch 
die evtl. Unterbrechungen der Smalltalk VM bei der FULL Garbage 
Collection nicht mehr auf, oder die (winzigkleinen) Unterbrechungen bei 
dem Recompilieren, wenn man Updates einspielt.... (und nicht vergessen, 
Background CPU Power zu aktivieren ... in der Squeak VM)
Tatsache ist auch, daß z.B. Microsoft in seinem IIS und auch in JBOSS, 
J2EE heimliche "Caches" enthalten sind, genaugenommen dieselbe Technik, 
wie beim invertierten SQUID Proxy (iX hat darüber berichtet). Zaubern 
können die alle nicht, wollen aber bei Benchmarks immer glänzen. Und 
eine alte Weisheit besagt -

                                                "Ein Entscheider kauft 
immer nur die Präsentation!"

Zu IronPython:
http://www.google.de/search?hl=de&client=firefox-a&rls=org.mozilla%3Ade%3Aofficial&hs=vcZ&q=ironpython+eve+game&btnG=Suche&meta=

Übrigens - XING ist eine voll dynamische Homepage, mit RUBY (ASYNC I/O 
natürlich) Interpreter dahinter. Die Performance ist mit der von Squeak 
und der Smalltalk VM durchaus zu vergleichen. Auf JIT - Compiler und 
"Multi-Threaded" Implementierungen bei Squeak zu warten, ist nicht 
nötig, die Performance würde sich eh nur Faktor 2 (JIT) erhöhen, 
maximal. Ich freue mich schon auf die neuen IBM CELL PROZESSOREN auf PS3 
mit Linux und Squeak drauf.... ;-)
http://www.gamezone.de/news_detail.asp?nid=47638

Kleine Internas der Squeak VM, für die, die Spaß daran haben, Workspace 
auf:

Smalltalk garbageCollect. <ALT>-P -> Full GC, returns bytes free.
Smalltalk garbageCollectMost. -> Incremental GC
Smalltalk getVMParameters.  -> Raw GC numbers.
Smalltalk extraVMMemory. -> Get/Set extra Heap Memory (veraltet)
Smalltalk bytesLeftString. -> Get bytes free + expansions
Smalltalk setGCSemaphore. -> Semi to signal on IGC
Smalltalk setGCBiasToGrow. -> setGCBiasToGrowGCLimit:
Smalltalk isRoot: /isYoung:/rootTable/rootTableAt: Which memory space is 
that object in, or is it a root?

Mehr, siehe Google....

Daß die Entwicklungszeigen bei Smalltalk nur 1/3 bis 1/6 derjenigen von 
C++ und 1/2-1/3 derjenigen mit JAVA (oder C# bzw. .NET) und etwa 
gleichauf mit Ruby on Rails bzw. Apple WebObjects (schon seit NextStep 
ungeschlagen) liegt, dürfte zu denken geben. Softwarewartung ist 
ungleich billiger mit Smalltalk.

Tja, was sagen die Marketing - Leute dazu: "Esst Scheiße, millionen 
Fliegen können nicht irren!" Meine Liste jedenfalls der gescheiterten 
J2EE / JBOSS Großprojekte wird täglich länger, nicht nur seit dem 
gescheiterten Projekt FISCUS der Bundesregierung, nein auch viele 
weitere bei großen Unternehmen. Smalltalk - Projekte komischerweise 
werden viel öfter Erfolge, ob es an dem Verstand der Entwickler und 
Entscheider liegt, die sich nicht von dem Marketing Hype beeindrucken 
lassen? Kollektive Wahrnehmungsstörungen?

Viele Grüße, Guido Stepken