OPcache オペコードキャッシュの仕組み - Shin x Blog
本エントリでは、PHP の内部実装（php-src）から OPcache のオペコードキャッシュの仕組みを見ていきます。 OPcache にはいくつかの機能がありますが、ここでは共有メモリへのオペコードキャッシュと preload が対象です。ファイルベースのキャッシュと JIT については触れません。 サマリ オペコードキャッシュ preload オペコードキャッシュと preload の比較 オペコードキャッシュ キャッシュデータレイアウト グローバル変数、マクロ キャッシュデータ構造体 オペコードキャッシュ: ZCSG(hash) キャッシュエントリ: zend_accel_hash_entry キャッシュデータ初期化 OPcache 処理の有効化 PHP ファイルコンパイル処理でのキャッシュ制御 persistent_compile_file() の主な処理 zend_accel_
Apple M1の参照カウントは本当に速いのか - yamasaのネタ帳
Apple M1に関して以下のようなツイートが話題になった。 18/ Another "magic" trick is how their "Swift" programming language uses "reference counting" instead of the "garbage collection" in Android. They did something in their CPU to double the speed of reference counting.— Robᵉʳᵗ Graham😷, provocateur (@ErrataRob) 2020年11月26日 fun fact: retaining and releasing an NSObject takes ~30 nanoseconds on current gen Intel, and ~6.
各種メモリ／ストレージのアクセス時間，所要クロックサイクル，転送速度，容量の目安 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 各種メモリ／ストレージについて，2024年時点で標準的なアクセス時間，所要クロックサイクル，転送速度，容量を，各種カタログスペックを参考にまとめてみました． レジスタ(レジスタファイル) 最近のCPUのレジスタ(register)のアクセスは，通常CPUの1クロックサイクルで完了します．2024年時点では，標準的なCPUのクロック周波数は，1〜5GHz程度のオーダーです．1GHzは1秒あたり10億回，すなわち1クロックサイクルは1ナノ秒です． したがって，2024年時点では，レジスタには0.2〜1ナノ秒程度でアクセスできると言えます．
キャッシュフレンドリーなステートレスアプリケーション設計について考える #CDN_Study - mizchi's blog
CDN_Study という勉強にいってきた。 https://http2study.connpass.com/event/81469/ そこで、Akamaiの方が、「個人の意見だけど、アプリケーション側がもっと基礎設計でステートレスでキャッシュフレンドリーな設計になってないといけないよね」という旨の発言をしていて、最近そのことにアプリケーションエンジニアとして同じようなことを考えていたので、書き出してみる。 SPAとかSSRとかフロントの不毛な話は出さないようにしてるが、主にサーバレス環境を意識している。 前提 世の中のアプリケーション内のモジュールは、Statefull or Stateless に分類でき、それをツリー状に表現できれば差分検知できる、という React の仮想 DOM 的な世界観が自分にある 以下の話は、基本的には Fastly のサロゲートペアーとそのためのミドルウェ
Apache Igniteを分散キャッシュに利用したシステム負荷軽減 | CyberAgent Developers Blog
秋葉原ラボ 飯島 賢志 シュティフ ロマン(@rshtykh) はじめに サイバーエージェント内の研究開発組織である秋葉原ラボは、大規模データ基盤の開発・運用に加えて検索・機械学習・データマイニングなどを活用して、弊社の各サービスと様々な形で連携している。今回、Amebaトピックスで使用しているレコメンドAPIに分散キャッシュを導入してシステム負荷を軽減した事例を紹介する。 Amebaトピックス Amebaトピックスでは、Amebaが展開するサービスの中でいまホットなトピックや記事を選定し配信している。誰にどのトピックを表示するかについていくつもの判定や処理が瞬時にされるが、今回の改善で一層速くレスポンスを返すことができるようになった。 図1. Amebaトピックスのブログヘッダへの配信 システム構成 今回、改善対象となったレコメンドAPI周りのシステム構成を以下の図2に示す。一部省略して
大きなテキストファイルをawkで処理するときにcatで投げ込むのと、ファイル読み込みするのどっちが速いか比較 - カメニッキ
追記が増えたので整理 経緯 2.5GBのテキストファイルを加工する必要があり、①vimで開いて加工→vim死亡②sublime textで開いて加工→sublime text死亡となったため、awkを用いて以下の様なコマンドを実行した。 $ cat sample.txt | awk '$5 ~ /((26|27|28|29|30)\/Jun|(01|02|03)\/Jul)/{ print }' > result.txt すると 「catいらなくね？」と指摘 さらにMATSUMOTO, Ryosuke (@matsumotory) | Twitter ＜ 「キャッシュに入れて高速化してるんかと思った」 とコメントをもらいました。ので、どっちが速いかの検証です。 注意 加工の目的はログファイルからある期間だけの行を抜き取りたい 正規表現がいけてないのは気にしない 比較 awkにファイル指定す
DMM inside
20年越しの大規模リニューアルが進行中。「わくわく時間100%」を目指すDMM通販モダナイズプロジェクトの全貌
はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer Blog
こんにちは、id:hakobe932です。はてなブログではユーザ体験の改善のために、ページ表示速度を向上させるための様々な取り組みを行っています。このエントリーでは、はてなブログで行っている、ブラウザキャッシュの活用、JavaScriptのページ最下部での読み込み、JavaScriptの圧縮、という3つの取り組みについて解説します。 ブラウザキャッシュの活用 同じ内容のJavaScriptやCSSを、ページを表示するたびにダウンロードすると、余分なHTTPリクエストが発生しますし、読み込み時間がかかります。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 $ curl -I http://hat
FlashCacheでI/Oのボトルネックを解消させよう
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog はじめに 皆様こんにちは。ストレージアーキテクトの矢澤祐司です。 Yahoo! JAPANにて利用されているマルチペタバイトなストレージ達と仲良く過ごしている私なのですが、今回はFlashCacheを用いたI/Oの最適化について検証した結果の一部を皆様にご紹介させていただきます。 FlashCacheとは SSD製品が安価に調達できるようになった昨今であっても大容量なストレージを構築する際はHDDに頼らざるを得ず、さすがにフルSSDで大容量なストレージを構築してしまうとコスト過多で現実的ではないと判断される方が大半かと思います。確かにSSDを利用することによってI/O性能が課題だったシステムを改善された事例はたくさんあるものの、大
5x performance - switching from LWP to Furl & Net::DNS::Lite
Recently I rewrote some of our code that used LWP::UserAgent to use Furl instead, and have been observing more than 5x increase in performance (the CPU time spent for each HTTP request in average has dropped 82%). The fact clearly shows that if you are having performance issues with LWP::UserAgent it is a good idea to switch to Furl. And here are my recommendations when doing so: use the low-leve
mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基本はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.ovaistariq.net/833/speedup-test-kitchen-vagrant-testing/
http://ryanbowlby.com/blog/2014/11/26/speed-up-your-chef-test-kitchen-testing-cycle/
5.3.2. Cachegrind を使ったキャッシュ使用量のプロファイリング | Red Hat Product Documentation