• Push-Implementierung in der studiVZ iPhone App
  Max Horváth, Steffen Irrgang
  In dieser Session berichten wir, wie studiVZ die Push-Funktionalität auf der iPhone- und auf der Serverseite implementiert hat. Wir zeigen, wie der Client sich über das studiVZ-API anmeldet und über welche Architektur Push-Nachrichten auf dem iPhone landen. Dabei wird näher auf die AMQP-Queue-Infrastruktur von studiVZ eingegangen und gezeigt, welchen Fluss eine Benachrichtigung bei studiVZ durchlebt, bis sie auf dem iPhone eines Nutzers ankommt.

  Download Slides

  16.11.2009 | 09:45 – 10:45

• OAuth – ein offener Standard für die sichere Authentifizierung in APIs
  Bastian Hofmann, Max Horváth, Andre Zayarni
  In dieser Session widmen wir uns dem offenen Standard OAuth. Er wird für die sichere Authentifizierung in APIs genutzt. Wir zeigen, wie man OAuth implementiert und wieso es sinnvoll ist, Drittanwendungen über OAuth an die eigene API anzubinden. Außerdem gehen wir darauf ein, wie eine eigene Webapplikation mittels OAuth mit anderen Services verbunden werden kann.

  Download Slides

  16.11.2009 | 14:30 – 15:30

• OpenSocial in der Praxis
  Sebastian Galonska, Bastian Hofmann
  OpenSocial bietet vielfältige Möglichkeiten, die Funktionalität eines Social Networks zu erweitern. Dabei sind die Konzepte zur Entwicklung von Gadgets einfach zu erlernen. In dieser Session geben wir Einblicke, wie Gadgets für die VZ-Netzwerke, aber auch jeden anderen OpenSocial-kompatiblen Container, erstellt und veröffentlicht werden können. Dabei berücksichtigen wir auch Aspekte wie Skalierung und Sicherheit.

  Download Slides

  17.11.2009 | 10:30 – 11:30

• Best Practices bei der Entwicklung von öffentlichen APIs
  Steffen Irrgang, Max Horváth, Andre Zayarni
  In dieser Session soll praxisnah erörtert werden, welche Fallstricke und vor allem welche Best Practices in Bezug auf die Entwicklung von öffentlichen APIs zu beachten sind. Dabei konzentrieren wir uns auf RESTful Web Services sowie auf den offenen Authentifizierungsstandard OAuth.

  Download Slides

  17.11.2009 | 16:30 – 17:30

• Keynote: Bugfree, agil und überhaupt
  Jodok Batlogg
  In his keynote Jodok will highlight some insights on studiVZ. How important are agile processes? Is studiVZ really bugfree or is there a need for a bugtracking system? Why should one additional line of SQL require 10 additional servers and how can good profiling save you 20 of them?
  18.11.2009 | 11:45 – 12:30

When: 16. December 2009 at 5:00pm
Where: newthinking store, Tucholskystr. 48, Berlin, Germany

As always there will be slots of 20min each for talks on your Hadoop topic. After each talk there will be a lot time to discuss. You can order drinks directly at the bar in the newthinking store. If you like, you can order pizza. We will go to Cafe Aufsturz after the event for some beer and something to eat.

Talks scheduled so far:

Richard Hutton (nugg.ad): “Moving from five days to one hour.” – This talk explains how we made data processing scalable at nugg.ad. The company’s core business is online advertisement targeting. Our servers receive 10,000 requests per second resulting in data of 100GB per day.

As the classical data warehouse solution reached its limit, we moved to a framework built on top of Hadoop to make analytics speedy, data mining detailed and all of our lives easier. We will give an overview of our solution involving file system structures, scheduling, messaging and programming languages from the future.

Jörg Möllenkamp (Sun): “Hadoop on Sun”
Abstract: Hadoop is a well known technology inside of Sun. This talk want to show some interesting use cases of Hadoop in conjunction with Sun technologies. The first show case wants to demonstrate how Hadoop can used to load massive multicore system with up to 256 threads in a single system to the max. The second use case shows how several mechanisms integrated in Solaris can ease the deployment and operation of Hadoop even in non-dedicated environments. The last usecase will show the combination of the Sun Grid Engine and Hadoop. Talk may contain command-line demonstrations ;).

Nikolaus Pohle (nurago): “M/R for MR – Online Market Research powered by Apache Hadoop. Enable consultants to analyze online behavior for audience segmentation, advertising effects and usage patterns.”

We would like to invite you, the visitor to also tell your Hadoop story, if you like, you can bring slides – there will be a beamer. Thanks for Isabel Drost who is organizing this event and for Newthinking Store for providing Space. VZnet Netzwerke is sponsoring the video recording of the talks.

Registration:

If you couldn’t make it to the first “NoSQL Meetup Berlin” which recently took place at newthinking store — all the talks have been recorded and are on vimeo now:

• Consistency in Distributed Key/Value Stores, Monika Moser
  
• Redis — Fast and Furious, Mathias Meyer
  
• Peer to Peer Applications with CouchDB, Jan Lehnardt
  
• Riak, Martin Scholl
  
• MongoDB, Mathias Stearn
  
• 4th Generation Object Databases, Prof. Stefan Edlich
  

Heise has a good summary (in german).

Here at StudiVZ we are following this topic very closely and are actively investigating some of the alternatives. At the moment, Cassandra looks very promising to us.

Some more links:

• Quick Reference to Alternative data storages
• Comparing Key/Value Stores, Round 2
• NoSQL East 2009 – Summary of Day 1, Day 2

• We broadcasted the sessions live through uStream
• Our partner Wooga showed BrainBuddies, the first OpenSocial Gadget running on our platforms. It will become available when we launch OpenSocial

We had about 70 visitors at the Volksbar and over 30 people watched the live stream.
As requested you can download our presentations on the vCard and on BrainBuddies in German.

Watch out for upcoming dates so you can come and join us next time!

DevHouseBerlin is a fun-packed weekend of hacking and sharing knowledge. The Box119 office is open for a weekend and invites hackers of all sorts to join us working on projects, sharing code and ideas and just hanging out among fellow geeks.

DevHouseBerlin is highly influenced by the SuperHappyDevHouse:

SuperHappyDevHouse is a non-exclusive event intended for creative and curious people interested in technology. We’re about knowledge sharing, technology exploration, and ad-hoc collaboration. Come to have fun, build things, learn things, and meet new people. It’s called hacker culture, and we’re here to encourage it.

VZ is happy to provide you with first class Spreeschnittchen Catering. Enjoy!

We strongly believe that OpenSocial should also been taken literally so we started a monthly GeekNight where all interested developers are informed about our current projects and the release status of our OpenSocial implementation.

