サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
norikone.hatenablog.com
NoClassDefFoundError や ClassNotFoundException に遭遇した時など,Java で書くならある程度クラスローディングについて知っておいたほうがいいかなあと思い調べたときのメモ.なんとなくの概要. クラスローダ 基本的な仕組み Java アプリケーションは基本的に,複数のファイルに分かれた沢山のクラスによって成り立っています.アプリケーションを動かすためには,これらのクラスを JVM が読み込まなければなりません.Java では JVM のクラスローダと呼ばれる機構がこの処理を担います.クラスローダは,読み込むべきクラスを判断し,ストレージから当該クラスファイルを探し出し,ファイルを開いてクラスをロードします. クラスロードの戦略は,オンデマンドな感じになっています.アプリケーションの開始時に必要な全てのクラスを読み込むのではなく,実行中に必要になった
MySQL のバージョン5.6から追加された機能に、Index Condition Pushdown(ICP) というものがあります。ICP は「マルチカラムインデックスの順番を意識しなくてもよくなる仕組み」的な説明がされることがあり、それはそれで間違いではないのかもしれません。が、それだと「ストレージエンジン側に条件式をプッシュダウンする」という動作が伝わりにくい気がしますし、ICP がマルチカラムインデックスの順序による制限を解消するものだと勘違いしてしまう可能性があります。なので、この記事では行フェッチ時の動作を見ながら ICP の動作イメージや利点を考えてみようと思います。ちなみに InnoDB を前提に書いていこうと思います。 先に簡単に書いておくと、 ICPとは ストレージエンジンがセカンダリインデックスを使って行をフェッチしようとする際に、MySQLサーバからストレージエンジ
パーティショニングについての覚書。 一応 MySQL が前提。先に具体的な実体を書いたあと、それがパフォーマンス向上にどう寄与するのかを書きます。 パーティショニング is 何 簡単に言えば、データベースのテーブルを物理的に分割することです。テーブルのデータが分割されてしまっても、外からは論理的(透過的)に単一のテーブルとして見えます。なので、以下の図のようにクライアントや DML レイヤはそれを意識する必要はありません。p1 や p2 は分割されたパーティションを表しています。 この透過性は MySQL サーバによって提供されています。また、ストレージエンジンは分割された各パーティションを独立したテーブルのように扱います。これを図にすると次のような感じになります。 このため、例えばパーティショニングするテーブルにインデックスを張ると、各パーティションごとにインデックスが作られることになり
MySQL のストレージエンジン(SE)を自作してみたときのメモ。バージョンは 8.0.13。 アーキテクチャをざっくりと掴むことが目的なので、ストレージエンジンの自作といっても非常に単純な操作しかできないものです。 RDB らしさとも言えるインデックスや行レベルロック、トランザクションなどの高度な処理は実装せず、簡単に入出力の流れを追っていきます。 ゴールは以下の基本的な機能を実現して、「あ、こんなもんなんだ〜」感を覚えることです。 CREATE 文でテーブルの作成 INSERT 文で行の挿入 SELECT 文で行の取得 ちなみに MySQL のコードは C/C++ です。(といっても、テンプレート等の C++ らしい拡張的な機能は使われておらず、ほぼ C で書かれています。クラスは頻繁に使われているので、俗に「クラスのあるC」なんて言われている模様。そのため、C をある程度理解していれ
HTTP の世界はステートレスです.すなわち基本的なプロトコル上では状態が管理されません.なので,ユーザの認証状態などを管理するために,これまでは主に Cookie & セッション ID が使われてきました.一方で,最近ではトークンを使った認証状態の管理もよく使われるようになってきました.この記事では,この辺の参考文献を見ながら,それぞれの特徴(主にトークンの利点)についてメモします. それぞれの認証方式の概要 Cookie & セッションID による認証 この方式では,ユーザが ID/PW をサーバに送り,その認証結果としてセッション ID が Cookie で返されます.サーバ側では,払い出したセッション ID とそれに紐づくセッション情報を1対1で管理しておきます.ユーザはそれ以降の HTTP リクエストに Cookie(セッションID) を含めることで,サーバに自分が誰であるのか(
今更ですが備忘のため,OAuth とか OpenID とかその辺の概要についてまとめたメモ.具体的な仕様については書かないけど RFC や公式サイトに載っています.便宜上,厳密性を疎かにしている点あり. OAuthについて 背景 現在,Twitter や Yahoo など様々なサービスが,Web API として機能を提供しています.API エコノミーなんていう言葉がありますが,Web API としてサービスを提供していくこの動きは今後も続きそうです. これに伴って,API をラップしてサービスを提供するサードパーティ製のアプリケーションが続々と出てきています.それをここでは「クライアント」と呼びますが,サービスを使いたいユーザはこのクライアントを通して API を利用し,何かしらの価値を享受するわけです.この方式が現在の Web では普及しています. 例えばユーザが Twitter クライ
MySQL(InnoDB) のロックにはレコードロックとかギャップロックとかネクストキーロックとかありますが、結構ややこしくて、クエリで条件文が与えられた時にそれがどのようなロックになるのかをイメージし辛い問題が自分の中でありました。ので、実験してみた(MySQL8.0.12、REPEATABLE READ)結果を図で書き残します。なお、結果は SELECT FOR UPDATE を使って排他ロックをとる方法で試したものですが、ロックの範囲を知る上では、排他ロックか共有ロックかとかは関係ないかと思います。 前提として、以下のような id カラムのみを持つインデックスレコードへのロックを考えます。レコードには10 ~ 40 までの 5 飛びの値が存在します。それぞれのインデックスレコードの間にはギャップ(gap)が存在します。また、最初のレコードの前と最後のレコードの後には、論理的な最小値へ
AWS の AutoScaling 機能を使う機会があったので、忘れないうちに設定方法を書いておきます。 AutoScaling とは 負荷に応じて EC2 インスタンスの数を自動的に増減してくれる機能です。水平方向の負荷分散、所謂スケールアウトを動的に実現します。また、増減はさせずに、インスタンスの数を一定にしておくためだけに利用したりもできます。負荷に応じて、と書きましたが、トリガーには CloudWatch のメトリクスなどが使用できます。 AutoScaling の利用には今のところ追加費用は発生しません。(当然ですが、AutoScaling によって追加された分のインスタンスの利用料はかかります) 以下の記事に分かりやすく概要が書いてあります。 【AWS】Auto Scalingまとめ 設定 今回はマネジメントコンソールを使ってGUIで設定をしていきます。AutoScaling
Apache のチューニングにあたって MPM について知ったときのメモ、なんとなくの概要。 Apache MPM is 何か、ざっくりと。 Webサーバの実装モデルの話 MPMの話に入る前に、Webサーバの基本的な並行処理のモデルをおさえておきます。 Webサーバに接続するクライアントが1人だけであれば、並行処理について考えることは少ないでしょう。しかし、多くの場合は同時に複数人のクライアントに対応しなければなりません。 そういった状況でリクエストを並行処理するためのWebサーバの実装モデルがいくつかありまして、代表的なものを簡単におさらいします。 マルチプロセスモデル クライアントからのリクエストごとに fork をして子プロセスを生成し、その子プロセスに処理を委ねる方式です。 プロセスの fork では、メモリ上の親プロセスのアドレス空間を、生成した子プロセスのアドレス空間にコピーし
最近 GAS(Google Apps Script) や SlackBot の存在を知って、慣れていけばいろいろ捗りそうな気がしたので触ってみた時のメモ。 今は特に GAS で自動化したいようなものは無かったので、SlackBot と連携して簡易的な日程調整、出席管理アプリを作って遊んでみました。JavaScript 自体も全然触ったことがなかったので、少しは勉強になったかなと思います。尚、実用性は皆無だと思われ(ry 簡単に今回作ったアプリの説明 Slack 上で日程調整ができるアプリです。特定のチャンネルから特定のワードを付けてメッセージを投稿すると、Google Spread Sheet と連携して出席状況の管理などをしてくれます。 イベントの登録 新しくイベント(予定)を追加するには以下の形式でメッセージを投稿します。 新: [イベント名] [日付(M/d)] ... [日付(M/
AWS の ELB に複数のインスタンスをぶら下げて負荷分散をしようと思った際に、Laravel アプリのセッション管理について考えたメモです。 ユーザにログインさせる必要があるアプリは、ELB によって接続先インスタンスを振り分けられたとしても、そのセッションを維持することが必要になってきます。単に ELB にインスタンスを沢山ぶら下げるだけだと、デフォルトでは1つのクライアントからの各リクエストが別々のインスタンスに割り振られてしまいます。つまり、デフォルトではインスタンス間でセッション情報を共有できていないので「さっきログインしたはずなのにまたログインしろ画面が出てきたんだけど」ということになってしまいます。 この記事では、この問題を解決する一般的な方法を3つ紹介します。次に、そのうちの一つを Laravel で設定してみます。 セッション切れの解決策 先に書いた問題を解決するための
ApacheのMPMとして、プロセスベースの並列実行をする prefork を使用していたのですが、省メモリのためにスレッドベースの並列実行をする event へ変更しました。構成としては、Apache2.4 + event + mod_proxy_fcgi + php-fpm です。 それぞれの MPM の特徴に関しては、以前書いたこちらの記事で簡単に紹介しています。 norikone.hatenablog.com 動きを確認するためにそれぞれデフォルトの設定で、PHPプログラムが動いているサーバに簡単な負荷テストを行ってみたところ、プロセスを多数起動しない分やはり event の方が使用メモリ量が少ないという結果が出ました。スループットも若干 event が prefork を上回る結果になりました。 ただ、速度に関しては配信するコンテンツの内容やリクエスト数によって prefork
このページを最初にブックマークしてみませんか?
『norikone.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く