DynamoDB でのデータのクエリとスキャンのベストプラクティス - Amazon DynamoDB
このセクションでは、Amazon DynamoDB で Query オペレーションと Scan オペレーションを使用するためのベストプラクティスについて説明します。 スキャンのパフォーマンスに関する考慮事項 一般的に、Scan オペレーションは、DynamoDB の他のオペレーションよりも効率が低くなります。Scan オペレーションは常にテーブルまたはセカンダリインデックス全体をスキャンします。次に、値をフィルターして必要な結果を提供し、本質的に結果セットからデータを削除する余分なステップを追加します。 可能な場合、多くの結果を削除するフィルターを使用して大きなテーブルやインデックスで Scan オペレーションを実行することは避けるべきです。また、テーブルまたはインデックスが大きくなるにつれて、Scan オペレーションの処理速度は遅くなります。Scan オペレーションは、すべての項目でリク
本番サーバのメモリ量が90%を超えて正常に動作しなくなることがありました。 なぜ90%まで増えるのか原因を突き止めるのに苦労したので紹介します。 現象 サーバ起動時のメモリ使用量は5〜10%程度 1〜6ヶ月で緩やかに上昇し75%程度に 90%ぐらいからout of memoryが起きる するとPHPがメモリ確保できなくなる そしてサーバエラー、DB接続エラーとなりサイトが表示されない なぜ気づかなかったか ３〜６ヶ月かけて上昇したと思ったら、40%程度に減ることもあった 頻繁にリリースすることがありリセットされてた 年に１回程度発生していたがアラートで事前検知し再起動していたので重要視していなかった そんな中、メモリアラート閾値ギリギリのところで、BOTからのアクセスが増え一気にメモリが90%になりサイトが表示されない現象が起きてしましました。 原因にたどり着くまで紆余曲折を経たので、時系
nginxでWordpressサイトを運用する場合、php-fpmを利用することが多いかと思います。（Apacheでも利用することができますが） php-fpmの設定によって、Webサイトのパフォーマンスは左右されます。それだけでなく、不適切な設定はメモリリーク等につながるので、Webサイトにとって重要な設定であるといえます。 この記事では、そんな php-fpm の設定の最適化方法について解説していきたいと思います。 php-fpmの役割と特徴 WordPress などの動的サイトは、Webサーバーがクライアントからリクエストを受けると、サーバー上でPHPを実行して動的にページを生成し、生成したページをレスポンスとしてクライアントに返します。 この、サーバー上でPHPを実行する仕組みがphp-fpmです。php-fpmでは、リクエストのたびにプロセスを生成していたのでは非効率なので、原則
はじめに Linuxサーバ(CentOS 6.6)の時刻をdateコマンドで一時的に変更する例です。 たまにアプリケーション等の検証目的で、サンドボックス用途のLinuxサーバを対象として、一時的にLinuxサーバの時刻を変更する事があります。備忘を兼ねて、時刻変更コマンドをメモしました。 注意事項 サービスに影響を与えない かつ 自分しか利用していないサンドボックス用途のLinuxサーバでなら、自由にサーバ時刻変更しても大丈夫だと思いますが、本番環境や開発環境のサーバでは時刻変更しないようご注意下さい。 もし、本番環境や開発環境のサーバについて、どうしてもサーバの時刻変更が必要となる場合は、サーバ管理者の方々とご相談しましょう。 また、サンドボックスのLinuxサーバで時刻変更が必要なテストが終わったら、ntpdateコマンドを使うなりして、変更した時刻を元に戻しておくと良いでしょう。
CSSファイルなどの静的ファイルはブラウザにキャッシュされ、内容を変更しても更新されないことがあります。それを避けるためにファイル名に次の様な引数を付けるのが定番になっています： css/app.css?201905201034 Laravel Mixのコンパイルではこれを自動化出来ます。 詳しくはドキュメントを読んでください。 バージョン付け／キャッシュ対策 | アセットのコンパイル(Laravel Mix) 5.5 Laravel 試してみる webpack.mix.js に version() を追加します。 mix.js('resources/js/app.js', 'public/js') .sass('resources/sass/app.scss', 'public/css') ; ↓ mix.js('resources/js/app.js', 'public/js') .s
信頼できるタイムスタンプがログに残っていることが障害調査の重要な手がかりとなります。 正確な時刻の確保はサーバ管理の根本ですので、時刻同期の設定はOSをインストール後に最優先で行う作業と位置づけられるものです。 基礎知識として 時刻は ハードウェアクロック とOS上の ソフトウェアクロック がともに刻んでいます。 稼働中はソフトウェアクロックだけが参照されますが、ハードウェアクロックはマシン停止時にも動き続けているので 起動時にはハードウェアクロックがソフトウェアクロックへ読み込まれます。 ネットワークから現在時刻を提供するサービス(NTP)により時刻合わせをします。 このとき、特に時刻を遅らす場合、急に遅らせる操作はしません。時刻が後ろへ飛ぶことによりログの時刻の前後関係がひっくり返る可能性があるからです。 （ログ以外のソフトウェア動作も異常を来すかも知れません） ソフトウェアクロックの
##概要 Laravelでサービスを作っていると、このコントローラー内ではアクション実行前に この値をチェックして、だめなら別のページにリダイレクトさせたいとかって時があると思います。 そんな時に便利なのがコントローラーフィルターです。 しかしなぜかLaravel公式サイトでは一瞬しか触れられておらず、詳細が不明。もったいない。 ただしLaravel 5.1からこのコントローラーフィルターは非推奨となり、 HTTPミドルウェアを使うように推奨しています。 （@localdisk さんよりご指摘。ありがとうございます！） ということで今回は、4系を使っている人向けにコントローラーフィルターについて書きます。 HTTPミドルウェアについては次回記載したいと思います！ ##寄り道 概要で述べたようなことを実現しようと考えた時に コントローラーフィルターを知る前はこんな感じのプログラムを書いてまし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
