タグ

高速化に関するtomotaka-itoのブックマーク (10)

  • 【前編:バトル!】いろいろチューニングしてパフォーマンスを競うバトルイベント!「Tuningathon」 #tuningathon : ゼロスタートの広報ブログ

    2011年07月13日09:00 【前編:バトル!】いろいろチューニングしてパフォーマンスを競うバトルイベント!「Tuningathon」 #tuningathon カテゴリイベントプログラム Tweet こんにちは! ゼロスタートコミュニケーションズ広報もりのです! 先週末は暑かったですねー! そんな猛暑の中、渋谷では更に熱いチューニングバトルイベント「Tuningathon」が開催されておりましたよ。 ななな、なんと参加率100%!!!!!! 今日は、その様子を写真たっぷりでご紹介したいと思います! イベント参加者リスト(39名)※参加率100%!! イベント当日の様子:準備 イベント当日の様子:オープニング イベント当日の様子:チューニングバトル イベント当日の様子:バトル終了! 【後編に続きます】 はじめに「Tuningathonとは」 いろいろチューニン

  • 本当は速いImageMagick: サムネイル画像生成を10倍速くする方法 - 昼メシ物語

    一般的に ImageMagick のサムネイル画像生成は遅いとされており、パフォーマンスが求められるシーンでは Imlib2 などのより高速な画像処理ライブラリが使われることが多いです。 Imlib2 の高速さについては、以前「Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成 - 床のトルストイ、ゲイとするとのこと」という記事で紹介しました。この記事のベンチマークにおいて、Imlib2 によるサムネイル画像の生成は、 ImageMagick の3倍程高速でした。 しかし、 ImageMagick は Imlib2 より画質がよく、高機能で使いやすく、今も頻繁にメンテナンスされており、とてもよく出来ています。その点 Imlib2 は、2004年からメンテナンスされておらず、セキュリティホールが見つかっても、各Linuxディストリビューションがそれぞれパッチを当て

    tomotaka-ito
    tomotaka-ito 2011/01/24
    ブコメに勘違いしたことを書いていた...
  • 大容量ファイルのSCP転送を高速にする方法 - 元RX-7乗りの適当な日々

    比較的大きいサイズのファイルをSCPで転送することがあって、できるだけ高速化してみたかったので、色々試してみたメモ。 scpというかsshには、暗号化方式と圧縮有無の指定があるので、それらのベンチマークを。 尚、以下は、SSH v2が対象です。v1はかなり遅かったのと、そもそも使っていないので試していません。 (追記: 2019/11) エントリの情報は既に古いため、以下のエントリにて再検証しています。あわせてご覧くださいませ。 ベンチマークで利用した環境 [Server1] <=> [Gigabit Switching Hub] <=> [Server2] Server1 (HP ML115 G5) AMD Phenom 9950, 8GB, RAMディスク使用, Gigabit Ethernet Server2 (HP ML115 G1) AMD Opteron 1210, 4GB,

    大容量ファイルのSCP転送を高速にする方法 - 元RX-7乗りの適当な日々
    tomotaka-ito
    tomotaka-ito 2010/12/20
    rsyncにも適用できるし超便利
  • blog.8-p.info: Facebook の BigPipe と TTI

    Posted at 2010/10/22 01:59, Modified at 2010/10/22 03:42 Facebook のフロントエンドは結構かわったことをやっていて、例えば、ログイン後の http://www.facebook.com/home.php には <div id="pagelet_home_stream"></div> みたいな空の HTML があり、その後に <script>big_pipe.onPageletArrive({ … });</script> <script>big_pipe.onPageletArrive({ … });</script> ... と script 要素が何個もならんでいる。 BigPipe: Pipelining web pages for high performance この仕組みは (変数名のとおり) BigPipe と呼

  • グーグルがWebを高速化するために何をしているか

    のページをめくるように、どんなWebページも素早く表示できるようにする。グーグルは以前からWebの高速化に取り組んできました。 6月22日から、米サンタクララで行われていたWebサイトのパフォーマンスと運用に関するオライリーのイベント「Velocity 2010」では、グーグルのUrs Hölzle氏がWebの高速化技術について「Speed Matters」(スピードの重要性)というセッションで紹介ています。 Webを高速化するためにどのような技術があり、あるいはどのような技術が検討されているのか、このセッションの内容を紹介しましょう。 スピードは重要だ 私が話そうとしているのは、「Speed matters」(スピードの重要性)についてだ。Webは空飛ぶジャガイモより速くなれるだろうか? どのくらい速くなれるだろうか? (参考:オペラがやってくれた! グーグルの空飛ぶジャガイモに対抗)

    グーグルがWebを高速化するために何をしているか
  • Ferret – Indexing with Ruby

  • DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!

    MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください! まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in

    DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング!
  • Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成 - 昼メシ物語

    この記事の概要 Imlib2を使って画像のサムネイルを生成してみたところ、ImageMagickより3倍速かった。 また一般的には、Imlib2の方が画質が悪いとされているが、パラメータを調整することで、十分に美しいサムネイル画像を得ることができた。 はじめに Imlib2は画像処理ライブラリ。mixiの発表資料大規模画像配信とPerl によれば、mixiは高速に高品質なサムネイルを生成するために、ImageMagickでなくImlib2を選んでいる。 上記資料の中では、以下のように説明されている。 速度 Epeg > Imlib2 > Imager >>> ImageMagick 画質 ImageMagick > Imlib2 >>> EpegImlibの画質は多少ImageMagickに劣るが、速度は十分に速い、とのこと。 一方で、404 Not Foundという記事では、ImageM

  • ke-tai.org > Blog Archive > mixiでも使われている画像処理ライブラリ「Imlib2」について解説された記事「Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成」

    mixiでも使われている画像処理ライブラリ「Imlib2」について解説された記事「Imlib2でImageMagickより3倍高速かつ美しいサムネイル画像の生成」 Tweet 2010/7/26 月曜日 matsui Posted in 記事紹介・リンク | No Comments » 興味深いブログエントリーを見つけましたのでご紹介します。 mixiでも使われており、ImageMagickより3倍高速という画像処理ライブラリ「Imlib2」について解説された記事です。 記事内ではサムネイル画像生成について触れられていますが、ケータイサイトではサムネイル作成はもちろん、「各端末の画面サイズに合わせて画像をリサイズ」という処理を使うことが多いため、何かと応用が利くのではないでしょうか。 → 床のトルストイ、ゲイとするとのこと Imlib2でImageMagickより3倍高速かつ美しいサムネイ

  • Railsの画面生成を10倍高速化する方法 - 世界線航跡蔵

    RailsでPageキャッシュをより広く活用する方法を考えてみました。以下、ちょっと長く前置きが続きます。 Rails遅杉 Railsは遅い。何が遅いって、Rubyが遅くてRoutingが遅くてRDBとRHTMLが遅い。RDBが遅いのは大抵のWebアプリケーションでは変わらない話、で、だからRailsなんかが評価される余地があるんだよね。RubyやRHTMLの遅さは柔軟性の代償として受け入れよう。なにしろRDBがもともと遅いんだから。ただ、Routingは無駄に高機能だったりして頭にくる。Rhino on RailsのSteve YeggeもRoutingは黒魔術だと言っていたし。私はActionPackの全てが黒魔術だと思うけど。 そういう訳で、RoutingをCで書き直すのはドリコムのみなさんがいつかやってくれると期待するとして(可能なら手伝いたいけどね)、当面の対応としてはキャッシュ

    Railsの画面生成を10倍高速化する方法 - 世界線航跡蔵
  • 1