Marcel Eichner // Ephigenia

  • Home
  • Illustration
  • Code
  • Kontakt

Aktuelle Projekte

Horrorblog.org
jQuery.slideShow
Franklin
code.marceleichner.de

This Blog-Website is built with Harrison!

Blogs & Freunde

Gimmixx
Martin Fleck
Torsten Bergler
Jens Franke
Robokid
Peter Kröner
Polycoder
Coding Horror
Lotterliebe
CodeBalancer
Pseudocoder
Migrador
Dachdeckermeister Peter Arold in Werda, Plauen, Hof und Umgebung La Petite Provence - Pension und Festsaal in Leisnig Piv-Berlin, Immobilienverwaltung Verwaltung Berlin blogoscoop

#507

04.07.2011 19:51
0 Kommentare
Share
  • php
  • apache
  • gd-lib
  • image
  • server
  • nginx
  • static
  • content
  • delivery
  • .htaccess
One problem when relaunching large projects with a ton of images is to re-create all the thumbnails that users have uploaded in the years. If you don’t use paperclip (ruby) or anything like it in PHP (is there any like it!?) where you can run run one command to re-create all the thumbnails in all specified sizes your can try to keep it flexible and create every image on demand.

Theory

The Webserver should serve the image if it exists. If the file does not exist, the request should be redirected to a PHP script that searches and creates the requested image file (in requested size) at exactly the location it was originally requested. The second request on the file will not be redirected to the PHP script and will server the image that now exists.

Practice

So the first thing to archive is to send the request of a not existing image to a PHP file. That’s easy if you’re familiar with all the nginx directives:

This rule can be combined with the anti-hotlinking rules for images with nginx I showed you last week.

After that we need to create a format that includes width and height of any requested image so that the
thumbnailer.php
knows which size the created image should have. A valid request for a resized file should always have all parameters (width, height) in it:
../img/public/9c4be029/438xauto/filename.jpg

This makes it easy to split up width, height with a regexp in
thumbnailer.php
. The following code is just an example. You’re surelly integrate the logic into your frameworks:

That’s it! After that you can request any image in any size on your webserver by only creating it once it’s requested.

There are some things you can add, like other parameters in the
$formatRegexp
string to add different resizing methods or even filters, or limitations on the
width
and
height
parameter.

Appendix: Apache

It’s almost the same thing with apache. Just add a few lines to your
.htaccess.
and all your image requests are redirected to the thumbnailer (or anything):

#506

28.06.2011 11:16
0 Kommentare
Share
  • config
  • facebook
  • server
  • nginx
  • hotlinking
  • referer
  • block
  • how-to
Almost two weeks ago I moved my personal blog-project horrorblog.org from a domainfactory managed hosting server to a JiffyBox which is a scalable cloud server solution also by domainfactory. I won’t talk about the setup for now (but later this or next week) but I want to show you an example for a nginx config file that prevents your images from beeing hotlinked but still enabling google and facebook.

Prevent hotlinking in nginx is really simple and some rules and examples can be found via google:
# apply this rule on any location that’s an image using Regexp
location ~* \.(png|gif|jpg|jpeg|swf|ico)(\?[0-9]+)?$ {
  # block empty blocked or whiteliste referers
  valid_referers none blocked horrorblog.org www.horrorblog.org;
  if ($invalid_referer) {
    return 403;
  }
}

This works fine, unless you won’t have your images displayed on facebook when anybody likes your stuff with the facebook share button (og:image) or in google image search. The solution that enables facebook to grab the images from your host is by adding
~\.facebook\.
and
~\.fbcdn\.
to the whitelist of hosts:
# apply this rule on any location that’s an image using Regexp
location ~* \.(png|gif|jpg|jpeg|swf|ico)(\?[0-9]+)?$ {
  # block empty blocked or whiteliste referers
  valid_referers none blocked horrorblog.org www.horrorblog.org ~\.google\. ~\.yahoo\. ~\.bing\. ~\.facebook\. ~\.fbcdn\.;
  if ($invalid_referer) {
    return 403;
  }
}

