Wednesday, November 29, 2006

Google AdWords goes AdPics + AdMovies ?

Why should Google stay only with words for advertisments? - It may be right, that not everywhere pictures and movies are welcome (e.g.: the Google homepage).

But what about Flickr, Picasaweb, YouTube? If the eye is focused on one type of information (e.g.: pictures) and the bandwidth needed is already within the same order of magnitude, why not use pictures and movies?

Many products cannot be advertised well only with words, just open your mind!

Monday, October 23, 2006

Google deployment

Die Verteilmechanismen für ein Netzwerk, wie es Google betriebt müssen einfach und robust sein; aber auch für den Masseneinsatz skalieren.

Hier ein kurzer Artikel zum Thema:
* http://www.computerworld.com.au/index.php/id;1814790366;fp;16;fpid;0

Monday, July 24, 2006

Google, response time

As it looks, sending the same query several times results in an quicker answer:

Searching for "hello":
* First time: ~30 ms
* Next time: 5-10 ms

OMC-Cs: Caching looks probable, perhaps also only due to disk / memory caches?

Rough estimations about Response Time + Bandwidth:
* Disk performance (see http://www.storagereview.com/): ~9ms / 50 MB/s
* Network performance (1 Gigabit Link): ~0.3 ms / 120 MB/s
* RAM performance (http://arstechnica.com/paedia/storage.html): ~50 ns / 5 GB/s
* CPU performance: ???

Google traffic, 10'000 requests per seconds?

Estimating traffic on Google's data centers is difficult.

But here very rough estimation:
* 1 bn people worldwide using Google once a day.
* => 1bn / 100'000 secs / day /day

This would roughly result in 10'000 pages per seconds worldwide.

Assuming a distribution on 10 data center and doubeling the nightly traffic this break down to 2'000 pages per data center and seconds.

The Apache Hello World Benchmark result in officially support 2'000 pages per seconds of "complex" 30k data delivered, including paremeter handling.

OMC-Cs: This may even assume, that an intelligen form of Apache may be sufficient to load-balance deliver from the Google backend.

Google Accessability, for blinds or machines?

Although Google's efforts to improve site ranking due to accessability rankings may help blinds, it may also help the computers (quite blind) to read more of optimized pages.

An "alt=" Tag is for sure easier to read than doing Text-Recognition on pictures.

OMCs-Cs: A Win-Win situation for Google and blind people? May be - Could be? Shoud be!

Google "jobs" technologies

Google is still in the comfortable situation to hire persons able to learn any variation of a required skill very fast, but nevertheless the Job proposal sometimes show more about the Tools currently used.

Programming:
* GNU C/C++
* Java

Scripting
* Python
* Perl

Databases
* MySQL see

Television
* see

Operating System
* Linux

Build tools
* make
* ant
* SCONS

Source Control Management
* Perforce

Data Warehouse
* Netezza
* MicroStrategy

User interfaces:
* XUL, Flex, XAML

Web Design
* Adobe Photoshop and Illustrator

Hardware Design (Metal)
* Pro-E Wildfire

ERP
* Oracle Applications (INV, BOM, WIP, PO, CST, MRP, ENG & Quality)

OMC-Cs: Google shows a good taste for "state-of-art" tools and some surprises about lesser known things like "Netezza" and "SCONS".

Google's datacenters

The analysis of the "Google DNS Strategy" revealed a hint about possible locations about their datacenters. At least it shows the IP addresses of some Load-Balancer:

AS15169: Google

Country & Address for www.google.com


Is all the Google in a big memory database?
* http://blog.topix.net/archives/000011.html

Google operations

Es gibt viele Mythen zur Betriebsumgebung von Google. Hier wieder ein paar weitere News:

http://www.baselinemag.com/article2/0,1540,1985040,00.asp

Eine kleine Fehlermeldung:
http://www.abuzant.com/od/2006-07/google-server-errors-fact-or-fiction.html

OMCs-K: Ich kann's mir nicht verkneifen - Einiges von Google mag weder sinnvoll, noch wirtschaftlich sein. Aber ein solch gigantisches Netz von Computern unter Kontrolle verdient doch eindeutig meine Beachtung.

Google's speed - Der DNS Trick

Wer sich schon gefragt hat, warum Google so schnell ist. Hier vielleicht ein kleiner Teil der Antwort.

Ausgangslage
Grundsätzlich sind Antwortzeiten im Internet von zwei Dingern abhängig:
  • Wegkosten: Die Anfrage braucht im Netzwerk ihre Zeit bis zum Server, die Antwort auf dem Rückweg dito. Zudem können Bilder im zweiten Anlauf geholt werden, ergo verdoppelt sich noch die Zeit.
  • Erstellkosten: Die Antwort auf dem Server erstellt werden. Entweder statsich als Dateikopie oder dynamisch als berechnetes Generat.
Hypothese
Google's Performance können wird mit den folgenden Begründungen erklären:
  • Erstellkosten: Google ist Meister im Parallelisieren und hat den dazu nötigen Rechenpower (siehe andere Posts).
  • Wegkosten: Die Wegkosten können entweder mit schnelleren oder kürzeren Wegen erklärt werden.
    Da Google das Internet nicht alleine betreibt, kommt eher Fall (2 - kürzere Wege) in Frage. Die "www.google.com" Seite wird den Kunden von einer "regionalen" Stelle geliefert.

    Wie geht das?
    Ein Browser erfrägt sich bei "google.com" (die es nur zentral gibt), die Adresse für "www.google.com" an. Aufgrund der IP-Adresse des Kunden kann aus einer Datenbank ermittelt werden, aus welcher Zone er anfrägt und das nächste Rechenzentrum vermittelt werden. - So einfach geht das.

    Wie findet man so was heraus
    1. Man stellt die einfachen Hypothesen über die Performance auf.
    2. Über die Seite "traceroute.org" ermittelt man aus verschiedenen Stellen dieser Erde die "www.google.com" Adressen.
    3. Man erhält verschiedene Adressen (immer mit einem ".99" oder ".104" Ende).
    4. Die Wege sind jeweils recht kurz.
    Bingo: Die Hypothese war richtig.

    Die interkontinentalen Laufzeiten könnte man auch hier ungefähr abschätzen:
    * http://www.internettrafficreport.com

    OMCs-K: Gerade weil das Thema so mystisch ist, macht richtig Spass, sich die Fragen zur Infrastruktur von Google zu stellen. Ich kann das nur weiterempfehlen.

    Thursday, July 06, 2006

    Baseline Magazine's article

    What shall I say more. Have a look at:

    * http://www.baselinemag.com/article2/0,1540,1985054,00.asp

    OMC-Cs: Best article seen in the topic.

    Monday, July 03, 2006

    Operation patterns

    Es gibt zwar jede Menge Patterns zum Thema Softwarentwicklung, aber wie sieht es mit dem Betrieb aus? Google wird nachgesagt, 10'000 Maschinen weltweit zu verwalten - es soll möglich sein, ganze Schränke auf Knopfdruck für eine Aufgabe zu aktivieren.
    Die Hardware ist dabei "billig" (AMD Prozessoren, IDE Festplatten) und daher das Applikations-Design prinzipiell auf Ausfall ausgelegt - nicht als Ausnahmefall.

    Frage:
    * Welche Techniken braucht es für eine solche Beherrschung?
    * Wie kann es sein, dass ein solches reibungslos zusammen funktioniert?

    Annahmen:
    * Jede Maschinengruppe erhält das selbe Initialsetup.
    * Alle applikationspezifischen werden nachträglich hinzugefügt.

    Patterns:
    * Servicekatalog: Die möglichen Kandidaten ("Worker") zur Abarbeitung einer Aufgabe müssen bekannt sein.
    * Vollautomatische Installation: Neuinstallationen und Patches müssen mit Minimalem Aufwand einspielbar sein, ohne den Betrieb zu gefährden (Etappierung?).
    * Laststeuerung: Die Last im System so verteilt werden, dass langfristig keine Überlastung zu Stande kommt.

    ....

    OMC-Ks: Welche Muster sind einfach? Welche kompliziert? Wo könnte die Industrie allgemein gewinnen?

    Nachwort: Hier ein NYT Artikel zum Thema http://www.nytimes.com/2006/07/03/technology/03google.html?_r=1&pagewanted=all&oref=slogin