OpenSocial will become fully available by the end of the year. This leaves enough room to be out with stable and tested gadgets for the container’s OpenSocial launch.
However we already use GoogleGadgets to provide interactive ads and games on our platforms.

Über den mobilen Browser gelangt man direkt über folgende Links zur entsprechenden Anwendung im Market:

market://search?q=pname:net.studivz.android.studivz
market://search?q=pname:net.studivz.android.meinvz
market://search?q=pname:net.studivz.android.schuelervz

Die derzeitige Version 1.0b verfügt unter Anderen über folgende Funktionen:

• Buschfunk
• Lesen und schreiben von Nachrichten
• Anzeigen der Freundesliste
• Anzeige der letzten Besucher
• Gruscheln

Die erste Version stellt somit die wesentlichen Funktionen bereit und wird nun zügig mit weiteren Features, wie sie bereits von der normalen Web-Oberfläche bekannt sind, erweitert.

Bis dahin freuen wir uns natürlich über jegliches Feedback zu den Anwendungen.

The user’s proximity to your web server has an impact on response times. Deploying your content across multiple, geographically dispersed servers will make your pages load faster from the user’s perspective. [...] Remember that 80-90% of the end-user response time is spent downloading all the components in the page: images, stylesheets, scripts, Flash, etc. [...] A content delivery network (CDN) is a collection of web servers distributed across multiple locations to deliver content more efficiently to users.

Steve posted this approx. e^3.25809654 days after(!) we started to use a CDN for our web sites. Just some days later we noticed the desired effect. Our users started to make more and more traffic. The activity grew. Of course a CDN is some kind of luxury but it’s worth to invest into such a service at a special time. And from our point of view we thought it was time to. We were right.

Actually round about 286.356,421^2 objects will be requested per month by our users. More than the half of that (5,4E10 objects) are photos. Small, medium and big sized ones. So each of all photo files we store will be loaded round(pow(2,4.91)) times in a month. That makes a monthly traffic volume of more ore less 265.334.489.612.288 bytes only for these kind of objects. The total traffic of all delivered objects per month is something about 1,402939962446178 times higher.

At high traffic times there are over 11000011010100000₂ requests per second hitting our CDN and we are happy that our origin servers only get the (5^5)th part of it.

As a side effect we can learn something about the behaviour of our users because the performance graphs can show us for example what they do in the evening. Maybe the Schimanski serials on 26th of July was one of the reasons for the spikes after 8 pm (see graph above) which are nothing else than commercial breaks. Have a break, have a visit at studiVZ.

Nährere Infos sind auf dem entsprechenden Edelprofil bei studiVZ und meinVZ zu finden.

Wir freuen uns auf viele Interessante Gespräche in gepflegter Atmosphäre!

Update
Wir werden Ende September eine weitere GeekNight in Berlin veranstalten, um euch über den aktuellen Stand zu informieren. Der Termin wird rechtzeitig angekündigt, versprochen ;).

The common strategy to solve this problem is to install Selenium Grid on the machine that formerly hosted the one Selenium RC to parallelize the execution of the tests. By connecting only 4 Selenium RC’s to this Grid Hub the execution time of these tests is reduced by a factor of 4 without any additional hardware and without rewriting the tests. The only prerequisite for this is that the used testing framework supports a parallelized test execution, i.e. it must be able to start more than one test of a test suite simultaneously and assign the answers supplied by Selenium Grid to the right test again.

Although our used testing framework PHPUnit does not provide a parallel execution of tests yet we found a way to use the benefits of Selenium Grid in our testing environment. Our continuous integration server provides the possibility to set up more than one build agent to run the Selenium driven acceptance tests. If we would do this with one single Selenium RC these agents would stress this RC rapidly because there is no possibility to check its state. The agents would start new tests no matter how many tests are already running at this RC.

So we installed Selenium Grid with 4 connected Remote Controls as described above. We can now control the number of simultaneously running tests, because Selenium Grid starts only so many test suites as RC’s are connected. Other incoming requests are queued in the Selenium Grid Hub until one of the connected RC’s has finished its test suite. Unlike the common usage of Selenium Grid we have not yet a real parallelization with this solution, since the test suites from the build agents of the continuous integration server run simultaneously, but each is still to be processed sequentially. But we have always the option of switching to a real parallelization when our testing framework supports it.

mckoy is a memcache protocol sniffer (based on pcap library) and statistics builder. It automatically detects and parses each key (and its value) and memcache-api methods.  At  the  end of the sniffing session, the results are used to build the statisticis. mckoy was written to analyse our web application and its usage of  memcache-api in PHP. For example: We wanted to know how many set() and get() methods were invoked in a given time. Based on these results,  we had to make changes to improve the usage of memcache-api for PHP. You can run mckoy on any UNIX based systems. It was tested on many *BSD and Linux systems. mckoy is licensed under GPLv3 and completely published as opensource project!

You can run mckoy in various modes (see manpage!). For example, if you want to sniff pattern “foobar” for all memcache-api methods and with live capturing, use:

mckoy -i <interface> -e “port 11211″ -m 5 -k foobar -v

And this is, how it looks like:

Unfortunately, there are some known bugs. :) For example: An SIGSEGV will encounter when ^C is sent from user. Also, we noticed that mckoy isn’t able to handle memcached-1.2.8 <= 1.4.* correctly. These bugs will be fixed in the next version as soon as possible! For the next version I also planned to build in udp and binary support.

You can offcially download mckoy from:
http://www.lamergarten.de/releases.html
or
http://sourceforge.net/projects/mckoy/

cheers.

Some of the issues they’ve been working on:

1. Erlang now detects CPU Topology automatically at startup.
2. Multiple run-queues
3. You can lock schedulers to logical CPU’S
4. Improved message passing – reduced lock time

They improved more things of course but considering SMP these are the most important ones.

1. Erlang now detects the CPU topology of your system automatically at startup. You may still override this automatic setup using:
   erl +sct L0-3c0-3
erlang:system_flag(cpu_topology,CpuTopology).
2. Multiple run queues … what does that mean? We should first take a look at how Erlang does SMP:
   • Erlang without SMP:
     Without SMP support the Erlang VM had one Scheduler for one runqueue. So all the jobs were pushed on one queue and fetched by one scheduler.
   • Erlang SMP / before R13
     They started more schedulers that were pulling jobs from one queue. Sounds more parallel but still not performing as good as desired on many cores.
   • Erlang SMP R13
     Several schedulers like in the former solution but each of them has it’s own runqueue. The problem with this approach is that it can of course happen that you end up with some empty and some full queues because of the different runtime of the processes. So they build something called migration logic that is controlling and balancing the different runqueues.

   They migration logic does:

   • collect statistics about the maxlength of all scheduler’s runqueues
   • setup migration paths
   • Take away jobs from full-load schedulers and pushing jobs on low load scheduler queues

   Running on full load or not! If all schedulers are not fully loaded, jobs will be migrated to schedulers with lower id’s and thus making some schedulers inactive.

   This makes perfectly sense because the more schedulers and runqueues you need the more migrating has to be done. Using SMP support with many schedulers makes only sense if you’re really optimizing for many cores and you will have decreased performance on systems with few cores.

