Begin forwarded message:
From: "Markus Czehak" <[EMAIL PROTECTED]> Date: 20. März 2007 17:06:55 GMT+01:00 To: [EMAIL PROTECTED] Subject: Re: Squeak-ev Nachrichtensammlung, Band 49, Eintrag 20 ------------------------------ Message: 4 Date: Tue, 20 Mar 2007 12:20:25 +0100 From: stepken <[EMAIL PROTECTED]> Subject: [Squeak-ev] Kommerzielle Applikationen mit Squeak? Vgl. JBOSS vs. Seaside vs. Ruby vs. Python vs. Apache + Module ... To: Squeak in Germany / Squeak in Deutschland <[email protected]> Message-ID: <[EMAIL PROTECTED] > Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 zumFenster hinausgeschmissen wird, weil oftmals die Kosten von Entwicklungund Wartung sowie Hardware aus oft unerfindlichen Gründen explodieren,sogar Applikationen neu entwickelt werden auf anderen Plattformen. Hierein 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 zubedenken, Debugging, Softwarewartung (Refactoring) und die oft horrendenKosten, 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 vonSqueak gegen VisualWorks gegen Jigsaw Java gegen Python, Ruby und Apachegetestet. 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 vieleNetzwerkverbindungen 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 seit2.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, weilz.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ßtkastriert. Wer z.B. FreeBSD oder insbesondere NetBSD einsetzte war hierin völlig unbegrenzt. Diese BSD - Typen sind in jeder Hinsichtunbegrenzt, ohne Tuning. Ist das BS von diesen Verklemmungen befreit, so kommen architekturbedingte Verklemmungen auf Applikationsseite hinzu. Somüssen z.B. einige Applikationen, um mehrere gleichzeitige Anfragenbedienen 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, wozwar 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 eingehendeNetzwerkverbindung eine neue Queue anlegt, und diese dann versucht, dieDatenströ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 zigtausendtausendesimultane Datenströme fließend bedienen, wo die Daten kontinuierlich injede 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 hierbeirecht 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 vieleMegabyte jeweils groß. FASTCGI bedeutet eine Art asynchrone Abarbeitungder 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 gleichzeitigenVerbindungen 100 Kopien des Servers im RAM erzeugt. PostgreSQL z.B. verfolgt ein anderes Konzept - 1 Server und je Netzwerkverbindung wirdeine Kopie eines PostgreSQL Clients erzeugt. Das ist viel sparsamer, alseine 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), 2CPU's, mehrere Netzwerkkarten, 2 auf unterschiedlichen CPU's gestarteteServer-Threads mit Single-Threaded Technik, unlimited File - und network-handels, und dann muß natürlich der Server auch Async I/O undAsync File I/O auch nutzen können. Wie nun handelt diese Single- Threaded - Technik 100.000 simultante Anfragen, wo Datenbank-Inhalte ausgeliefertwerden 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" dereingehenden Verbindungen? - "Green Threads" für jede Netzwerkverbindung wird ein sog. "green thread" aufgemacht, also innerhalb des Interpreterseine Art Multi-Tasking ausgefürt. Der Interpreter verwaltet alsoeigenstä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, 8Netzwerkkarten ! Dieselbe Technik in IRONGATE - einem Mailserver, welcheebenfalls 100.000 Mail-Datenströme gleichzeitig ausliefern kann. Diese werden für Spamming vorwiegend eingesetzt, weil die 300.000 Mails jeStunde 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 nichtunter 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 keinesVisualWorks Smalltalk oder Multi-Threaded - Technik, um auf Performance zu kommen, sondern nur der Beachtung dieser Kleinigkeit. David Shaffnerhat 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 Vieleder 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 einemInterpreter - klein, flink, sparsam im RAM, und - diese Kombination erst macht das System wahnsinnig schnell, gegenüber den Multi-CPU Servern mitMulti-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) mitSqueak eine 100 MBit - Karte sättigen! Wie?http://www-sor.inria.fr/~piumarta/squeak/unix/j3/Squeak-2.8/src/ macos/sqMacNetwork.cEs ist wirklich kein Problem, einen Green - Thread http - Server in Squeak zu programmieren. Wie das geht, zeigen auch RUBY und Python, daliegen die im Quellcode herum. Nun - Smalltalk hat eine noch einfachereSyntax, 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 invertiertenProxy, z.B. SQUID hinzu. Dynamische Seiten, welche schon mal soausgeliefert wurden, werden gecacht, die Anfragen gelangen erst garnichtmehr 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). Undwer 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 mansich dann z.B. den CICSO LOCAL DIRECTOR ersparen. Damit fallen dann auchdie evtl. Unterbrechungen der Smalltalk VM bei der FULL GarbageCollection 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/Onatürlich) Interpreter dahinter. Die Performance ist mit der von Squeakund 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 PS3mit Linux und Squeak drauf.... ;-) http://www.gamezone.de/news_detail.asp?nid=47638Kleine Internas der Squeak VM, für die, die Spaß daran haben, Workspaceauf: 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 isthat object in, or is it a root? Mehr, siehe Google....Daß die Entwicklungszeigen bei Smalltalk nur 1/3 bis 1/6 derjenigen vonC++ 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 ------------------------------ Message: 5 Date: Tue, 20 Mar 2007 12:39:58 +0100 From: Bert Freudenberg <[EMAIL PROTECTED]> Subject: Re: [Squeak-ev] Kommerzielle Applikationen mit Squeak? Vgl.JBOSS vs. Seaside vs. Ruby vs. Python vs. Apache + Module ...To: Squeak in Germany / Squeak in Deutschland <[email protected]> Message-ID: < [EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On Mar 20, 2007, at 12:20 , stepken wrote: > Hallo, Squeaker! Hallo Guido. Dir ist schon klar, dass du hier dem Chor predigst? Ich für meinen Teil find das gut und erfrischend, aber die Leute hier auf der Liste musst du eigentlich nicht mehr von den Vorteilen von Squeak überzeugen ... Mit deinem Enthusiasmus würdest du aber einen hervorragenden Pressesprecher des Vereins abgeben. Lust?Das ist ja sogesehen nicht ganz richtig. Ich für meinen Teil interessiere mich für Squeak/Smalltalk, bin da aber noch ein unbeschriebenes Blatt.Ich arbeite an einem kfm. Berufskolleg in NRW. U.a. programmieren auch einige unserer Schüler, ich arbeite grad daran, dass die Zahl steigen kann. Und mit denen möchte ich dann gerne mit Squeak arbeiten. Gute Argumente, die für Squeak/Smalltalk sprechen anstelle von Java, PHP, C++ oder C# und wie sie alle heißen kann ich da gut gebrauchen.Neulich hatte ich ein Gespräch mit der Bezirksregierung. Hab mich mal erkundigt, wie denn die Chancen stehen, in der Schule mit Smalltalk/Squeak zu programmieren (auch im Hinblick auf die zukünftige Abi-Zentralprüfungen in NRW). Wenn ich das gut begründen kann, wäre es in Ordnung, hieß es. Gut begründen muss man es gegenüber den Schülern (die nur Java, PHP, C#, ... kennen) und gegenüber der Bezirksregierung. Halt ein eingefahrener Verein. Ganz zu schweigen vom Großteil der Lehrer, die sich da stur stellen (und den Schülern so gerne mit VBA was beibringen (natürlich keine OO) oder PHP ganz toll finden, weil man da sofort Ergebnisse sieht). An vielen anderen Schulen ist es Java. Java ist nun mal "in". Das Zentralabi wirkt sich auch auf die Auswahl der Sprachen aus, hier soll die Vergeichbarkeit gewährleistet werden. Und da sind mehr als eine oder zwei (populäre) Sprachen nicht drin. Ähnliche Erfahrungen mache ich grad beim Einsatz von OpenSource (OpenOffice). Aber da bleib ich stur. ;-)Da ich selber in Squeak noch ein unbeschriebenes Blatt bin, bin ich dankbar für jede Unterstützung (ein Pamphlet wurde hier mal angesprochen ;-) - an meiner Schule hat man einen guten Spielraum (freie Hand wäre übertrieben), unser Schulleiter ist da recht aufgeschlossen, wenn man gute Ideen hat und argumentativ auf sicherem Boden ist).-- Herzliche Grüße, Markus Czehak
smime.p7s
Description: S/MIME cryptographic signature
