Archive for category tech-recipes
Cached json (or xml) view with CakePHP
Posted by Lars Schenk in tech-recipes on Dezember 23rd, 2009
While implementing caching for view as descriped in the cookbook i stumbled upon some glitches:
First I found out the best way to avoid problems with routing urls beeing not cached - especially when using Router::mapResources() - is to enable the caching per action in the controller like this:
function view($id = null) {
$this->cacheAction = "10 minutes";
// more stuff
}
The next problem was that cached views don't retain document mime type (xml, json, etc.). The first request works correctly (uncached request), but the second request will come back as text/html. You can find a more detailed description of the problem here.
I got an advice to enable callbacks for my views but that slows down and defeats the purpose of the cache. My approach now is to use a layout like this:
With the header('Content-type: text/x-json'); embedded in the nocache tags, it works fast and returns the correct mime type.
- Development-Server XDebug enabled, APC enabled, View cache disabled:
Requests per second: 1.64 [#/sec] - Development-Server XDebug enabled, APC enabled, View cache enabled (files):
Requests per second: 29.04 [#/sec] - Development-Server XDebug disabled, APC enabled, View cache enabled (files):
Requests per second: 95.66 [#/sec]
Further reading
8 Ways to Speed Up the Performance of CakePHP Apps.
Store View Cache in APC or Memcached.
Nagios commands via web-interface on Debian
Posted by Lars Schenk in Linux, Open Source, tech-recipes on Februar 24th, 2009
Ups, I did it again - when I upgraded to Debian GNU/Linux 5 (lenny) and Nagios3 I stumbled about this nagios error when I try to send directs commands via the web-interface:
Error: Could not stat() command file ‘/var/lib/nagios3/rw/nagios.cmd’!
In "/etc/nagios3/nagios.cfg" the "check_external_commands=1" was already set. So there was something more required to make it run on Debian...
Deep in my memory I know that there was a debian way to solve this user right related problem. This time I'll write it down here - perhaps I'll find it more easily when I upgrade to Debian GNU/Linux 6.0 (codenamed squeeze) and/or Nagios4.
/etc/init.d/nagios3 stop
dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios3/rw
dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios3
/etc/init.d/nagios3 start
So funktioniert der Apple Automator
Posted by Lars Schenk in Apple, Video, osx, tech-recipes on Januar 19th, 2009
Der Automator in OS X ist ein sehr nützliches Tool zum automatisieren von Routineaufgaben. Komplexe Arbeitsabläufe lassen sich zum wiederholten Anwenden zusammenstellen. Viele Anwendungen wie Finder, iTunes, Safari, iPhoto, Mail, iCal usw. lassen sich sehr leicht über den Automator nutzen so dass i.d.R. nicht einmal mehr eine einfache Scriptsprache wie z.b. AppleScript erforderlich ist um wiederkehrende Aufgaben in einer Art Minianwendung zusammenzufassen.
Ich glaube viele Apple Benutzer kennen das Tool aber nicht oder können vielleicht nicht viel damit anfangen. Vielleicht ändert sich das nun, denn Lars Blumberg erläutert in seinem wunderschön gemachten Screencast sehr anschaulich die Bedienung und Funktionsweise des Apple Automators. Da dieses Video im Rahmen eines Seminars "End user programming" entstanden ist, geht Lars Blumberg zu Beginn auf das Pipe-Konzept ein auf dem der Automator beruht, bevor ein Beispiel erläutert wird.
Im dritten Teil des Screencasts wird die Programmierung einer eigenen Erweiterung (Action) für den Automator mit Xcode demonstriert. Alle Schritte sind in dem liebevoll gemachtem Video ausführlich dokumentiert, so dass ich hoffe dass Anwender und Scripter neugierig gemacht werden sich einmal etwas ausführlicher mit Apples Automator auseinander zu setzen.
So funktioniert der Apple Automator from Lars Blumberg on Vimeo. (c) 2008 Lars Blumberg
Welchen DAC/KHV an Toslink: Citypulse, Zhaolu, Tianyun Zero, Audio Technika?
Posted by Lars Schenk in Musik, Persönliches, tech-recipes on Januar 17th, 2009
Um den wirklich sehr schlechten Analog-Ausgang des MacBook Pro zu umgehen (es rauscht und fieps; man hört eher das LogicBoard als die Musik - für ein AppleProdukt nicht akzeptabel ja sogar katastrophal; zumal das Vorgängermodel da deutlich besser war. read the full story here) möchte ich auf den optischen Ausgang ausweichen.
Folgende Geräte (allesamt mit optischen Input) für den nicht mobilen Einsatz hatte ich dabei im September 2008 in die engere Wahl gefasst: Read the rest of this entry »
Amazon CloudFront – Content Delivery Network für S3
Posted by Lars Schenk in Virtualisierung, tech-recipes on November 20th, 2008
CloudFront ist eine sinnvolle Erweiterung für Amazon S3: Wenn man S3 bisher als Asset-Server für statische Inhalte eingesetzt hat, so muss man sich für einen Standort entscheiden der möglichst nahe an der Zielgruppe betrieben wird. Ist meine Zielgruppe Europa, so wähle ich den S3 Standort dort und nehme in Kauf, dass User aus USA eine höhre Latenzzeit haben werden.
Mit CloudFront kann ich nun vor meinen öffentlichen S3 noch ein Content Delivery Network vorschalten, dass automatisch meine Inhalte über alle verfügbaren Standorte synchronisert und bei Requests auf meine Inhalte immer die schnellste Verbindung auswählt. Mehr Details zur neuen CloudFront, dem Content Delivery Network von Amazon gibt's unter aws.amazon.com/cloudfront/ und im original Wortlaut des Developer-Newsletters. Read the rest of this entry »
Vodafone WebSessions mit MacBook pro nutzen
Posted by Lars Schenk in Apple, osx, tech-recipes on März 22nd, 2008
Ich möchte die Vodafone Websessions mit meinem MacBook Pro nutzen und habe dazu den Vodafone EasyStick E172 (MC USB-Stick UMTS Broadband Huawei E1720) günstig bei Ebay erstanden. Als SIM kommt eine CallYa Karte zum Einsatz.
Wie in der Anleitung beschrieben muss zunächst die aktuelle Dashboard-Software für Apple-Notebooks installiert werden. Die aktivierte SIM in den USB-Modem-Stick einlegen und den Stick in einen freien USB-Port einsetzen. Soweit beschreibt die Anleitung das Procedere wie zu erwarten war. Die Vodafone Mobile Connect Card UMTS war nun im OSX eingebunden - aber wie stelle ich eine Verbindung via WebSessions her?
Dazu fand ich auf der Seite "Installationshinweise zu Websessions" den Link zum Dokument: "Anleitung: Vodafone WebSessions mit Apple-Notebooks nutzen". Genau das, was ich gesucht habe - aber leider steht auf der ersten Seite in fett: "Hinweis: Diese Anleitung gilt nicht für Apple MacBook Pro Notebooks mit Intel-Prozessor." - boom - und leider gibt es auch keine Info, wo ich als MacBook Pro Nutzer denn eine alternative Dokumentation finde. Ich habe auf den Vodafoneseiten auch nichts gefunden... Daher habe ich mich weitestgehen an diese eigentlich für meinen Anwendungsfall nicht gültig Anleitung gehalten und APN auf event.vodafone.de umgestellt. Bei den Custom Connection-Settings habe ich noch auf "DE VodafoneD2 Websessions" umgestellt. Die unter Punkt 11 gezeigten Screenshots gelten so nicht mehr für Leopard. Die Angabe von Account-Name und Kennwort sind auch nicht erforderlich. Über die Systemeinstellungen/Netzwerk ist dann über den vom Dashboard erstellten Eintrag "Vodafone" eine Verbindung ins Internet über die Default-Configuration möglich. Der Requet einer beliebigen URL im Browser führt zur WebSessions-Seite so dass man das gewünschte Pakete buchen kann.
Aus meinem Büro heraus bekomme ich immerhin Werte die sogar leicht über meinem ehemaligen DSL Anschluss liegen:
Zum Vergleich dazu mein ehemaliger DSL-Anschluss:
Das ist sogar als Backup-Lösung für meine Kabel-Deutschland-Anbindung ausreichend.
Was noch etwas nervt ist die Komprimierung aller Bilder die Vodafone vornimmt - irgendwie soll man das über den Vodafone HighPerformance Client abstellen können. Ein Hinweis besagt: "Im Vodafone Dashboard ist der HighPerformance Client bereits integriert." - aber entsprechende Einstellungsmöglichkeiten habe ich - bei der Mac-Version - bisher nicht entdeckt.
Skalieren mit Amzon EC2 und S3
Posted by Lars Schenk in tech-recipes on Dezember 11th, 2007
Jonathan Weiss zeigt in seinem Blog eine überarbeitete Version seines Vortrags zur Skalierung vom Ruby on Rails Apps mittels Amazon EC2 und S3.
Eine etwas älteres Video von seinem Vortrag (mit zum Teil überholten Aussagen, siehe hier und hier), welches aber dennoch wirklich ansehenswert ist, gibt es unter: www.loromoar.com.
Jonathan stellt im Slide 34/35 "EC2 for extra capacity" ein optionales Model vor, bei dem für die DB und den Loadbalancer ein Inhouse-Lösung angetrebt wird (Eigens RZ oder klassischer Hoster). Die Gründe dafür deutet er auch schon im Video an (welches dieses Modell noch nicht zum Gegenstand der Diskussion gemacht hatte): EC2 hat kein persistentes Speichermedium. Fällt die Instanz aus, gehen die Daten verloren. Wenn nicht konstant dedumpt und auf S3 gesichert wird, droht Datenverlust.
Ich fürchte jedoch das gerade bei RoR-Anwendungen recht komplexe und viele SQL Abfragen entstehen, so das sich eine erhöhte Latenz zwischen den Application-Servern die unter EC2 laufen und der Datenbank, die inhouse läuft sehr negativ auf die Antwortzeiten auswirken könnte. Ich würde daher lieber die DB@EC2 belassen und das Verlustrisiko von Daten minimieren indem eine Replikation (Slave) in eine oder mehrere EC2 Instanzen oder auch auf einen Slave im eigenen RZ gemacht wird. Der Vorteil dabei ist, dass die Application-Server kürzere Latenzzeiten zur DB haben und der Traffic innerhalb EC2 bleibt und somit auch kostenlos ist. Fällt die Master-DB aus, so kann ein Slave die Aufgabe übernehmen.
Das Argument den Loadbalancer Inhouse zu nehmen ist, dass beim Ausfall des EC2 basierten Loadbalancers eine neue IP zugewiesen wird und es somit zur vorübergehenden Unerreichbarkeit kommen kann, wenn DNS-Server die Updates nicht rasch genug verarbeiten. Steht der Loadbalancer hingegen im eigenen RZ oder beim klassischen Hoster habe ich eine statische IP und kann das Problem (eher) umgehen, so dass keine DNS-Update erforderlich wird.
Aber man erkauft sich diesen Vorteil zum einen durch mehr Latenzzeit: der Loadbalancer muss nun alle Requests erst an die weit entfernten EC2 Instanzen weiterreichen und auf deren Antwort warten. Der Weg von den Clients zum Loadbalaner kommt in diesem Fall dann noch hinzu. Hier kann es sich dann schon lohnen über eine Proxy/Cash-Lösung nachzudenken. Was aber ebenfalls noch zu berücksichtigen ist: Ich habe nun zwei mal den Traffic zu bezahlen: Einmal zwischen EC2 und dem Loadbalancer und hinzu dann noch der Traffic zwischen dem Loadbalancer und den Clients.
Also auf den ersten Blick würde ich den Loadbalancer doch lieber auch bei EC2 einsetzen...
Ein recht radikaler aber genialer Ansatz ist der Verzicht auf einen dedizierten Loadbalancer.
Lei Zhu beschreibt in seinem Aritkel wie man das Problem mit der dynamischen IP lösen kann indem man ganz auf einen Loadbalancer verzichtet und das Konzept und die Aufgabe des Loadbalancers gleich auf den Client überträgt: Client-Side Loadbalancing!
Zum Slide: Read the rest of this entry »
Latest comments