3. Binding schedulers to CPU’s is really worth looking at it. The more cores your CPU has the more important it’ll be and the more performance improvement you’ll gain. You can force the erlang VM to do scheduler binding by:
   erl +sbt db
erlang:system_flag(scheduler_bind_type,default_bind).1>erlang:system_info(cpu_topology).
[{processor,[{core,{logical,0}},
{core,{logical,3}},
{core,{logical,1}},
{core,{logical,2}}]}]
2> erlang:system_info(scheduler_bindings).
{unbound,unbound,unbound,unbound}
fabrizio@machine:~$ erl +sbt db
1> erlang:system_info(scheduler_bindings).
{0,1,3,2}

Source: presentation Kenneth Lundin – Erlang-Factory

You can test and benchmark SMP using following flags:
fabrizio@machine:~$ erl -smp disable       //default is auto
fabrizio@machine:~$ erl +S 2:4               //Number of Schedulers : Schedulers online

With erlang:system_info/1 you can use the following atoms

# cpu_topology
# multi_scheduling
# scheduler_bind_type
scheduler_bindings
logical_processors
multi_scheduling_blockers
scheduler_id
schedulers
# schedulers_online
smp_support

The ones marked with # can be set using system_flag/2

Nach dem Launch der ersten Version des Buschfunks, gab es bereits wenige Minuten später einen riesigen Impakt auf unserer Serverfarm. Dies führte dazu, dass wir bereits nach einem Tag die Statusnachrichtendatenbank auf eigene Server umziehen mussten. Ihr seht hier die absolute Anzahl von Statusaktualisierungen pro Minute (getrennt nach studiVZ/meinVZ = blau/flacher Graph und schuelerVZ = rot/steiler Graph):

Man kann Feeds, also Mitteilungen über Statusaktualisierungen eines Freundes, unterschiedlich implementieren und stellt sich dabei einigen Herausforderungen, gerade wenn es nicht nur um die optimale Speicherung, sondern auch um performante Zugriffe und logisches Zusammenführen von ähnlichen Feedeinträgen geht.

Wir haben uns für erste Tests in Richtung Social-Feeds für eine reine Memcache-Implementierung entschieden. Man hat den Vorteil, dass man die ohnehin nur momentan interessanten Posts von Usern nicht in der Datenbank vorhalten muss und Memcacheoperationen dazu noch um einiges schneller sind. Für einen Feed baut man sich im einfachsten Fall eine Queue pro User mit sortierten Einträgen auf, die man als Entity im Memcache ablegt. Da man nicht unendlich viele Einträge vorhalten muss und ein Memcacheobjekt per default eh nur 1 MB pro Eintrag groß sein darf, limitiert man die Queue auf eine feste Anzahl und wirft bei einem neuen Eintrag einfach alte Einträge weg.

Ok, genug der Einleitung, kommen wir zu ein paar Codeschnippseln. Am besten baut man sich ein Interface, welches sich um das Handling von Feedeinträgen kümmert:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

interface FeedEntry {
 
//referenziertes Memcacheobject, also eigentlicher Inhalt
public function getFeedEntryReference(...);
 
//ist der Eintrag sichtbar -> Privacy
public function isFeedEntryHidden(...);
 
//initialer Aufbau
public function initializeFeedEntry(...);
 
[...]
 
}

Jetzt haben wir einen beliebig erweiterbaren Feed Typen und können mit Implementierungen, wie zum Beispiel Statusänderungen von Nutzerprofilen, Microblogeinträgen etc, beginnen.

Was man jetzt noch braucht, ist das eigentliche Aufbauen der Queue, also Füllen des Feeds mit Feed Typen. Man sollte sich überlegen, woraus ein Eintrag innerhalb der Queue aussehen soll. Es sollte die id des Users, einen Zeitstempel, sowie den eigentlichen Inhalt enthalten. Wir haben uns dafür entschieden, den Inhalt des Eintrages nur als Referenz in der Queue zu halten, damit bei Änderungen nicht jedes Queueobjekt, sondern lediglich das referenzierte Memcacheobjekt geändert werden muss. Ausserdem will man die Daten nicht doppelt im Speicher halten.

Beispielhaft könnte eine vereinfachte Queue folgendermaßen aussehen:

1
2
3
4
5

$queue = array(
0 => array ('timestamp' => time(), 'userId' => 123456789, 'contentId' => 1000, 'type' => TYPE_MICROBLOG),
1 => array ('timestamp' => time(), 'userId' => 1234567910, 'contentId' => 1001, 'type'  => TYPE_PHOTOCOMMENT)
[...]
);

Mit Hilfe des Typs und dessen konkreter Implementierung eines Feed Entries kann nun der eigentliche Inhalt aus einem weiteren Memcacheobjekt oder aus der Datenbank geholt werden. Sortiert ist die Queue bereits nach dem Einfügen eines neuen Entries. Wird nun der Content hinter einer solchen Referenz gelöscht, so braucht man die Queues der User, dessen Feeds beeinflusst werden, nicht updaten, da der Feed beim Einlesen automatisch merkt, dass die Referenz nicht mehr gültig ist und diese “überspringt”.

Für’s Aufbauen der Queue noch ein Tipp: Verwendet lieber mehrmaliges array_reverse im Zusammenhang mit array_push, anstatt ein array_shift! Das ist um Welten schneller, wenn man ein Element vorn ranhängt bzw. hinten anfügt.

