MySQL5.5 と MySQL5.6 と RDS - まめ畑
MySQL5.6は5.5よりもベンチマーク性能が落ちるという話がここ最近見受けられます。 My MySQL is faster than your MySQL Is MySQL 5.6 slower than MySQL 5.5? MySQL5.6の検証は半年程前から本格的に開始して、大量データに対して、JOINやLIMIT、INDEXが不十分なクエリに対して、productionデータで試してみたところ、完全に新規パラメータの設定やデフォルト値の変更を適用していない状態でも性能向上が出ていたので、安定性のテストをしていたのですが、上の記事などを読んでsysbenchやsql-benchを試してみました。 これは基本的なクエリを流すので、複雑な処理を高速化しているとかはあまり考慮されません。 ついでに、RDSもベンチマークを測ってみました。 MySQ5.5と5.6は基本的な設定内容は同一に
ARMORED CORE VERDICT DAY Official Site | アーマード・コア ヴァーディクト デイ オフィシャル サイト
2013.10.8 「ARMORED CORE VERDICT DAY」ゲームツアー「アクション編」公開 2013.10.3 「ARMORED CORE VERDICT DAY」ダウンロードコンテンツ第2弾 配信開始 2013.9.30 「ARMORED CORE VERDICT DAY」ゲームツアー「アセンブル編」公開 2013.9.30 「ARMORED CORE VERDICT DAY」PV第3弾公開 2013.9.26 「ARMORED CORE VERDICT DAY」ダウンロードコンテンツ第1弾 配信開始 2013.9.26 「ARMORED CORE VERDICT DAY」ゲームデータ連動サイト ACVD LINK公開 2013.9.26 「ARMORED CORE VERDICT DAY」発売開始！ 2013.9.25 「ARMORED CORE VERDICT DAY」
今後の負荷を RRDTool を使って予測してみよう
斎藤です。 今日は、RRDToolを使って、今後かかる負荷を手軽に予測する方法をご紹介します。あわせて、プログラムと連携して性能限界を越えそうなサーバがあるかを判定してみます。人手ではまかないきれない数のサーバに対して、一台ずつ問題の予兆を調べるときなどにお試しください。 ※CentOS 6.3 (64bit) + RRDTool の2013/2/20頃の最新ソースを用いて試しています 「限界」を早く知りたい！ ITインフラを運用している方の多くは、Cacti, Munin等で負荷を日々モニタリングされているかと思います。モニタリングしたデータを用いて今後を予測する際、どのようにされていらっしゃいますでしょうか？描かれたチャートの動きをもとに、経験と勘を駆使して「ヨイショ！」っとされている方も、いらっしゃるのではないでしょうか。 特に、ディスク容量やネットワークトラフィック等、根本的な対策
Try::Lite is especially useful in PSGI handler. - tokuhirom's blog
I guess, Try::Lite is very useful in PSGI handler. use Try::Lite; my $app = sub { try { main_handler(); } "MyApp::Exception::PermissionDenied" => sub { [403, ['Content-Type' => 'text/plain'], ['Forbidden']] }, "MyApp::Exception::NotFound" => sub { [404, ['Content-Type' => 'text/plain'], ['Not Found']] }, };Awesome.
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
fluentd + mongodb+ node.js でリアルタイムにグラフを描く - stanaka's blog
追記 2/22 毎回微妙に追記していますが、今回も追記です。最後にmongodbのinsert性能について80lines/secで厳しくなった、と書いてますが、環境か設定まわりがあやしいので訂正します。もうすこし検証してみようと思います。 → 検証して fluentd側の設定の問題であることが分かりました。詳しくは、http://blog.stanaka.org/entry/2013/02/22/171053 追記ここまで 最近は、fluentd + mongodb でログを蓄積していろいろ便利に使っているわけですが、数分に一回集計スクリプトを周したり、 GrowthForecast の画面をリロードしまくるのではなく、もっとリアルタイムで見たい! という欲求が募ってきたので、 node.js を使って実装してみました。( https://github.com/stanaka/realti
三項演算子である条件演算子が右結合であることの利点・妥当性と可読性について - Guinea Pig
条件演算子とは？ 条件演算子とは、よく見るアレのことである。 bool b = true; string s = b ? "真" : "偽" ; // ここで出てくる ? と : が条件演算子 // ? の左が真であれば : の左を返し、 // ? の左が偽であれば : の右を返す。 // この場合 b が true なので (b ? "真" : "偽") は "真" を返す 右結合と左結合 んで、右結合、左結合というのは、同じ優先度の演算子が並んだ場合、それを右からまとめていくか左からまとめていくかと言うルールの話である。 // 左結合の例 int sub = 10 - a - b - c; // 左結合なので、以下の順番で解釈される // int sub = (((10 - a) - b) - c); // 右結合の例 x = y = z = 10; // 右結合なので、以下の順番で解
「○x言語はもう終わり」というプログラマは終わり : 404 Blog Not Found
2009年02月19日22:30 カテゴリLightweight Languages 「○x言語はもう終わり」というプログラマは終わり これ、 Perlはもう終り？ | | プログラマ2.0日報 | あすなろBLOG すでにJPAの中の人が完璧に論破しちゃっている FUDを広げるのは誰の得にもならないと思うんだ。 - D-6 [相変わらず根無し] のだけど、お呼びがかかったので蛇足しておくことにする。 まずは各論から。 Perlはもう終り？ | | プログラマ2.0日報 | あすなろBLOG 言語仕様が汚い。厳格にはサブルーチンの「引数」という概念がないし、変数はすべてグローバルで特に宣言した場合だけローカルになる...というあたりの仕様は、そりゃインタプリタの実装は楽チンだろうけども、美意識（とミスしにくさ）には欠けるよね。 汚いったって英語や日本語ほどじゃない。そして英語や日本語が汚い
perl - Data::Decycle で悪循環を断とう! : 404 Blog Not Found
2010年08月23日08:00 カテゴリLightweight Languages perl - Data::Decycle で悪循環を断とう! Data::Decycleというモジュールをリリースしたのでお知らせします。 /lang/perl/Data-Decycle/trunk - CodeRepos::Share - Trac dankogai's p5-data-decycle at master - GitHub Dan Kogai / Data::Decycle - search.cpan.org Perlは循環参照が苦手 有名な話ですが、Perlで循環参照を作ると、プログラムが終了するまでその分のメモリーは解放されません。 perlobj - search.cpan.org use strict; use warnings; { package Dummy; sub new
overload の rebless バグについて - daily dayflower
きちんと追いきれなかったので結構ぐだぐだです。 そもそも bless の挙動とは #!/usr/bin/perl use strict; use warnings; package FooBar; package main; my $a = { }; my $b = $a; print $a, "\n"; # HASH(0xb8002a0) print $b, "\n"; # HASH(0xb8002a0) bless $a, 'FooBar'; print $a, "\n"; # FooBar=HASH(0xb8002a0) print $b, "\n"; # FooBar=HASH(0xb8002a0) 前半はまぁいいでしょう。同じ無名ハッシュリファレンスをさしているので同じ内容が出力されます。 おもしろいのは後半です。 $a を bless しただけなのに，$b も bless され
Perl OO におけるオーバーヘッド - naoyaのはてなダイアリー
フレームワークを考えるにあたって、気になる部分のベンチマークを取ってみた。 ポイントは次の３点。 関数の呼び出し方法： Class::func() と Class->func() 形式 クラスを継承した場合のペナルティ： Class->() と SuperClass->() 連想配列への直接アクセスと、アクセサ経由のアクセス Perl における関数型の実装と OO の実装で、関数呼び出し/メソッド呼び出しでどの程度のオーバーヘッドの差があるかをベンチマークした結果。勉強になります。結果としては関数型に対して OO の方が数倍遅い、という結果。 それで、結論の方なのですが 本来なら、アプリケーションより下位にあたるライブラリ関連は、オブジェクト化されて mod_perl 上で共有されるメリットはあるかもしれないが、アプリケーションの上位にあたるフレームワークは、mod_perl 上で共有され
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GCを切る中村氏 (r7kamura) と GCを改善する中村氏 (nari3)
FUDを広げるのは誰の得にもならないと思うんだ。 : D-7 <altijd in beweging>