ITflow.de

In der IT gibt es immer wieder Trends, welche durch ein markantes Buzz-Word representiert werden. Nach dem langsamen Untergang von SOA (Serviceorientierte Archtektur), wird nun das Cloud Computing als die Lösung aller Probleme propagiert.  Dabei ist das zusammenfügen von mehreren Hosts zu einem Cluster nichts neues. Mit Cloud Computing kommt nun die in Zeit & Volumen berechnete Rechenkapazität für jederman. Man hat also dem Cluster eine effektivere Load Balancing Technik und ein Traffic/CPU Monitoring hinzugefügt, welches nun als Abrechnungsbasis herhält. Da sich aber der Begriff Cluster, wohl nichtmehr verkaufen ließ, heißt das jetzt Cloud.

Da ich bisher immer XP auf dem NC 10 hatte und das teilweise doch etwas zäh wirkte, hab ich nun einmal Ubuntu installiert.

Version

Ich habe mich für die Desktop Version entschieden.

Installation

Da dass NC10 kein CD laufwerk hat, muss man das Ubuntu auf einen USB Stick bekommen. Dazu lud ich mir die das Ubuntu ISO Image und Transformierte es mit Unetbootin auf den USB Stick. Da man nach dem Boot direkt auf dem Desktop landet, kann man auch gleich sehen welche Hartware funktioniert. Die Installation ansich war erstaunlicherweise in 15 Minuten abgeschlossen.

Hardware Kompatibilität

Von Beginn an wurde jede Hartware erkannt. WLan wurde problemlos erkannt. Die Funktionstasten funktinieren auch alle bis auf die des Wlan´s. 2 Probleme hab ich allerdings gefunden. Der Standby Modus tut nicht und der Ath5k Wlan Modul stürt manchmal ab, was sich aber durch einen Shutdown wieder beheben lässt. Einen Patch bzw. Tip der zur Lösung des Problems führt, konnte ich bisher nicht finden.

Geschwindigkeit

Eines der großen Pluspunkte von Ubuntu auf dem NC10, ist die Geschwindigkeit. Sowohl Boot als auch Reaktionszeit (z.b. beim Fensteröffnen) sind gefühlt 1/3 schneller als bei XP. Während man bei XP immer das Gefühl hatte, es ist alles etwas träge, geht es beim Ubuntu richtig zügig. So öffnet sich Firefox meiner Meinung nach fast doppelt so schnell wie unter XP

Ich werde nun vorestmal bei Ubuntu bleiben, da ich keine Nachteile sehe,  mal abgesehen von dem Open Office, mit welchem ich mich immernoch nicht richtig anfreunden kann. Mal schauen, ob es Microsoft schafft, mich mit Windows 7 wieder umzustimmen.

Aus aktuellem Anlass, sollte jeder Internetnutzer überlegen, ob er den DNS Server seines Providers (vorallem bei den großen) noch benutzen will. Es gibt mehrer unabhängige DNS Server welche nicht zensiert oder mit sonstigen Umleitungen versehen werden (manche enthalten leider Werbung bei Fehlerhafter URL Eingabe).

Hier ein paar Organisationen welche zur Zeit auf ihren Webseiten ( Zeitpunkt des Blogeintags) IP´s zu unabhängigen DNS Servern anbieten.

German Privacy Foundation

OpenDns

Chaos Computer Club

So ändert man unter XP den DNS Server:

Start

-> Systemsteuerungen

-> Netzwerkverbindungen

-> Netzwerk Adapter

-> LAN oder WLan etc..

-> Rechtsklick -> Eigenschaften

-> TCP / IP Einstellungen

-> Benutze folgenden DNS Server

-> dort die IP des DNS Servers eintragen.

Dank des schönen Wetters gibs erst nach längerer Zeit mal wieder einen Blog-Eintrag.  Warum wird bei Java Socket Beispielen im Internet, immer alles mögliche in einen String gepackt (z.b. Datum, Namen usw). Dazwischen hat man dann immer diese schönen Trennzeichen wo dann immer gesplittet wird. Kaum eines der Beispiele zeigt, das Sockets auch noch andere Objekte verschicken können außer String .  Da es in Java leider nicht möglich ist, auf die Methoden einer Klasse zu zugreifen, ohne Cast, wenn diese in eine java.lang.Object initialisiert wurde (möglich, aber das entspricht nicht wirklich der Objektorientierung), muss die Klasse sowohl beim Sender als auch beim Empfänger verfügbar sein. Das Down-Casten vom java.lang.Object zu einer Klasse ist nur möglich wenn sich die Klasse sich in der Laufzeit befindet bzw. eingebunden wird.  Hier mal ein Beispiel für den Client:

Socket socket = new Socket(host, port);

ObjectOutputStream outputStream = new ObjectOutputStream(socket.getOutputStream());

String hallo = “Hallo”;

outputStream.writeObject(hallo);

MeineKlasse klasse = new MeineKlasse();

outputStream.writeObject(klasse);

outputStream.writeObject(new Date());

outputStream.flush();

outputStream.close();

Der Server dazu sieht zum Beispiel so aus:

ServerSocket server = new ServerSocket(port);

Socket socket = server.accept();

ObjectInputStream inputStream = new ObjectInputStream(socket.getInputStream());

String hallo = (String) inputStream.readObject();

MeineKlasse klasse = (MeineKlasse) inputStream.readObject();

Date date = (Date) inputStream.readObject();

inputStream.close();

Das Casten der Objekte muss in der Reihenfolge passieren in welcher diese abgeschickt wurden.

Da der Dell Poweredge für größere WebAnwendungen leider etwas schwach ist (2x 1,4 ghz), gabs jetzt einen zweiten Server. Hab mich diesmal für die Self-Made Lösung entschieden. Leider fehlt noch der Raid Controller und 4x 1TB HDD.

Da ich schon länger nicht mehr so viel mit MySQL zu tun hatte, hab ich mich gefragt, warum mein Mysql-Server die Connection meiner Javaanwendung refused. Wollte mich gerade auf die Googlerecherche machen, als mir es wieder einfiel:

/etc/mysql/my.cnf

Da war doch was

bind-address

skip-external-locking

Die meisten Mainboards haben schon eine Gigabit Netzwerkkarte integriert.  Allerdings hab ich festgestellt, das die Übertragungsraten leider kaum an die 38-45 mb/s rankommen. Konstruktionsbedingt sollte eine Onboardkarte ja schneller sein als ein PCI Karte.  Das ist aber meistens nicht der Fall, da eigentlich immer bei den Chips gespart wird. Das wird vorallem bei der Verteilung der Netzwerklast auf die CPU Kerne bemerkbar. Auch spielt  die Reduzierung von Interrupts eine nicht unbedeutende Rolle für die Geschwindigkeit. Gute Netzwerkkarten haben bessere eine Fehlerkorrektur der Ethernet Pakete, was ein nochmaliges Senden des Pakets vermeidet.

Wer also Wert auf ein bisschen mehr Speed legt, als die möchte gern 1000mbit Oboard, kommt wohl um eine vernünftige Netzwerkkarte nicht herum.

Eingentlich ist das Vergleichen eines Stringinhalts ziemlich simpel.
Dennoch wird es gerade bei der Überprüfung auf ” “, also auf keinen Inhalt aber existierendes Objekt, oft falsch gemacht!

if(string == “”){

}

if(string.equals(“”)){

}

if(“”.equals(string)){

}

Folgendes wäre beim Inhalt falsch, da diese Abfrage sich auf die Existenz eines Objekts bezieht:

if(string == null){

}

if(string.equals(null)){

}

Warum wir das schreiben? Man findet im Web viele Lösungsvorschläge, aber keine Übersicht über das ganze.

Es kursieren Gerüchte, Java sei nicht richtig Mulitcore-fähig.Dies ist jedoch seit Java 1.5 grundlegend widerlegt. Jedenfalls haben wir ein bisschen herumprobiert und festgestellt, dass die Thread Technik und das Memory Model ziemlich ausgereift sind.
Allerdings ist das ganze Thema nicht ganz einfach, da man wesentlich mehr Aspekte beachten muss als bei der sequentiellen Programmierung.