(Quelle: http://www.ingo-schramm.de/blog/archives/9-PHP-array_shift-does-not-scale.html)

Da der Memcache, wenn der ihm zugewiesene Speicher vollläuft, wenig frequentierte Bereiche freigibt, muss man sich zwangsweise überlegen, wie man mit Datenverlusten innerhalb der Queue umgeht. Dazu könnte man zyklische Backups der Queueeinträge oder ein initiales Befüllen der Feedeinträge implementieren (im Interface bereits vorgesehen). Die eigentlichen Daten (bsp. das konkrete Statusupdate) bleiben natürlich erhalten und liegen in der Datenbank persistent vor, es geht hierbei nur um die Referenzen auf diese Einträge.

Wir beginnen mit dem 11Freunde Hingucker (StudiVZ/MeinVZ).

Viel Spaß!

Intern waren vor allem unsere HTML/CSS und JavaScript-Fachkräfte schon tatkräftig bei der Arbeit, um unsere Seite (und vor allem den Chat) für den IE8 fit zu machen. Erfreulicherweise gibt es aber garnicht mal soviele Unterschiede zum IE7, somit gehen die Anpassungen relativ schnell von der Hand.

Eine weitere – vielleicht sogar die größte – Neuerung, wird bereits jetzt von unseren Platformen unterstützt: Die Web Slices (Web Slice Format Specification). Web Slices sind eigentlich eine Mischung aus Favoriten mit Vorschaufunktion und RSS-Feeds. Man kann sich Bestandteile einer Webseite abonieren, die dann in regelmäßigen Zeitabständen automatisch aktualisiert werden. Der Anwender wird dann automatisch über Veränderungen informiert und muss nicht jedesmal selbst aktiv werden. Ansich also eine ganz nette Funktionalität. Auch in der IE-Addon Gallery sind wir schon vertreten, zu bestaunen unter www.ieaddons.com/de/social.

Bei uns kann man ein Web Slice hinzufügen, mit dem man den vollen Überblick über Aktivitäten im eigenen Netzwerk bekommt. Wer war auf meiner Seite? Habe ich neue Nachrichten? Hat mir jemand etwas gezeigt? Das sind nur einige Fragen, die dort beantwortet werden und zwar egal auf welcher Seite man gerade unterwegs ist. Voraussetzung ist, dass der Nutzer unsere (auch recht neue) Remember-Me-Funktion (die persistener Cookie beim Anwender setzt) aktiviert hat, sonst muss man sich jedesmal neu einloggen.

Technisch ist ein Web Slice simpel aufgebaut:

• Ein umgebendes (DIV-)Tag mit der Klasse “hslice” und einer ID
• Ein Tag mit der Klasse “entry-title”, deren Inhalt den Titel definiert
• Ein Tag mit der Klasse “entry-content” für den eigentlichen Inhalt der angezeigt werden soll

Darüber hinaus kann dieses Basis-Konzept eines Web Slices natürlich noch erweitert werden. Bei studiVZ kommt z.B. eine “Alternative Display Source” und eine “Alternative Update Source” zum Einsatz, damit nicht bei jedem Update die komplette Startseite aufgerufen werden muss, sondern wirklich nur das, was auch im Web Slice angezeigt wird.

Die nachstehende Grafik soll die Zusammenhänge nochmals verdeutlichen:

WebSlice bei studiVZ

Wenn ihr den IE8 bereits am Start habt, könnt ihr das Web Slice auf der Startseite oder in der IE-Addon Gallery abonieren. Natürlich gibt’s das Web Slice für alle drei Platformen.

Zusatz:
Auch für den Firefox wird bereits ein Plug-In für die Web Slices und die Activities umgesetzt. Sieht auf jeden Fall interessant aus.

Inspired by this post http://blueparabola.com/blog/spl-deserves-some-reiteration we decided to run our own benchmarks to either verify or disapprove the results posted. Our benchmarks were executed on a 64bit RHEL with PHP 5.3.0beta1. As you may expect, we carefully excluded startup or compilation time and measured only the code blocks in question. We used getrusage() to determine CPU time consumption. A huge number of iterations guaranteed smooth results.

The first structure under consideration was the SplFixedArray. If you only need numerical indices you now can create an array of fixed size that does not have to grow while more and more items are inserted. Dealing with an SplFixedArray saves you about 10 percent of runtime compared to a plain old PHP array.

Next we tried the SplStack and SplQueue. It is usually easy to implement a stack and a queue with plain arrays. Using array_push(), array_pop() and array_shift() is straightforward. It may be a surprise to the average PHP programmer to learn about the runtime behaviour of these functions. Worst is array_shift() because of the internal rehashing and the experienced PHP programmer may – for critical code at least – try to access arrays by indices maintaining counters, for example. This is much more efficient. Compared to the functions, at least SplQueue is something like an upset, but it is possible to find comparable solutions with plain PHP.

There is a little danger to compare apples and pears when turning towards SplHeap and SplPriorityQueue. What is the proper representation of a heap implemented using plain old arrays only? It’s a sorted array, ok. But a heap is sorted for each insert, so, do we really have to sort the array for each insert? Who will do this in real life?

It’s the use case that decides about the sorting strategy. If you are supposed to carefully separate writing the heap and reading from it, it is sufficient to sort it once. That way you beat SPL. But if you have to mix reading and writing arbitrarily the SPL will beat plain arrays by far. This is shown in the pictures below. For the mixed strategy we read once for 5 inserts and the SplMinHeap scales very well. The same holds for SplMaxHeap and SplPriorityQueue.

Lessons learned:

• SPL rules
• use SPL data structures where appropriate for a particular use case, they are efficient and comfortable
• benchmarking is error prone
• anyway, always benchmark performance critical code blocks

• myTop
• show innodb status
• DSH (Distributed SSH Shell)
• Maatkit (http://www.maatkit.org/)

Aus Maatkit eignet sich mk-query-digest besonders gut, um ein System nach einem Neustart der Datenbank “aufzuwärmen”.

mk-query-digest --processlist h=d-mm-05-1-svz --execute h=d-mm-05-2-svz \
   --filter '$event->{fingerprint} =~ m/^select/

Außerdem kann man damit sehr elegant an einem Zweitsystem verschiedene Dinge testen und die Auswirkungen direkt beobachten.
Es bietet sich dazu an, dass man sein System damit immer genau im Blick hat:

• Ganglia (Distributiertes Grid Monitoring)

Ganglia ist eine Allzweckwaffe, um ein Gefühl dafür zu bekommen, wie eine Datenbank “lebt”. Es visualisiert quasi den Herzschlag des Systems. Durch gmetric bekommt man zudem die Möglichkeit mit wenig Aufwand alle möglichen Parameter vom System oder der Datenbank an Ganglia zu übergeben und damit zu visualisieren. Basics dabei sind die Queries per Second, Slave Lag und Slow Queries per Second.

• iostat -x

Was ist auf meinen Platten los? Wie verteilt sich das await auf die einzelnen Devices? Viel sieht man damit leider nicht, aber es gibt deswegen Erweiterungen für MySQL, die das IO bis auf Tabellen und Indizes runterbrechen können.

• Nagios – damit man den Fehler auch mitbekommt

Kristian Köhntopp hat dafür was Nettes gebaut. Man braucht an der Stelle also nicht mehr ganz so viel tun.

Nicht zu vergessen der Kommandozeilenclient mysql mit einem ordentlichen Prompt, damit man nicht bei mehreren Maschinen durcheinander kommt:

[mysql]
prompt = \u@hostname[\d]>\_

]]> http://developer.studivz.net/2009/03/16/mysql-dba-tools/feed/ 0 http://developer.studivz.net/2009/03/13/a-good-piece-of-geek-stuff-client-side-image-processing-with-gears/ http://developer.studivz.net/2009/03/13/a-good-piece-of-geek-stuff-client-side-image-processing-with-gears/#comments Fri, 13 Mar 2009 10:04:21 +0000 fabrizio http://blog.studivz.net/?p=168 In the latest downtime we released a beta version of a new photo uploader. Since we removed the Java based uploader some time ago, we’ve been dreaming of offering our users an uploader that’s able to do the same as the applet did, without requiring Java and of course with less conflicts on the different clients.

