Next.jsのmiddlewareはVercel以外でも問題なく使えるか
Next.jsでv12〜middlewareという機能が使えるようになりました。 middlewareに書いた処理はリクエストが完了する前に実行されます。Cookieの値に応じてルーティングを振り分けたり、Basic認証を導入したり等など、幅広い用途で使えそうです。 VercelとNext.jsの組み合わせが強いのは、VercelにNext.jsをデプロイするとこのmiddleware部分をEdge Functionsで捌いてくれるという点です。つまり、静的なページに対するリクエストに対して、オリジンサーバーに触れことなくmiddlewareを実行できるということです。 Vercel以外のプラットフォームだとどうなのか ドキュメントには以下のような記載があります。 This works out of the box using next start, as well as on Edge
ZOZOTOWNリニューアルで実施したCache Stampede対策 - ZOZO TECH BLOG
はじめに こんにちは。マイグレーションチームの藤本です。 この記事では、先日のリニューアルに伴って導入したBackends For Frontends（以下、BFF）で、Redisを使ったキャッシュの事例をご紹介します。キャッシュを導入する際に起きる問題とその回避策について、サーバーサイドのアプリケーションで行った対策をもとに紹介していきます。 ZOZOTOWNリニューアルとBFF ZOZOTOWNで導入したBFFは、複数のAPIのレスポンスをフロントエンドが必要とする形式に集約して返却することを主な目的としています。これまでの実績から、大規模セール時のアクセス数は通常時の何倍にもなることがわかっており、BFFもそれに耐えられるパフォーマンスが必要です。 しかし、BFFに来たすべてのアクセスをそのままAPIに流すと、パフォーマンスに影響する恐れが出てきました。そのため、APIからのレスポン
HTTPキャッシュ入門の入門 – cat /dev/random > /dev/null &
ローカル・経路上のキャッシュを併用しよう キャッシュは再利用されるほどいいものです。 サイトの規模にもよるのですが、ローカルと経路上のキャッシュはそれぞれ性質が異なるため、ブラウザキャッシュだけ適切に設定しておけば経路上では不要というわけではありません。 ローカルキャッシュはキャッシュを持つクライアント自身がサイトを再訪する場合は有効ですが、キャッシュを持っていない新規クライアントには無効です。 経路上のキャッシュは新規クライアントに対してもキャッシュを返すことができるため、例えばサイトへの流入が突然増えるといった事態でも対処がしやすいです。 そのためコンテンツ次第ではありますが、ブラウザキャッシュのように特定のクライアントでしか使えないprivate cacheにするよりも、 効率を考えてローカル・経路上のどちらでもキャッシュができ、多数のクライアントで共有できるshared cache
キャッシュの Stampede 問題をセマフォで解決する - Qiita
Cache Stampede キャッシュが有効期限切れによってオリジン（データベースなど）へのアクセスが殺到することで負荷が高まってしまう問題を Cache Stampede (キャッシュ・スタンピード） と呼びます。Stampede は日本語にすると「殺到」というような意味合いの単語です。 ※他にも Cache miss storm だったり Thundering Herd だったり、Dog pile だったり、いろいろ呼び方はあるようです。 本記事では この Cache Stampede 問題への対策として memcached の機能をセマフォとして使い、オリジンへのアクセスを制御する方法について記します。 問題の整理のため、キャッシュを使う場合の典型的な処理を振り返りながら見ていきます。 単純なキャッシュ キャッシュには通常では有効期限があり、有効期限が切れるとキャッシュを使用せずに
Webアプリ負荷試験ガイド - withgod's blog
Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前
シンボリックリンクを用いたアトミックデプロイと opcache と realpath cache - ngyukiの日記
これまで PHP のアプリケーションのデプロイは rsync でどべーとコードを撒いていました。が、それだと新旧のコードが混在するし Capistrano とかはデフォでシンボリックリンク切り替えでアトミックなデプロイになっているし、周回遅れな感じもしますが今後は似たような方法でデプロイしたいと思います。 releases/ ディレクトリの中にリリースタグでディレクトリを掘ってコードを配置して current を最新のリリースのディレクトリへのシンボリックリンクにします。そして Apache や Nginx でドキュメントルートを current の中の公開用のディレクトリに設定します（/path/to/app/current/public とか）。 /path/to/app/ releases/ 20161213/ 20161224/ 20170101/ current -> relea
Webサービスにおける
キャッシュ戦略
YAPC::Asia Hachioji 2016 mid in Shinagawa 2016-07-03 Yusuke Wada a.k.a. yusukebe
『PHPでブラウザのキャッシュを利用させる検証』
純粋なHTMLファイルで、余計なヘッダーやMETAタグを付けていなければ一定期間、ブラウザ上にあるキャッシュを見させると言うことは出来たりします。 これって、PHPででも出来るのかなとふと思い検証してみました。 （特にそれで困ったことがあったわけではないのですが） で、結論から言えばApacheの設定やヘッダーによる制御で、PHPを意図的にローカル（ブラウザ）のキャッシュを利用させるということは出来ませんでした。 キャッシュされているか否かでいえばキャッシュされているようなんですが、要は（あえてHTTステータスコードを返すようなことを除いて）ヘッダーやMETAタグだけの制御により、サーバーから304レスポンス返してブラウザにあるキャッシュを意図的に見せたい、ってことができない。 純粋にクライアント-サーバーのシステム構成で、間にプロキシサーバーなど余計なものを介在しなければ、キャッシュが働
クラウド環境でのApacheの設定
クラウドのホスティングサービスは、一定リソースの時間極課金＋通信トラフィックの従量課金が一般的です。 CPUやメモリなどのリソースは、1%しか使わなくても100％使っても時間内の料金は同じです。 一方で通信料は使った分だけGB単位などで段階的に課金される仕組みです。 この料金体系では、なるべくリソースを使い切って、且つ通信料を抑えることが最も費用対効果のある利用方法となります。 サーバーからクライアントへのレスポンス、特にブラウザーのロードとレンダリングを高速化させるために、Yahoo!のYSlowやGoogleのPage Speedを使ってチューニングを行うのと同じようなアプローチで、なるべくCPUに仕事をさせて、トラフィックを減らしてみたいと思います。 キャッシュ機能を最大限利用する Expires Apacheのmod_expiresを有効にすることで、レスポンスヘッダーにExpir
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
screw-axis.com