#498

04.06.2010 12:39
3 Kommentare
Share
  • code
  • script
  • bash
  • shell
  • apache
  • benchmark
  • ab
In einem aktuellen Projekt steht bald ein signifikanter Server-Wechsel an. Um später genau sagen zu können, was das gebracht hat, wollte ich mehrere Teile der Website (verschiedene URIs) mit dem Apache Tool ab zu verschiedenen Tageszeiten, einmal vor Wechsel des Servers und nach Wechsel des Servers, testen. Da ich nicht viel Zeit verschwenden wollte, hab’ ich ein Shell-Script geschrieben das mir wenigstens die Arbeit abnimmt die verschiedenen URIs abzuchecken:
#!/bin/bash
##############################################################################
# Run ab on a list of URIs
#
# Usage:
#   ab_batch.sh
#
# Author: Marcel Eichner // Ephigenia <love@ephigenia.de>
# Date: 2010-06-03
##############################################################################
URL="http://www.horrorblog.org"
SLEEP=30
URIS=(
  "/"
  "/blog/reca-drei-clips-und-red-band-trailer/"
  "/blog/the-crazies-remake-horrorblog-kritik/"
  "/blog/the-crazies-interview-clips/"
  "/blog/the-devils-playground-erste-bilder/"
  "/blog/a-nightmare-on-elm-street-remake-horrorblog-kritik/"
)
date
echo -e "Batch Apache-Benchmarking on n${URL}"
for URI in ${URIS[@]};
do
  echo "uri: ${URI}"
  ab -c 10 -t 60 "${URL}${URI}" | grep -P "(request|second):"
  sleep ${SLEEP}
done