So the requirements for the uploader were :

• uploading (of course :D)
• scaling
• rotating
• compression

We implemented a Flash based uploader that could do a multiupload but neither scale nor compress the pictures before upload. So there is the problem, no direct access to the local files on the client.

On the Google Developer Days in Munich last year a collegue and I heard of the possibilities Gears offers and we were quite suprised how far it pushes the abilities of the client. Dreaming of all the geeky things I could do with Gears I also hoped to be able to solve that fileaccess problem. But unfortunately Gears did not offer the announced canvas API and also the desktop API hadn’t implemented the needed interfaces so far.

Enough story let’s look at the code …


var desktop = google.gears.factory.create('beta.desktop');
var localServer = google.gears.factory.create('beta.localserver');
var store = localServer.createStore('picturesTemp');

November 24, 2008: Google released the 0.5 version of Gears and there it was, the local server offered captureBlob() .

We created the needed Gears features, desktop for the fileaccess, localserver to store the files on the client.


$('#openFile').bind('click', function(){
gearsComponents_.desktop.openFiles(openFilesCallback_, {
filter: ['image/jpeg', 'image/png', 'image/bmp', 'image/gif']
});
});

Here we’re binding the filepicker dialog to some button, providing a filter to delimit the shown files to supported types.

var url = yourdomain;
var openFilesCallback_ = function(files){
var file = files_.shift();
gearsComponents_.pictureStorage.captureBlob(file.blob, url, "image/" + file.name.substring(file.name.lastIndexOf('.') + 1));
}

Capturing the blob to the local server like shown above solves two problems. Now we can access the files and import them into the canvas element, because it can be delivered via the same domain as the main page so there is no crossdomain security problem.

var canvas = $('<canvas>').get(0);
var context = canvas.getContext('2d');
canvas.width = canvasOriginal.width * fac;
canvas.height = canvasOriginal.height * fac;
context.scale(fac, fac);
context.drawImage(canvasOriginal, 0, 0);

In this example the canvasOriginal is the canvas/image from the localserver. We can now rotate, scale etc. the picture if the browser supports these actions on the canvas element.

You can also apply filters on the images by extracting the picture information as pixelarray modifying it and pushing it back:


// get the imagedata
var imgdata = canvasOriginalContext.getImageData(0, 0, canvasOriginal.width, canvasOriginal.height);
// do something with the pixel data
// push the imagedata back
context.putImageData(processedData, 0, 0);

As Javascript blocks while executing code this will for sure cause serious GUI problems, so let’s use a Gears worker to solve that problem.
First we have to create a workerpool:


var workerPool = (function(){
if (window.google) {
return google.gears.factory.create('beta.workerpool');
}
}());

The workerpool needs an onmessage handler which will be called on receiving messages by a childworker:


workerPool.onmessage = function(a, b, message){
//message will contain our processed pixelarray
};

The workers have no access to the dom so we only push the pixelarray in and get it back in the onmessage handler


// accessing the predefined workerpool
var script = 'var wp = google.gears.workerPool;' +
'wp.onmessage = function(a, b, message) {' +
'var data = message.body[0];' +
'//Process the data here' +
'//send the data back to the worker pool'
'wp.sendMessage(reply, message.sender);' +
// create a childworker by script (could also be created by url pointing to a script)
var childWorkerId = workerPool.createWorker(script);

We currently only use workers to apply a filter to the pictures.

Now we can do anything we want with the pictures but what about sending them to the server.

The solution to that problem is the toDataURL() method of the canvas element which exports the pictures to a “data URL”, which we can send to the server by a simple xhr as post.

According to the HTML5 spec toDataURL() should support several parameters first the data type  – e.g. toDataURL(’image/jpeg’) – the second parameter should be the compression rate as float value.

The compression rate does not seem to be supported by Firefox so far, so you should leave it blank then Firefox uses it’s default value.

The released beta version of the Gears uploader only supports Firefox because of the missing canvas (especially picture export) support in most of the browsers. Another drawback is that Gears is not available on all OS/browser combinations.

I hope that Safari will soon support (didn’t look at Safari 4 so far) the needed Canvas export methods, so that the uploader will work with Mac/Safari.

The CanvasAPI of Gears is already available in the sources but it’s not sure if and when it will be released. So perhaps some day there will be also a canvas element available in IE via Gears.

Have fun with the Gears uploader!

Seit einiger Zeit nutzen wir auf unserer Plattform die MySQL-Version von Percona, weil es unheimlich praktische Patches gibt, die uns als DBA das Leben erleichtern.

• Session status to check fragmentation of the last InnoDB scan
• SHOW USER/TABLE/INDEX statistics
• SHOW PATCHES
• Adds additional information of InnoDB internal hash table memories in SHOW INNODB STATUS
• Information schema table of InnoDB IO counts for each datafile pages
• Adds INFOMATION_SCHEMA.PROCESSLIST with TIME_MS column
• Add locks held, remove locked records in SHOW INNODB STATUS
• Extended statistics in slow.log
• Patch allows redirect output of error.log to syslog-ng
• Information of fsync callers in InnoDB
• Show innodb buffer pool content

Mit show index_statistics sieht man z.B. sehr gut, wieviele Rows durch welchen Index gelesen wurden. Ideal, um nicht benutzte Indizes aufzuspüren.
Natürlich will man auch wissen, wie sich die IO auf einzelne Tabellen und Indizes verteilt. Dafür gibt es dann im Information-Schema die Tabelle INNODB_IO_PATTERN:

$ describe INNODB_IO_PATTERN;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| SPACE      | bigint(11)  | NO   |     | 0       |       |
| OFFSET     | bigint(11)  | NO   |     | 0       |       |
| INDEX_ID   | bigint(11)  | NO   |     | 0       |       |
| TABLE_NAME | varchar(32) | NO   |     | NULL    |       |
| INDEX_NAME | varchar(32) | NO   |     | NULL    |       |
| N_READ     | bigint(11)  | NO   |     | 0       |       |
| N_WRITE    | bigint(11)  | NO   |     | 0       |       |
+------------+-------------+------+-----+---------+-------+
7 rows in set (0.01 sec)
 

