JavaScriptの顔認識ライブラリをチューニングしたら実用レベルになったという話 (Kanasansoft Web Lab.)
ただ、WebRTCで顔認識させようとすると遅くてしかたがなかった。 最初は速いこともあるが、10回ぐらい認識をさせるとすぐに遅くなる。 とりあえず、デモ。 そこで、チューニングをしてみることにした。 まず、JavaScriptの定番の高速化を試してみた。 例えば、正の数で使える「Math.floor(x)」を「(x | 0)」に、整数で使える「x * Math.pow(2, y)」を「x << y」にする等。 これで、10~30%高速化できた。 次に、遅くなっている部分を調べたら、Web Workersで分散するための仕組みが遅くなる原因だとわかった。 これは、Web Workersを使わない場合にも影響が出ていた。 じゃあ、Web Workersを使えば速くなるのかといえばその逆で、20倍遅くなっていた。 詳しくは調べてないけど、多分Workerスレッドに処理データを渡す時にJSON化が
チューニンガソンで優勝してきました : DSAS開発者の部屋
7/9(土)にチューニンガソン というイベントに参加して優勝してきたので、その報告と、何を考えてどんなチューニングをしたのかを 記憶の範囲で公開したいと思います。 今回のチューニンガソンのお題は、WordPress(ja) + php + Apache + MySQL で、 ab を使って wp-comment.php 経由でコメントのポストをすることで計測が行われました。 MySQLとApacheを立ち上げたらWordPressが動く環境が渡され、そのWordPress自体は設定ファイルを含めて 改造が一切禁止、WordPressの実行をショートカットするチートも禁止です。 0. 試合前日 環境がAWSとAMI Linuxということは事前に公開されていたため、前日にAWSに登録して少しだけAMI Linuxを 触ってみました。yumベースだけどCentOSと違って結構新しいバージョンが用
甘肃空气优良天数逾九成水质土壤环境质量明显提升 爆发勒斯坦人地巴与当冲突-武冈新擞蔬菜行情网
最新文章 2018-12-26 07:29▪ 一男子高速“飙车”后拍视频晒微信群因涉嫌危险驾驶罪被拘... 2018-12-26 07:29▪ 嘉定优化营商环境为企业办事提速增效 2018-12-26 07:29▪ “论证西游记是自己所写”，有些奇葩考题不值得提倡 2018-12-26 07:29▪ ？元旦春节将至干部职工可享有正常福利待遇每人每年可领... 2018-12-26 07:29▪ 网络女主播与“阔绰”粉丝成恋人被骗25万元 2018-12-26 07:29▪ 福建龙岩一公交车被歹徒劫持冲撞行人已致5死21伤 2018-12-26 07:29▪ 雷寒、李洪被撤销重庆市政协委员资格 2018-12-26 07:29▪ 西双版纳公开销毁逾2000件非法枪支、猎具、毁林器具 2018-12-26 07:29▪ “市民云”成全国首个用户逾千万政务APP，有235项服务 2018-12-
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
プロのサーバ管理者がApacheのStartServers, (Min|Max)SpareServers, MaxClientsを同じにする理由 - blog.nomadscafe.jp
kazuhoさんが「プロのサーバ管理者の間では存在価値が疑問視されて久しい (Min|Max)SpareServers だと思う」と書いたり、hirose31さんが去年のYAPC::Asiaで{Start,{Min,Max}Spare}Servers,MaxClientsは同じにしているよと発表したり、実際前職のサーバはそのように設定されていたのですが、自分でうまく説明ができてなかったので、調べながら書いてみた。 本当はイントラブログ用に書いていたものですが、がんばったので転載。 前提として、CPUの使用率におけるsystemとfork Re: クラウドがネットワークゲーム開発者にもたらしてくれたもの - blog.nomadscafe.jpでも書いている通りforkってのはサーバにとって重い部類の処理になります。つまり負荷の高いときにforkを大量に行うのはしてはならないことの１つです。
はてなダイアリーの高速化の裏側 - stanaka's blog
先週、ダイアリーがリニューアルされました。今回のリニューアルはダイアリーの応答時間の改善が目玉の一つとなっており、そのために１週間リリースを延ばし、改善の時間を確保していました。今回は、この改善について記しておきます。 はてなでは「推測するな、計測せよ」の原則にしたがって、ダイアリーのユーザーページの全アクセスの応答時間を解析し、ヒストグラムを作っています。また、特定の閾値(1秒、2秒とか)以内に何%のリクエストを返却できている割合をグラフ化しています。 このグラフを見ると、応答時間時間は時間とともに劣化することが一目瞭然です。実際に今年初めの値と比較すると10%〜20%程度の悪化が確認されました。あとは、これをひたすら改善していくのみです。今回実施した主な対策は、以下の通りです。 ネットワーク パケットロスが発生しているようなトラフィック経路上のボトルネックの解消(L2スイッチの置換、物
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
漢(オトコ)のコンピュータ道: 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ページを開く
20090107 Postgre Sqlチューニング（Sql編）
IDEA * IDEA
MyNA Web Site