How to Reduce Next.js Bundle Size
Photo by chuttersnap on UnsplashIn NE Digital, we are continuously working to provide faster and smoother user experience irrespective of the internet connection or the device type. In order to achieve that shipping less amount of javascript payload is one of our key focus areas. Byte-for-byte, JavaScript is still the most expensive resource we send to mobile phones, because it can delay interacti
Linuxページキャッシュの設定を変更してWrite I/Oをチューニングしたメモ - YOMON8.NET
環境 設定パラメータ 計測ツール 1 ダーティーページ状況の計測ツール 出力項目 出力フォーマットと出力例 2 時間付きvmstat 3 fio(I/O負荷発生ツール) 観測 実験 チューニング例 デフォルト値 ダーティーページの最小化 キャッシュ有効活用メモリ上に乗せたまま高速処理 局所的なI/O負荷を受け流したい 参考URL 環境 以下のCentOS7環境で検証しています。 $ uname -r 3.10.0-327.13.1.el7.x86_64 設定パラメータ Linuxのページキャッシュの書き出しを設定する主なパラメータは以下です。 バッファをバイパスするI/O(O_DIRECTなど)例外を除いて、通常の書き出し処理は一旦ダーティーページに書かれて後から遅延書き込みされます。 $ sysctl -a | grep dirty vm.dirty_background_bytes =
railsdm2018で「ActiveRecordデータ処理アンチパターン」を発表しました
Rails Developers Meetup 2018で「ActiveRecordデータ処理アンチパターン」というタイトルで発表してきました。 発表資料発表概要ActiveRecordはWebエンジニア達が嫌う（？）SQLを書かずとも、Rubyオブジェクトで気軽にデータベースへアクセスできる魔法のようなツールです。しかし便利な反面、何も考えずにゴリゴリActiveRecordを使ってDBアクセスしていると、劇的に重たいクエリが発行されたり非効率的なクエリが量産されたりします。 本発表ではそれらActiveRecordで陥りがちな罠をパターン化し、ActiveRecordデータ処理アンチパターンとして発表します。 ※発表では実際のサンプルコードとともにパフォーマンスの計測結果も紹介します。 事前に公開したエントリ発表資料に出てくる最初の事例はこちらがベースの事例となっています。 今月末のR
MySQLパフォーマンスチューニング -my.cnfの見直し- - Qiita
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
１台あたり10,000人を捌くRails製Webサーバのチューニング - dely Tech Blog
SREの深尾です。kurashiru [クラシル] のインフラを担当しています。 タイトルのとおり、クラシルのwebサイトではRailsを使っており、１サーバあたり10,000人程度のアクセスに耐えることができます。実際には余裕を持たせて5,000人/サーバを目安にスケールさせており、TV CMをガンガンやったり、国内外のTV番組で特集されたり、芸能人にSNSで拡散されても動じませんが、実は過去に１度だけWebサイトがダウンしてしまったことがあります。それは2017年3月11日にSmaSTATION!!というTV番組でクラシルが取り上げられた時のことでした。 以下はその時のリクエスト数を表すグラフです。ダウンしてしまったので計測できなかったユーザの数字は含まれませんがそれでもアクセス数は１分で数万人を超えていました。 それまで、Webサイトの負荷対策はあまり行っておらず、２台のWebサーバ
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
MongoDB - Sign In
The page has timed out If this page does not reload automatically, please refresh your browser.
THREE.jsをサンプルのまま作るとCPU使用率が半端じゃない件 - tsuge development page
最初に、ここで使っているのはTHREE.jsのRev.49なのでそのつもりで。 バージョン違いの場合はまた別の解があるかもです。 THREE.jsをサンプルのまま作ると、デュアルCPUであろうと最大限にCPUを使ってくれて常時100％近い。 ちなみにグラフィックボードをちゃんと搭載しているPCなら別として、ビジネス向けノートPCなどソフトウェアでがんばってる場合ね。 Webサイト表示してCPU100％なんて、正直いやだよねと。 CPU時間なんて最近そんな気になるもんでもないけど、ノートは熱くなるし、バッテリの消費も早いし、どっちにしろ使用率は少ないに越したことないだろと。 サンプルでよく見るのはこういう処理。 function animate() { requestAnimationFrame(animate); render(); } function render() { render
漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Improve the performance of Mapbox GL JS maps | Help