Bevor man Auswertungen starten kann, muss MySQL erstmal Daten sammeln:

$ set global innodb_io_pattern_trace = 1;
$ set global innodb_io_pattern_trace_running = 1;
$ set global innodb_io_pattern_trace_size_limit = 1;
-- Anzahl der Pages die gesammelt werden sollen

Man muss auch unbedingt darauf achten, dass man genug freien Hauptspeicher hat, bevor man das Tracing startet.
Auswertung des IO für jeden Index, getrennt nach Read und Write:

$ select sum(i.n_read) n_read, sum(i.n_write) n_write, index_name, table_name from information_schema.innodb_io_pattern i group by index_id

Dokumenation, Sourcen und Binaries finden sich im Wiki von Percona. Großes Lob also an die verschiedenen Entwickler, die dafür sorgen, dass auch die Datenbanken bei studiVZ unheimlich gut performen. Hier aus unserem Grid Monitoring die aggregierte Datenbanklast in Queries pro Sekunden:

Alle Bildschirme der Entwicklungsabteilung (inkl. System Operations) zusammen genommen kommt man auf

202 Megapixel (Mpx)

Das sind ziemlich exakt so viele Pixel wie die HIPerWall an der UC Irvine. Wobei die dort 30-Zoll-Geräte nutzen und somit für die selben Mpx weniger Monitore brauchen.

Wenn man unsere 202 Megapixel auf eine Bildschirmwand im Seitenverhältnis 16:10 verteilen würde, hätte man eine Monitor-Einheit von 18.000 x 11.250 px. Mit den bei 24-Zöllern üblichen 94 PPI wäre das eine Fläche von etwa 191 Zoll x 119 Zoll. Das entspricht

4,8m x 3,0m

In dieser Rechnung sind noch nicht die vielen Leute mit Geräten dabei, die bei studiVZ in anderen Bereichen arbeiten. Da gibt es u.a. noch Marketing, Sales und vor allem den großen Support.

Und das hier sind noch zwei Schnappschüsse aus dem Maschinenraum. Die Büros und die Backfabrik stellen wir bestimmt später nochmal etwas genauer vor.

Übrigens… In Spitzen laden VZ Nutzer mal locker über 1.000.000 neue Fotos am Tag bei uns hoch und es werden um die/über 70.000 Anfragen pro Sekunde an unser CDN gestellt. Das CDN schützt unsere Image Server (die Server, die die ganzen Fotos und anderen statischen Inhalte ausliefern) davor, sich dieser enormen Last selber stellen zu müssen.

Ich weiß nicht, was ich verbrochen habe, aber ich sehe seit einigen Tagen keine Fotos mehr im meinVZ, studiVZ oder schülerVZ. Hilfeee!

Dafür kann es verschiedene Gründe geben. Letztlich reduziert sich das darauf, dass euer Browser (Firefox, Internet Explorer, Safari, Opera usw.) keinen korrekten “Referrer” übermittelt. Daran muss nicht direkt der Browser schuld sein. Antiviren-, Firewall- oder Proxy-Software zum Beispiel beeinflussen die Übermittlung des Referrers bzw. verändern diesen dahingehend, dass anstelle des korrekten Referrers ein “Blocked by Firewall XYZ” übermittelt wird, sofern man dies nicht deaktiviert. Manche haben sich vielleicht das Firefox Add-on “RefControl” installiert. Dort und bei der anderen Software sollte zumindest das Senden eines leeren Referrers eingestellt sein. Dann müsste alles wieder funktionieren.

[UPDATE]
Wir haben uns unterdessen dazu entschieden, auch leere Referrer zu akzeptieren. Deshalb wurde der Artikel entsprechend angepasst und ist jetzt etwas übersichtlicher geworden.

[UPDATE]
Unterdessen sind leere Referrer wieder von der Whitelist gestrichen worden. Wer jetzt noch mit den Fotos ein Problem hat, schaue bitte in die entsprechenden Hilfegruppen:

http://www.meinvz.net/Groups/Overview/fbd443e298aee375
http://www.studivz.net/Groups/Overview/193b82ce5c44d2ba
http://www.schuelervz.net/Groups/Overview/f2d4f75f70701b0f

[UPDATE]
Leere Referer sind wieder erlaubt.

Unser besonderer Dank gilt hier Chris Chabot von Google, der die Basis des von uns eingesetzten Shindig Servers entwickelt hat. Natürlich waren noch einige studiVZ-spezifische Anpassungen notwendig. Unter Anderem haben wir zusätzlich zum Standard den “Group”-View eingeführt, der speziell für die Anzeige von Gadgets in Gruppen optimiert ist. Auch müssen Anbieter von Gadgets nicht mehr um die Last auf ihren Servern bangen, denn dank intelligenter Verteilung der statischen Inhalte auf unserer CDN Farm, ist die Verfügbarkeit der Inhalte gewährleistet.

Wir befinden uns noch in der Beta-Phase, weitere Funktionalitäten werden folgen. Ihr dürft also gespannt sein ;)

Die ersten Fussballverein-Gadgets in Kooperation mit Bild.de könnt ihr in den folgenden Gruppen bewundern:

studiVZ

• FC Bayern
• Borussia Dortmund *BVB 09*
• Schalke 04
• Hertha BSC Berlin 1892 e.V.
• Werder Bremen
• HSV
• 1. FC Köln
• Bayer 04 Leverkusen
• HANNOVER 96 – Mein Verein
• VfL Wolfsburg
  
• VfB Stuttgart
• Eintracht Frankfurt
• TSG 1899 Hoffenheim
• FC Energie Cottbus
• VFL.Borussia Mönchengladbach 1900 e.V.
• I ♥ DSC ARMINIA BIELEFELD
• VfL Bochum
• KSC

schülerVZ

• FC Bayern München – FCB
• FC Bayern München
• Borussia Dortmund
• FC SCHALKE 04
• SV Werder Bremen
• HSV
• Hertha BSC Berlin
• 1. FC Köln
• Bayer 04 Leverkusen
• Hannover 96 Fanclub
• VfL Wolfsburg
• VfB Stuttgart
• Eintracht Frankfurt
• TSG Hoffenheim
• FC Energie Cottbus
• Borussia Mönchengladbach
• Arminia Bielefeld
• VfL Bochum 1848
• KSC

meinVZ