Das liefert dann zum Beispiel folgendes Ergebnis. Die Werte kann man dann in eine Tabelle übertragen und ein Diagram draus machen. Nach dem Server wechseln dann das ganze noch einmal durchführen und schon hat man einen schönen Beweis was der Umzug denn gebracht hat.
Fr  4 Jun 2010 12:15:54 CEST
Batch Apache-Benchmarking on
http://www.horrorblog.org
uri: /
Finished 349 requests
Requests per second:    5.57 [#/sec] (mean)
Time per request:       1794.754 [ms] (mean)
Time per request:       179.475 [ms] (mean, across all concurrent requests)
uri: /blog/reca-drei-clips-und-red-band-trailer/
Finished 588 requests
Requests per second:    9.79 [#/sec] (mean)
Time per request:       1021.170 [ms] (mean)
Time per request:       102.117 [ms] (mean, across all concurrent requests)
uri: /blog/the-crazies-remake-horrorblog-kritik/
Finished 407 requests
Requests per second:    6.78 [#/sec] (mean)
Time per request:       1474.255 [ms] (mean)
Time per request:       147.425 [ms] (mean, across all concurrent requests)
uri: /blog/the-crazies-interview-clips/
Finished 397 requests
Requests per second:    6.60 [#/sec] (mean)
Time per request:       1514.682 [ms] (mean)
Time per request:       151.468 [ms] (mean, across all concurrent requests)
uri: /blog/the-devils-playground-erste-bilder/
Finished 331 requests
Requests per second:    5.50 [#/sec] (mean)
Time per request:       1816.657 [ms] (mean)
Time per request:       181.666 [ms] (mean, across all concurrent requests)
uri: /blog/a-nightmare-on-elm-street-remake-horrorblog-kritik/
Finished 506 requests
Requests per second:    8.43 [#/sec] (mean)
Time per request:       1185.792 [ms] (mean)
Time per request:       118.579 [ms] (mean, across all concurrent requests)

Für Verbesserungsvorschläge bin ich wie immer offen! Kommentiert einfach!

#493

07.03.2010 18:53
0 Kommentare
Share
  • code
  • wordpress
  • php
  • deploy
  • local
  • programmieren
  • tutorial
  • url
  • permalinks
  • config
Ich hab ja in letzter Zeit mal sporadisch mit dem wunderbaren Wordpress zu tun gehabt und konnte mich eine Weile damit beschäftigen. Viele Sachen gefallen mir nicht, unter anderem die Tatsache das Wordpress URLs immer komplett haben muss. Wie soll ich bitte lokal entwickeln wenn alle URLs komplett sind?

Dem lässt sich zum Glück relativ einfach abhelfen. Man legt sich einfach eine wp-config.php Datei an die man nur benutzt wenn man lokal entwickelt. Das kann man zum Beispiel am username im System festmachen:
$envUsername = strtolower(get_current_user());
$envConfigFilename = dirname(__FILE__).'/wp-config-'.$envUsername.'.php';
if (file_exists($envConfigFilename)) {
  require $envConfigFilename;
}

Und dann kann man in der lokalen Konfigurations-Datei einfach den Wordpress-Installationspfad überschreiben:
define('WP_HOME','http://'.$_SERVER['HTTP_HOST'].'/wordpress/path/');
define('WP_SITEURL', WP_HOME);

So hat man zumindest damit keinen Stress mehr. Wie man die Bilder lokal verlinkt weiss ich allerdings auch noch nicht …

#490

22.11.2009 21:33
0 Kommentare
Share
  • Web
  • osx
  • virtual
  • box
  • google
  • os
  • preview
  • test
  • screenshots
Das Horrorblog in Chrome OS
Letzte Woche Freitag Nacht wurde von Google der Source Code aka Quellcode zu deren Online-Betriebssystem Chrome OS released. Ein paar Videos und noch mehr Infos gibt’s in dem dazugehörigen Blog-Post im Chrome-Blog.

Wer es drauf hatte auf Ubuntu seinen eigene Version zu compilieren kann sich glücklich schätzen und kennt sich wahrscheinlich gut damit aus. Ich musste mich mit dem Versuch begnügen das ganze mit einem Festplatten-Image von GDGT in Virtual Box (3.0.12 r54655) auf Snow Leopard (10.6.2) zum Laufen zu bekommen. Nachdem ich den Netzwerkadapter auf Desktop umgestellt habe, Linux - Ubuntu - Other Linux wie in der Anleitung angegeben hatte zeigte sich auch endlich der Login-Screen! So, jetzt noch die Tücken der englischen Tastatur besiegen und nachdem das "z" im Passwort auch hübsch als "y" auf der Tastatur eingegeben wurde komm ich auch mit meinem Google Account rein! (Manchmal geht das wohl nicht weil die Server überlastet waren?)

Ja, wie ist es? Ganz nett - es kann noch nich’ viel, alles läuft quasi im "Browser". Das Schachspiel das man schon gesehen hat vielleicht läuft in Flash und ich glaube nativ installiert, auf einem Netbook, ist Chrome OS superschnell! Frisch hochgefahren mit 3 Fensterchen offen, verbrauchte Chrome OS nur ca. 50MB!

Ich bin gespannt wie das fertige System aussehen wird. In einem Jahr wird sich ja hoffentlich noch viel Ändern und noch mehr "Programme" geboten werden. Zum Websites-Testen braucht man Chromium auf jeden Fall nicht - da reicht auch der Chrome-Browser.

#463

19.06.2009 10:45
0 Kommentare
Share
  • code
  • osx
  • test
  • terminal
  • tool
  • apache
  • siege
  • unix
  • webserver
  • benchmark
  • performance
  • regression
Wie gestern schon beschrieben kann man super ab (Apache Bench) die Performance seiner Applikationen im Web testen. Durch Zufall hab ich in meiner Ports Sammlung noch ein anderes Programm gefunden das auch sehr vielversprechend aussieht: siege.

Dort kann man auch mehrere URLs testen, einen User simulieren und noch viel mehr. Damit habe ich allerdings noch nicht so viel Erfahrung. Hab aber gleich mal meine App getestet:
siege -c 100 -t 10s http://localhost/myProject/
Die Ausgabe sieht fast so aus wie beim ab:
Transactions:                    545 hits
Availability:                 100.00 %
Elapsed time:                  17.85 secs
Data transferred:               1.33 MB
Response time:                  1.02 secs
Transaction rate:              30.53 trans/sec
Throughput:                     0.07 MB/sec
Concurrency:                   31.01
Successful transactions:         604
Failed transactions:               0
Longest transaction:            3.31
Shortest transaction:           0.03

Mit einem Config File kann man aber auch noch mehrere Urls abfragen und so ein realistischeres Ergebnis erzielen. Mehr dazu steht in der Docu von Siege oder in Tutorials die man so im Netz findet: Regression testing with Siege.

Ich denke mal das solche Tools auch eine wunderbare Möglichkeit sind verschiedene Hoster zu testen oder einem Kunden zu zeigen wie Vorteilhaft eine Optimierung seiner Applikation wäre oder einfach nur welchen extremen Effekt der Einbau eines Caches hat.

#462

18.06.2009 13:37
2 Kommentare
Share
  • code
  • php
  • osx
  • test
  • framework
  • terminal
  • shell
  • apache
  • unix
  • benchmark
  • performance
  • port
Wer sich mit Websiten beschäftigt die von mehr als 100 Besuchern am Tag besucht werden und nicht wirklich viel im Terminal macht freut sich eventuell über Apache Bench.

Das ist ein Programm das man auf OSX ganz einfach im Terminal laufen lassen kann um seinen Server mal so richtig schwitzen zu lassen.

Ein üblicher (und auch vergleichbarer) Aufruf ist der folgende:
ab -c 10 -t 60 http://localhost/myProject/
Was 60 Sekunden lang, immer 10 Requests auf die Seite abfeuert und einem danach folgende Ausgabe generiert:
Finished 3102 requests
Server Software:        Apache/2.0.59
Server Hostname:        localhost
Server Port:            80
Document Path:          /myProject/
Document Length:        2005 bytes
Concurrency Level:      10
Time taken for tests:   60.002 seconds
Complete requests:      3102
Failed requests:        303
   (Connect: 0, Receive: 0, Length: 303, Exceptions: 0)
Write errors:           0
Total transferred:      7530897 bytes
HTML transferred:       6211149 bytes
Requests per second:    51.70 [#/sec] (mean)
Time per request:       193.431 [ms] (mean)
Time per request:       19.343 [ms] (mean, across all concurrent requests)
Transfer rate:          122.57 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.2      0      11
Processing:    30  186 663.6    157   20630
Waiting:        0  161  83.6    155     621
Total:         30  187 663.6    157   20631
Percentage of the requests served within a certain time (ms)
  50%    157
  66%    196
  75%    219
  80%    235
  90%    276
  95%    309
  98%    354
  99%    386
 100%  20631 (longest request)
In dieser Ausgabe kann man erkennen das das aktuelle Projekt so ca. 50 Leute gleichzeitig aushalten könnte. Im vergleich mit anderen Projekten kann man dann Rückschlüsse darauf ziehen wie gut man programmiert hat ;-)

Viele benutzen ab auch zum Vergleich von verschiedenen Frameworks die ich euch natürlich nicht vorenthalten möchte: Test1, Test2 und Test3.

ab kann man wie üblich über macports installieren (OSX Developer Tools müssen installiert sein):
sudo port install ab

#457

05.06.2009 13:49
0 Kommentare
Share
  • code
  • osx
  • App
  • terminal
  • tool
  • script
  • scripting
  • apple
iTerm ist eine willkommene Alternative zu der nativen Terminal App für OSX. Jetzt kann man die auch mit AppleScript verwursten.
Wenn man es Leid ist immer wieder die selben Terminal Fenster aufzumachen um Apache-Logs zu lesen oder die Datenbank zu überwachen sollte man überlegen ob das nicht noch besser geht. Klaro geht das besser! Mit Apple-Script!
tell application "iTerm"
  activate
 
  -- create server log terminal
  make new terminal
  tell the last terminal
    activate current session
    launch session "Default Session"
    tell the last session
      write text "clear;"
      write text "tail -f /Applications/MAMP/logs/apache_access.log"
      set background color to {15000, 200, 200}
    end tell
  end tell
  set the bounds of the first window to {0, 700, 840, 900}
  set the name of the first window to "apace_access.log"
 
  -- creat working terminal
  make new terminal
  tell the last terminal
    activate current session
    launch session "Default Session"
    tell the last session
      write text "welcome user, start now"
    end tell
  end tell
  set the bounds of the first window to {0, 0, 840, 660}
  set the name of the first window to "workspace"
 
end tell
So kann man ganze Fenster Setups zusammencoden und erspart sich so hoffentlich einen Haufen Zeit.

Nachtrag:
Man kann dann das Apple-Script auch automatisch bei jedem Start von iTerm ausführen lassen indem man es in ~/Library/iTerm/AutoLaunch.scpt ablegt. Weitere Beispiele gibt es auf der Scripting Seite von iTerm.

#448

30.03.2009 17:47
0 Kommentare
Share
  • code
  • deploy
  • programmieren
  • osx
  • terminal
  • script
  • shell
  • apple
  • server
  • rsync
Ein weiterer Vorteil von mediatemple Servern ist, dass man per rsync und ssh einfache Projektupdates schieben kann.

Ich arbeite an den meisten Projekten, wie auch diesem Blog, lokal auf meinem Rechner und habe bisher immer mit Transmit syncronisiert. Da Transmit aber reichlich beschränkt ist, was die Einstellungsmöglichkeiten betrifft und mein PHP-FTP Sync Programm nicht 100% alle Features abdeckt die rsync abdeckt habe ich mich damit mal beschäftigt.

Sobald man einen ssh Zugang zu seinem Mediatemple server hat kann man mit nur einer Zeile in der Console sein komplettes Projekt updaten - in Windeseile!

rsync -avzcu --cvs-exclude --progress [localDir] -e ssh [host]:[remoteDir] --exclude-from deployIgnore.txt
Die mit eckigen Klammern umklammerten Sachen müsste man dann einfach durch eigene Werte ersetzen.

#438

16.01.2009 15:27
0 Kommentare
Share
  • terminal
  • bash
  • ssh
  • svn
  • hook
  • commit
Ich bin seit dem letzen Jahr erfolgreich und glücklich auf einem Mediatemple Server.
Man kann dort unter anderem auch echt supertoll seine eigenen SVN Repositories anlegen. Das hab ich bei noch keinem deutschen Hoster gesehen für das Geld.

Seit heute hab ich es auch endlich hinbekommen einen sog. SVN-Hook einzurichten. Ich hab dazu leider nichts richtiges im Netz gefunden und musste ein wenig rumprobieren. Es geht nämlich so:
cd svn-repo/hooks
cp post-commit.tmpl post-commit
chmod +x post-commit
Und dann brauch man nur noch die post-commit mit dem editor seiner Wahl editieren:

/usr/share/subversion/hook-scripts/commit-email.pl "$REPOS" "$REV" --from absender@host.tld  -s "Custom Subject" empfaenger@host.tld

Die mailer.py und mailer.rb variante die es bei tigris gibt sind viel hübscher, funktionieren aber irgendwie bei MT nicht :(
  • 1
  • 2
  • weiter »
marceleichner HTML5 Harrison Theme (Validate Source), © 2010 by Ephigenia M. Eichner, Impressum