CakePHPのアプリをスピードアップする8つの方法 - 忍び歩く男 - SLYWALKER
8 Ways to Speed Up CakePHP Apps | PseudoCoder.com 上記に記載されてます。 前置きとして、ContainableBehaviorを使用して最適化してあり、SQLのIndexも適切に設定された上でとのこと 1.デバッグの設定は0で 2.遅いクエリやWEBサービスのリクエスト他、はキャッシュしよう 3.Viewをキャッシュしよう 4.HTMLをキャッシュしよう 5.APCを使おう 6.Persistent Models your controller (or AppController) に以下を加える <?php var $persistModel = true; ?> 7.Persistent CacheをAPCにStore core.php <?php Cache::config('_cake_core_', array('engine'
PHP: ob_gzhandler - Manual
Getting Started Introduction A simple tutorial Language Reference Basic syntax Types Variables Constants Expressions Operators Control Structures Functions Classes and Objects Namespaces Enumerations Errors Exceptions Fibers Generators Attributes References Explained Predefined Variables Predefined Exceptions Predefined Interfaces and Classes Predefined Attributes Context options and parameters Su
ウノウラボ Unoh Labs: PHPで書かれたwebサービスを高速化する2
前回のエントリPHPで書かれたwebサービスを高速化するでは高速化のレベルのうち、最初の2段階「ハードウェアによる高速化」「ソフトウェアによる高速化」について書きました。 今回は第2弾として「プログラムの工夫による高速化」について書きたいと思います。 - DBへのアクセスは自分で抽象化する DBへのアクセスを高速化するためには、チューニングを行ったり複数台構成にするわけですが、 広く使われているPear::DBとかadodbは複数台構成のDBに接続することを考慮されていません。 Pear::DBやadodbはバックエンドに使って、ラッパークラスを作るようにしましょう。 - 更新系クエリと読み出し系クエリのユーザを分ける これは高速化とは関係ないんですが、ぜひ実行してもらいたいので書きました。 複数台構成のサーバにアクセスするときは更新系クエリはマスターに発行して、 読み出し系クエ
ITmedia エンタープライズ：LAMP vs. LAMP──mod_perlとmod_phpのパフォーマンス比較
MySQLテストでは、5000件のレコードを含むテーブルを読んで更新するHTTPリクエストを1つ実行した。MySQLとのやり取りには、標準PHPインタフェースとPerl DBIを使った。テストに使ったテーブルの構造は次のとおり。 +----------+----------+------+-----+--------+----------------+ |フィールド| タイプ | Null |キー | 既定値 | そのほかの特性 | +----------+----------+------+-----+--------+----------------+ | id | int(11) | | PRI | NULL | auto_increment | | junktext | char(30) | 可 | | NULL | | +----------+----------+------+
Do You PHP はてな - oci_pconnectの第4引数を指定するとパフォーマンス向上
Oracle9.2以降を使っている場合、oci_pconnectの第4引数にキャラクタセットを指定できます（9.2以前の場合、環境変数NLS_LANGが使われる）が、このパラメータを指定すると、パフォーマンスが向上するとのこと。 I used AL32UTF8 which is the character set of the Oracle XE "Universal" database I have. Testing with the database and PHP both on my little old machine I was getting figures like 0.6 vs 2.7 seconds for 50,000 pconnect calls in the one script. I saw some other results that showed only
ページの読み込みを早くするもう20個のtips – 秋元
PHPケベックカンファレンスでYahoo!の人が発表した資料が公開されていますね。 YSlowでチェックできる14個のルールに加えて、あらたに20個のチェックポイントが解説されています。カテゴリごとにわかれているのを要約するとこんな感じ。 サーバ 早めのフラッシュ AjaxにはGET コンテンツ 遅延読み込み 次回以降のための先行読み込み DOM要素を減らす 複数、しかし4個以下のドメインから並行読み込み iframe個数削減 404エラーをなくす クッキー Cookieサイズを最小に Cookieを使わないドメインでのホスト分割 Javascript DOMアクセス最小化 イベントハンドラの改善 CSS @importじゃなく<link> IEのフィルタは避ける 画像 画像の軽量化 GIFをPNGに、PNGの圧縮、JPEG内のコメント削除 CSSスプライトの効率化 表示サイズ以上の画像を
PHP コード最適化 Best Practices 63+ - カタコト日記
みたいなタイトルの記事を Digg 経由で発見。チートシート代わりにと思い超訳。*1 A Software Architect PHP 最適化 ベストプラクティス！ 01. static にできるメソッドは static として宣言しよう。（4倍速い） 02. echo の方が print より速い。 03. echo '文','字'; （カンマ区切り）の方が、'文'.'字' （ドット連結）より速い。 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。 05. 大きい配列のような変数は unset() してメモリを解放しよう。 06. マジックメソッド（例： __get, __set, __autoload）は使用を避けよう。 07. require_once はハイコストなのです。 08. include や require でファイルはフルパスで指定しよう。 09
勉強会「快適なwebアプリケーション構築のための基礎知識 増えていく負荷とサーバと機能に どう向き合うかの巻」を開催しました
こんにちわ。arashoです。 表題の件で勉強会「快適なwebアプリケーション構築のための基礎知識 増えていく負荷とサーバと機能に どう向き合うかの巻」を開催しました。 今回はwebサーバ、DBサーバを増やして、インフラを構築・拡張していく場合、 インフラとアプリケーションは互いに強力しあわなければいけないんだよ 一つの問題の解決に対して解は複数あって、メリット・デメリットを比較して判断しないといけないんだよ と言うことを伝えたかったのですが、伝わっているといいのですが...。 とりあえず公開します。 使用したスライド
Twitterがスケールに苦しむ理由 - スケールするサイトのアーキテクチャ考
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
大規模SNSのボトルネックとソリューション
SNSは比較的データアクセスが多いアプリケーションであり、負荷対策が難しい部類に入る。本稿では、グリーCTOの藤本真樹氏が、GREEというSNSでの経験を基に、SNSの具体的な負荷軽減ソリューションを紹介する。 はじめに 昨今では、地方自治体や企業内でもSNSを導入する動きが活発化しているようです。しかし、SNSは比較的データアクセスが多いアプリケーションであり、負荷対策が難しい部類に入ります。そこで本稿では、前回お届けした「大規模SNS実現のためのGREEのアプローチ」の内容からもう一歩踏み込んで、GREEというSNSでの経験を基に、SNSの具体的な負荷軽減ソリューションを紹介します。 SNSのボトルネック 一定以上のユーザー数、データ量、そして機能を持つSNSでは、普通に構築していくと非常に悩ましいボトルネックが2つ顕在化してきます。1つは、「友達の新着」系の情報取得です。もう1つはア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