• FC Bayern
• Borussia Dortmund *BVB 09*
• Schalke 04
• Hertha BSC Berlin 1892 e.V.
• Werder Bremen
• HSV
• 1. FC Köln
• Bayer 04 Leverkusen
• HANNOVER 96 – Mein Verein
• VfL Wolfsburg
  
• VfB Stuttgart
• Eintracht Frankfurt
• TSG 1899 Hoffenheim
• FC Energie Cottbus
• VFL.Borussia Mönchengladbach 1900 e.V.
• I ♥ DSC ARMINIA BIELEFELD
• VfL Bochum
• KSC

Google sowie das Logo sind ein eingetragenes Zeichen von Google Inc.

Die Versionen für meinVZ und schülerVZ werden in absehbarer Zeit folgen.

Die App wird möglichst zügig weiter entwickelt werden, schließlich sind noch lange nicht alle Funktionen damit möglich, die man über die normale Web-Oberfläche nutzen kann. Ihr könnt also gespannt sein.

Bis dahin freuen wir uns über konstruktives Feedback.

[NACHTRAG]
Freigabe war am Freitag, den 13.02. Heute (Montag, 16.02.) liest sich die Top 1 der “Hitliste” im deutschen App-Store so:

[NACHTRAG 2]

Die Apps für schülerVZ und meinVZ haben es nun auch geschafft und können geladen werden. Hier die App-Store-Links:

studiVZ
meinVZ
schülerVZ

Dennoch. Aus aktuellem Anlass wollen wir auch an dieser Stelle eindringlich vor der Browser Extension, Toolbar und sogenannten Symbolleiste “StudiVZ die Studenten Commuity Toolbar” warnen, die einen Trojaner mit Backdoor-Mechanismus enthält und persönliche Daten wie z.B. das studiVZ Passwort des Nutzers auszuspähen versucht. Sie ist nicht von uns. Das erkennt man u.a. daran, dass es nicht einmal ein Impressum oder sonstigen offiziellen Bezug zu uns gibt.

Da studiVZ selber [bis dato] kein Anbieter von Toolbars ist, mit keinem Toolbar-Betreiber kooperiert oder solche bewirbt,  raten wir unseren Nutzern dringend davon ab, Toolbars zu installieren, die mit dem  Namen studiVZ werben. Um Sicherheitslücken zu vermeiden, raten wir unseren Mitgliedern den regulären Weg zu gehen, d.h. mit einem Webbrowser direkt unsere Netzwerke zu besuchen.

Natürlich sollten eine Antivirus- und Firewall-Software auf jedem PC zur Basisausstattung gehören. Letztlich schützt aber auch der gesunde Menschenverstand und ein stets eindringlicher Blick, bevor man sich irgendeine Software installiert.

Siehe auch…
http://www.heise.de/security/StudiVZ-Toolbar-mit-Backdoor-in-Umlauf-Update–/news/meldung/132420
http://www.avertlabs.com/research/blog/index.php/2009/02/10/trojan-bundles-legit-social-network-toolbar-with-backdoor/

“Die Rennmäuse (Gerbillinae) bilden eine Unterfamilie der Langschwanzmäuse und bewohnen die Wüsten, Halbwüsten, Steppen und Savannen Afrikas und Asiens.” [Quelle: Wikipedia]

Das ist sogar fast richtig – aber eben nur fast, denn auch in der studiVZ-Entwicklungsabteilung leben zwei Exemplare dieser putzigen Tierart, die seit nunmehr fast 2 Jahren hier tapfer die Stellung halten. Im kalten Frühjahr 2007 wurde nach einer denkwürdigen Mittagspause die Entscheidung getroffen, dass doch ein Haustier, oder genauer gesagt ein Firmentier, genau das richtige für uns wäre. Der Hamster war quasi schon ausgesucht und freute sich schon aus seinem stickigen Zoohandlungskäfig in eine bessere Zukunft entlassen zu werden. Tragischerweise (für den Hamster) befanden sich genau unter seinem Käfig die beiden Jungs, die bis heute bei uns ihr Unwesen treiben und sie passten einfach perfekt. Also Hamster wieder rein und Rennmäuse raus, denn zu zweit ist es natürlich auch für die Tierchen schöner. Außerdem stinken Mäuse weniger als Hamster, was ja in einem Großraumbüro ein nicht zu unterschätzender Faktor ist. Der Käfig war auch schon am Start und es ging geradewegs zurück in die Saarbrücker Straße.

Tja und seit dem leben die Beiden hier und hören auf die Namen V (der Hellere) und Z. Und da unsere Entwickler (und auch der Rest der Firma) sehr tierlieb sind, werden die Kleinen auch stets gehegt und gepflegt. Und vor allem auch eifrig gefüttert, was den Beiden eine leicht tischtennisballartige Figur verschafft hat. Dieser Entwicklung versuche ich als hauptverantwortlicher Pfleger durch eine gezielte Diät und mehr Sport Einhalt zu gebieten. Der Tagesablauf gibt außer schlafen, fressen, graben und nichtstun nämlich oft nicht so viel her. Auch wenn ich fest überzeugt bin, dass der Plan für die Weltherrschaft irgendwo in ihrem Micespace verborgen liegt. Achso: “Micespace” ist der offizielle Name für ihr Domizil, dass sich mittlerweile in der 3. Reinkarnation befindet. Angefangen hat es mit einem kleinen Plastikgehege über einen vierstöckigen Plattenbaukäfig bis hin zu ihrem heutigen Luxus-Glas-Terrarium-Prenzlberg-Loft.

Da die Lebenserwartung von solchen Tieren bei bis zu 5 Jahren liegt, haben sie auch genügend Zeit um sich ihren Traum von einer eigenen Yacht zu erfüllen und durch die Karibik zu schippern. Bei dem ganzen Know-How, das sie hier aufsaugen, dürfte das auch kein Problem werden. Als kleines Schmankerl gibt es unten ein kleines “Unplugged-Video” aus dem täglichen Wahnsinn im Mäusekäfig (übrigens noch ein altes Video mit der Version 1.0 des Käfigs).

Ehe man sich versieht, wird aus dem ehemals unsichtbaren Byte-Order-Mark-Steuerzeichen, ein sichtbares Zeichen, das besonders am Anfang von .php  und JS-Dateien durchaus für Ungemach sorgen kann, wenn es vom Webbrowser falsch interpretiert wird.  Entweder nur hässlich sichtbar oder der Code funktioniert nicht mehr.

Bei uns prüft ein pre-commit-hook jeden SVN-Commit auf BOMs. Und für alle Homepagebastler die sich auch schon das eine oder andere mal darüber geärgert haben – mit der simplen – auf einer Shell eines Linux-Rechners ausgeführten Zeile wird man die Dinger komplett los. Wenn man SVN benutzt, kann man die Änderungen danach auch direkt committen, da die SVN-Steuerdateien ausgenommen sind.

