[Talk-de] T at H furchtbar langsam

[Frederik Ramm]

Hi,

Dirk Stöcker wrote:
> Dann fühle ich mich einfach mal angesprochen. Ich habe OSM vor 
> vielleicht anderthalb bis 2 Jahren kennengelernt, hielt es für 
> unausgereift und habe es ignoriert.

Ging mir beim Erstkontakt auch so. Karte war leer, Projekt uninteressant.

[Arbeit an Merkaartor, JOSM, Tagwatch...]

Find ich prima, so soll es sein. Und von jemandem, der Probleme 
normalerweise anpackt, wo er sie sieht, laesst man sich auch eher mal 
auf eines hinweisen, das er nicht loesen zu koennen glaubt.

> Die nicht funktionierende OSMX-API stört mich und ich dachte darüber 
> nach vielleicht eine zweite Variante davon aufzusetzen. Aber oh Wunder, 
> findet sich natürlich nichts dazu im SVN (vielleicht ist es ja sogar 
> irgendwo drin, aber zu finden ist nichts).

Warum schreibst Du "oh Wunder...natuerlich"? Das klingt so, als ob Du 
annimmst, dass Dir da jemand absichtlich was vorenthalten will?

OSMXAPI ist von Etienne Cherdlu geschrieben, der auch Osmarender 
verbrochen hat. Es ist ein einer Programmiersprache gemacht, die 
angeblich ein moderner Dialekt von MUMPS ist. MUMPS ist eine 
Datenbank-Programmiersprache aus den 70er Jahren. Ich habe 80n gefragt, 
ob ich die Sourcen haben kann, und er sagte: "Gerne, aber Du muesstest 
Dir ca. eine Woche Zeit nehmen, um Dich von mir in eine etwas exotische 
Programmiersprache einweisen zu lassen". Warum es nicht im SVN ist, 
weiss ich nicht - 80n ist politisch ein sehr grosser GPL-Freund, also 
wird er bestimmt nichts geheimhalten wollen. Ich habe dann aber 
abgewunken und gedacht, so kompliziert ist es nun auch wieder nicht, das 
OSMXAPI vernuenftig in C auf einem PostGIS-Backend nachzubauen. Hab ich 
dann aber nie getan; anderes schien mir wichtiger.

> Und Grundvoraussetzung 
> des ganzen Projekts ist der stabile Betrieb der zentralen Infrastruktur. 
> Und Du wirst mir ja wohl kaum sagen wollen, dass ich gleich die zentrale 
> API auch klonen soll? Oder meinst Du das?

Naja. Die zentrale API ist in Ruby gemacht, und jeder, inkl. dem Admin, 
sagt, dass Ruby fuer diesen Betrieb - Daten aus SQL-Datenbank 
rausschaufeln, XML draus machen, ueber die Leitung schicken - absolut 
ungeeignet ist (wegen der schlechten String-Implementierung vor allem). 
Ich habe daher neulich, als ein nach eigenem Bekunden erfahrener 
C++-Programmierer fragte, was er sinnvolles tun koennte, empfohlen, er 
sollte doch mal den "map"-Call als Apache-Modul reimplementieren, und 
siehe da, er hats tatsaechlich gemacht, die Sache ist 10-15x so schnell 
und braucht einen Bruchteil des Speichers. (Das ist eines der Probleme 
im Moment, dass wir nur eine begrenzte Anzahl an parallelen API-Daemons 
laufen lassen koennen, weil man immer damit rechnen muss, dass ein 
speicheraufendiger map-Call kommt.) Ich habe das nicht genau verfolgt, 
aber ich rechne damit, dass diese Entwicklung in ein paar Monaten live 
gehen wird.

Ich weiss, dass Du viele andere sinnvolle Sachen machst, aber da Du so 
konkret fragst: Fuer diese C++-Implementierung hat der Typ auch 
keinerlei Hilfe bekommen, er war einfach ein Aussenseiter, der sich da 
reingefressen hat, und das haettest Du sicherlich auch tun koennen, wenn 
Du es hinreichend wichtig gefunden haettest.

Eine weitere Sache, die die Arbeitsgeschwindigkeit deutlich erhoehen 
wuerde, waere die Einrichtung von OSMXAPI-aehnlichen Mirrors, die aber 
(im Gegensatz zu OSMXAPI) die gesamte Palette der API-Leserequests 
koennen. Also einfach eine leicht modifizierte Version der normalen API 
aufsetzen, einen Job dahinter, der die minuetlichen Updates per Osmosis 
in die MySQL-Datenbank einspielt - alles kein Hexenwerk, "muss nur 
jemand machen" - und dann passen wir den JOSM so an, dass er seine 
Leserequests grundsaetzlich nicht aus der Masterdatenbank befriedigt, 
sondern aus einem der vorhandenen Mirrors. Die Datenbankperformance der 
Zentrale stuende dann hauptsaechlich fuer die Update-Requests zur 
Verfuegung. Warum wird das nicht gemacht?  Nicht etwa, weil irgendein 
finsterer Neinsager in der OSM-Zentrale dagegen waere; nicht etwa, weil 
es politisch nicht gewuenscht waere oder technisch schwierig... es hat 
sich einfach bislang nicht "der richtige" dafuer gefunden, der die Zeit 
und die Initiative dafuer aufbringt.

An wessen Adresse soll man also die Kritik daran richten, dass es solche 
Mirror-Server nicht gibt? "Die unfaehigen Admins sollten halt einfach 
sagen, was sie brauchen?" - "Die Foundation sollte jemanden einstellen, 
der das macht?" - Meiner bescheidenen Ansicht nach gibt es solche Server 
halt einfach nicht, weil es nicht *so* wichtig ist. Diejenigen im 
Projekt, die sowas machen *koennten*, tun es im Moment nicht, weil ihnen 
andere Sachen wichtiger erscheinen. Ist doch auch ihr gutes Recht. Ich 
kann doch nicht zu Dir sagen "verschwende doch keine Zeit mit 
Uebersetzungen von JOSM, wenn Du stattdessen einen API-Mirror bauen 
koenntest". Wenn die Performance der API wirklich *so* schlecht waere, 
dann wuerdest Du vermutlich von selber auf die Idee kommen.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"