Threads  sind dazu da, dass Aufgaben parallel abgearbeitet werden können und somit die JVM nicht durch einen Task, der gerade ausgeführt wird, blockiert ist. Man will also erreichen, dass ein Thread über seine Laufzeit maximal ausgelastet ist.
Was ist nun aber wenn ein Thread auf das Ergebniss eines anderen Threads warten muss?
Dann sinkt die ‘Thread-Auslastung’ während der Wartezeit quasi auf null.
Hiermit sind wir schon bei dem zentralen Problem des Parallelprocessing, nämlich der Synchronisation zwischen Threads.
Wenn man von dem idealen Parallelprocessing ausgeht, dürfte keine Synchronisation zwischen den Threads vorhanden sein, weil diese kostet immer Zeit, und damit auch Performance. Da aber bei vielen MultiThread Programmen ein Mindestmaß an Synchronisation vorhanden sein sollte, ist das Java Memory Model von Nöten. (Falls man wirklich keine Synchronisation haben möchte, gibt es z.b.  java.util.concurrent.atomic). Hier sind ein paar Stichworte zum Java Memory Model. Folgendes ist zu beachten:

Sichtbarkeit, Final und static Fields, die Sicherheit während der Initialisierung, was darf wer und wann, usw….

Das oben gezeigte Schema illustriert ein Modell, bei welchem das locale Thread Ergebnis, sofort wenn es fest steht, einen Push auf das Globale Object ausführt.
Dabei ist es von Bedeutung, dass während der Zeit, in der das Object bearbeitet wird, kein anderer Thread etwas an dem Object verändert bzw. schon das neue Object bekommt, d.h. das Object muss blockiert werden und die anderen Threads müssen warten.
Ab Java 1.5 gibt es hierfür unter anderem volatile und syncronise

public class Kunden{

public static volatile ArrayList list;

public Kunden(){

list = new ArrayList();

}

public syncronised void addKunde(Kunde kunde){

list.add(kunde);

}

public syncronised void removeKunde(Kunde kunde){

list.remove(kunde);

}

public syncronised Kunde getLatest(){

list.get(list.size()-1);

}

}

In diesem Beispiel gibt die Methode getLatest() immer den wirklich letzten Kunde zurück, auch wenn gerade ein neuer Kunde hinzugefügt wurde. Denn syncronised blockiert das Object, solange die Methoden add/removeKunde/getLatest damit arbeiten und führt einen Flush auf alle Objecte aus damit diese tatsächlich den aktuellen Stand im Speicher haben, wenn die Methode ausgeführt ist.
Da die Softwareunterstützung für Multicore Prozessorarchitektur immernoch nicht richtig in Fahrt ist, bzw. erst langsam im kommen ist, wird sich jeder Programmierer irgendwann einmal damit beschäftigen müssen. Jedenfalls ist dieses Thema sehr spannend, da es teilweise sehr komplex  ist und man dadurch vor ganz neue Herrausforderungen gestellt wird.

Das Neueste auf dem Speichermarkt sind im Moment die Solid State Disks.
Diese zeichnen sich durch eine hohe Lese- und Schreibgeschwindigkeit aus. Diese kommt auch dadurch zustande, dass in eine SSD keine mechanischen Teile verbaut sind. Auch dürfte die Produktion in Zukunft billiger werden, da die Flash Speicherbausteine immer billiger werden.
Allerdings gibt es sowohl preislich als auch bei der Geschwindigkeit große
Unterschiede.
Es gibt im Moment 2 verschiedene Flash-Chips welche bei SSDs eingesetzt werden.

MLC (Multi Level Cell)
SLC (Single Level Cell)

SLC Chips sind teuerer in der Herstellung, dafür halten sie auch
länger, wobei die Haltbarkeit bei ca. durschnittlich 1000000 Betriebsstunden liegt und
länger als bei Hard Disks ist.
Generell sind in den meisten SSDs (Hauptsächlich bei den günstigeren) MLC Chips verbaut. Diese sind meist langsamer beim Schreiben und Lesen als SLC Chips.
Auch der verbaute Controller hat einen erheblichen Einfluss auf die Geschwindigkeit. Er zerteilt die Daten auf die einzelnen Flash-Chips. Da er auch die Datenteile wieder ‘zusammensuchen’ muss und sie auch wieder zusammensetzt, kommen bei teureren SSDs auch bessere Controller zum Einsatz, welche mehr Datenkanäle haben.

Leider hat die Technik noch ein paar Probleme, beispielsweise dass sie laut einigen Benchmarks langsamer werden,
wenn die Datenfüllung über 80% beträgt. Die Blockgröße bei der Formatierung hat auch Auswirkungen auf die Geschwindigkeit.

Die SSDs werden aber auf jedenfall in Zukunft ihren Platz neben den Harddisks haben.