find .  -name .svn -prune -o -type f -print  | while read file;do [ "`head -c3 -- "$file"`" == $'\xef\xbb\xbf' ] && sed -i -s -e '1s/^\xef\xbb\xbf//' $files $file && echo "found BOM in: $file";done

Unter anderem sind wir dabei die Datensätze der Gruppenmitgliedschaften zu partitionieren, die vorher zusammen gespeichert waren. Es gibt von Flickr eine Präsentation über das Data Sharding die ziemlich gut beschreibt, was wir machen werden. Außerdem geht nach tagelanger Arbeit unser neuer LVS/ Heartbeat 2-Cluster mit einer neuen Version online. Mit dem LVS läuft im Backend die komplette Lastverteilung auf die Systeme, dank Direct Server Routing hält sich der Durchsatz auch in Grenzen, da nur die eingehenden Frames durch das System müssen.

Mehr dazu demnächst in einem anderem Blog-Post.

P.S. Der/das Blog bleibt online.

We’re just waiting for the App Store approval …

$array = array(1,2,3);
print $array[0];
>> 1
print $array['foo'];
>> Notice: Undefined index:  foo

$string = '123';
print $string[0];
>> 1
print $string['foo'];
>> 1


If you access a non existing index in an array you will be notified about a non existing index and NULL is returned. That’s fine so far. But what if you’re doing the same with a string? Is a string an array of characters as you might expect?

Unfortunately not in PHP. A string is a string and accessing a non existing index in a string is a different thing. PHP obviously converts the string index “foo” into an integer since strings have only numerical indices. Casting “foo” into integer is 0 and the character at position 0 is returned – without any notice. A string is not an array of characters.

As you may read here http://bugs.php.net/bug.php?id=44914 this is also fine for the creators of PHP. For me, I’m sorry, it’s a reason to stop using PHP (if I could at least). Implicit type casts in PHP are a story on its own and notoriously leading to subtle and hard to find bugs. But this one is beyond belief.

The only way to protect you from a catastrophe is to check at any and every usage of arrays if you really have an array. Type hint arrays. Use is_array() excessively. Write thousands of tests.

Better choice – use a well designed programming language. A better supported at least.

Vor Kurzem war unser Operations Team zu einem Workshop in unserem Rechenzentrum bei Telefónica o2 Germany, in dem unsere Server stehen, zu Besuch. Nach drei Stunden Fahrt mit der Deutschen Bahn (6 Uhr aufstehen ist wirklich das Schlimmste was es gibt), sind wir sogar pünktlich angekommen.

In Gütersloh bzw. Verl angekommen, ging es auch gleich mit dem vollen Programm los. Besichtigung der zentralen Stromeinspeisung (ein Ring mit 8 Megawatt Leistung), Spannungswandler bei denen die Kupferleiter fast dicker als mancher Arm sind, riesige Dieselaggregate, Batterien für die Überbrückung bis die Generatoren anlaufen. Angeblich dauert es auch nur 30 Sekunden bis alle Generatoren auf der gleichen Phase laufen und die Spannung umgeschalten wird.

Dann ging es weiter unter die Erde, hunderte lärmende Server, Storage-Systeme, Lastverteiler und tausende Kabel. Bei der Ordnung wünscht man sich, das hinter dem heimischen Schreibtisch die gleiche Ordnung bei den Kabeln herrscht, aber das bleibt wohl bis in alle Ewigkeit ein Wunschtraum.

Außerdem haben wir dort noch ein paar Schränke voll mit Festplatten, die vor allem die Fotos speichern und ausliefern (das folgende Foto ist ein rekursives Foto, denn es enthält sich selbst). Das ist schon ziemlich beeindruckend, wie die Lichter an den Platten blinken, weil draußen tausende Leute Bilder anschauen. Normalerweise sehen wir nur die Zahlen auf dem Bildschirm. Aber kubikmeterweise Technik, die riesig Lärm und Abwärme produziert, zeigt noch viel deutlicher, dass auf den Plattformen einiges los ist.

Wir haben das Gebäude nicht verlassen, ohne einen “Gruschel mich!”-Aufkleber auf eine Blende in einem Rack zu kleben. So sehen nun auch andere RZ-Besucher, dass wir da waren.

Apache is the canonical web server to serve PHP to the world. Thinking about technological alternatives in the backend domain we have a look at both Java and Erlang. A rather quick and easy test to compare the scalability of the technologies was to setup web servers delivering the same static document. The image below shows the results.

Apache and Tomcat scale nearly linearly up to a concurrency of 1000. We find that Mochiweb has a breakdown when concurrency reaches 300 but afterwards still scales linearly as Yaws does at a lower level. Absolute performance is less interesting here. What counts is the scaling behavior. Mochiweb for example is not designed first hand to deliver static content but to act as a HTTP endpoint for arbitrary OTP applications. Neither Yaws nor Mochiweb seem to cache documents in the default setup. Also, we did not use HiPE.

Unfortunally we had not yet the chance to verify the measurements given in this post: http://www.sics.se/~joe/apachevsyaws.html where Yaws still scales linearly (in the average) when Apache has long gone away, at concurrency of 50.000 or even 80.000 and clearly seems to survive DDoS attacks.

In this picture Erlang/OTP may not be a recommendation for classical web delivery but to build reliable services either to provide internal or external API endpoints. An interesing alternative at least.

Frontend Refactoring macht Userstylesheets und Greasemonkey Scripts unbrauchbar.

Um zukünftig flexibler und effizienter arbeiten zu können, haben wir die Plattformen schülerVZ, studiVZ und meinVZ einem Frontend Refactoring unterzogen. Optisch gibt es nur wenige Änderungen, unter der Haube steckt aber eine neue Konstruktion. Im Rahmen des Refactorings werden wir jetzt nach und nach auch alle Seiten anpassen und optimieren.

Mitglieder unserer Plattformen, die die Oberfläche via Userstylesheets oder Greasemonkey Scripts anpassen, werden nach dem nächsten Release (Donnerstag, 5. Februar 2009) diese Skripte nicht mehr verwenden können. Wer seine Skripte bereits vor dem nächsten Release prüfen und anpassen möchte, kann sich hier eine Zip-Datei downloaden. In der Zip-Datei sind wichtige Seiten abgespeichert, sodass man seine Skripte entsprechend anpassen kann.

Wir hoffen, das hilft etwas.

Download Zip-Datei

Schöne Grüße aus dem Maschinenraum.

Viel Spaß!

]]> http://developer.studivz.net/2009/02/02/5/feed/ 12