Expires Header Wie wir alle wissen kann man die größten Performanceverbesserungen auf der Browserseite erreichen. Ich habe bereits das Zusammenfassen von CSS- und Javascript-Dateien vorgestellt, ebenso wie das Zusammenfassen von Bildern in CSS-Sprites. Damit wird die Anzahl der Request schonmal reduziert. Aber es gibt natürlich noch mehr zu tun, beispielsweise die Requests noch weiter reduzieren durch gute Cache-Einstellungen, die wir an den Brower senden. Cache-Einstellungen werden via HTTP-Header an den Browser mitgesendet. Damit die unten stehenden Anweisungen vom Apache interpretiert werden können muss man das “Expires-Modul” aktivieren, häufig kann man das wie folgt erledigen: Hier die entsprechenden Apache-Einstellungen, die man entweder global im Apache einstellen kann, oder im entsprechenden vhost der Domain oder aber in der .htaccess-Datei speziell für Ordner: Mit dem Firefox-Addon Firebug kann man sich das Ergebnis anschauen:
List of PHP accelerators This is a list of PHP accelerators. Alternative PHP Cache (APC)[edit] Alternative PHP Cache is a free, open source (PHP license) framework that caches the output of the PHP bytecode compiler in shared memory, thus reducing parsing and disk I/O overhead for later requests; and a shared memory cache for user data. For an application consisting of a large source code base such as Drupal, a 3x increase in page generation speed is possible as a result.[1] It has been used at Facebook and has a mature codebase thanks to numerous contributors, including Facebook itself.[2] APC was originally scheduled for inclusion into the PHP core no later than PHP 6.[3] While multiple accelerator projects were considered desirable,[4] the focus has since moved to Optimizer Plus[5][6] which is included in the core distribution as of PHP 5.5. eAccelerator[edit] eAccelerator was born in December 2004 as a fork of the Turck MMCache project. ionCube PHP Accelerator[edit] Only supports PHP 4. Turck MMCache[edit]
Rack::Cache Rack::Cache is suitable as a quick drop-in component to enable HTTP caching for Rack-based applications that produce freshness (Expires, Cache-Control) and/or validation (Last-Modified, ETag) information. Standards-based (see RFC 2616 / Section 13).Freshness/expiration based cachingValidationVary supportPortable: 100% Ruby / works with any Rack-enabled framework.Disk, memcached, and heap memory storage backends. News Rack::Cache 1.0 was released on December 24, 2010. Installation $ sudo gem install rack-cache Or, from a local working copy: $ git clone $ rake package && sudo rake install Basic Usage Rack::Cache is implemented as a piece of Rack middleware and can be used with any Rack-based application. require 'rack/cache' use Rack::Cache, :verbose => true, :metastore => 'file:/var/cache/rack/meta', :entitystore => 'file:/var/cache/rack/body' run app More See Also Rack::Cache takes (liberally) various concepts from Varnish and Django’s cache framework.
Creating Your Own CMS Part 1 - Secure Login Have you ever built a site to realize it is a pain to manage? There are a lot of CMS options out there but some of them cost money, some are hard to learn, some your hosting company might not support, and well sometimes they just don’t have everything thing that you want. So today I am going to start to teach you how to create your own simple CMS. Today I will get into how you can find a design and get your secure login setup. This will be a series of blogs but to be honest I am not sure how advanced I will be going. Design of Your Own CMS This may or may not be important to you. Here is the one that I chose as well as a few others to browse through. I am creating this CMS as I type this so you guys are looking at it first hand. A Few Things To Have Before You Begin the Login If you haven’t already setup the database then you can refer to one of my recent posts “Getting Started With MySQL DB and PHP with PHPMyAdmin”. Most of this layout is pretty self-explanatory. Secure Login Code
NGINX + PHP-FPM + APC = Awesome The following guide will walk you through setting up possibly the fastest way to serve PHP known to man. If there is a faster way, I’ve not yet found it climbing through zillions of blog posts out there on the subject. In this article, we’ll be installing nginx http server, PHP with the PHP-FPM patches, as well as APC. The end result? Pure awesome. Some Background For the last 2+ years, we’ve been running Apache with mod_php at Massify . It’s a pretty well know fact by now that Nginx (pronounced engine-x, though I call it n-jinx) in typical scenarios outpaces Apache on all kinds of fronts: i/o, cpu, memory, reqs/sec. The typical nginx configuration involves using from the LightTPD project to get nginx serving up PHP. Enter PHP-FPM , which stands for PHP FastCGI Process Manager. Note: Even if you are sticking with Apache, there are a variety of reasons to skip mod_php and go straight for PHP via FastCGI. Let’s Get Rocking We’re using a fresh install of Ubuntu 8.10 Intrepid. Compile PHP #!
Caching with Rails: An overview 1 Basic Caching This is an introduction to three types of caching techniques: page, action and fragment caching. Rails provides by default fragment caching. To start playing with caching you'll want to ensure that config.action_controller.perform_caching is set to true, if you're running in development mode. 1.1 Page Caching Page caching is a Rails mechanism which allows the request for a generated page to be fulfilled by the webserver (i.e. 1.2 Action Caching Page Caching cannot be used for actions that have before filters - for example, pages that require authentication. 1.3 Fragment Caching Life would be perfect if we could get away with caching the entire contents of a page or action and serving it out to the world. Fragment Caching allows a fragment of view logic to be wrapped in a cache block and served out of the cache store when the next request comes in. and you can expire it using the expire_fragment method, like so: You can also use an Active Record model as the cache key: Feedback
Eine kleine MySQL-Referenz (PHP-Tutorial) Vorwort Diese "Referenz" zeigt nur die allerwichtigsten MYSQL-Befehle. Für eine ausführlichere Referenz empfehle ich die PHP-Referenz. Viele dieser Befehle sind ähnlich den ODBC-Befehlen aufgebaut. Ist Voraussetzung in jedem PHP-Programm, das MySQL benutzen will. Mit MySQL_Connect wird meist auch gleich die Datenbank der Wahl ausgewählt; dies geht mit mysql_select_db(...) und ist deshalb hier gleich mit-erwähnt. mysql_connect('localhost') OR DIE ("Konnte nicht mit MySQL verbinden."); @mysql_select_db("datenbankname") OR DIE ("Konnte nicht mit Datenbank auf MySQL verbinden Hinweis: OR DIE (String) lässt den Programmablauf mit der Meldung String abbrechen falls das Ergebnis der vorangegangenen Operation false war. Schließt die Verbindung zu MySQL und ist am Ende jedes Programmes, das auch MYSQL_CONNECT benutzt hat, aufzurufen. mysql_close(); führt eine SQL-Anweisung aus. mysql_query ("insert into kueche values ('Messer')"); führt eine SQL-Anweisung auf Datenbank aus. siehe MYSQL_DB_QUERY-Beispiel.
Wordpress Performance Comparison: Using Nginx, Apache, APC and Varnish in Different Scenarios Wordpress Performance Comparison: Using Nginx, Apache, APC and Varnish in Different Scenarios Written by Guillermo Garron . Date: 2012-04-27 22:17:39 +0000 Introduction If you follow this blog, you may already know that I’m somehow obsessed with performance. I like to try to squeeze every drop of power from a server before upgrading it. This time, I’ve been playing with Wordpress and a Small VPS server. 512 MB RAM Shared CPU Shared Disk Arch Linux 32 Bits It is the smallest Linode available by the time of this writing. I’ve tested Wordpress on different possible configurations: Apache, PHP, MySQL Standard Apache, PHP, MySQL and APC Nginx, PHP-FPM, MySQL Nginx, PHP-FPM, MySQL and APC Nginx, PHP-FPM, MySQL, APC and Varnish Apache, PHP, MySQL, APC and Varnish I’ve used the standard Wordpress installation, with no extra plugins installed, not even Total Cache or Super Cache. Full configurations facts can be found at: Increase Wordpress performance The tests The results Apache + PHP + APC Conclusion
Seven Advanced Rails Fragment Cache Techniques | CRAZ8 Blog The Rails Fragment Cache is the easiest way of making your view template code run fast. A fragment is a piece of generated output, usually HTML, that is a part of the total output, usually the HTML page, that is returned to a user. The documentation on caching with Rails explains the basics, but doesn’t go into any depth, especially for new use cases and techniques that have been developed and expanded over the last year or so. Here are six techniques and tools that can make your fragment caching easy to manage yet provide the benefits of turbo-charging your view rendering. Don’t Expire Fragments using expire_fragment Frankly, don’t use this. Expire by time If you are using a memcache store for your Rails cache store - and your really should be - then you have the option of expiring fragments by time. <% cache @post, :expire_in => 2.hours %><%= render @post %><% end %> For some use cases, this technique is very useful. Generational (or Key) Expiry Advanced Generational Expiry Summary