You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 How a single PostgreSQL config change improved slow query performance by 50x https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0 How a single PostgreSQL config change improved sl
スライスの比較の記事を読んでいて、ほーと思ったのでメモ。 BCEで最適化されるとスライスへのアクセスが少し速くなるよ、という話。 参考 ここに書いてあることを要約して書いただけなので元記事読んだほうが良い説があります Slice Comparison in Golang - Tapir Games はじめに 2つのスライスの比較として、以下の3つの関数を考えます。 1つはDeepEqualを使った場合で、あとの2つは自作した関数です。 func CompareSlices_Reflect(a, b []int) bool { return reflect.DeepEqual(a, b) } func CompareSlices_General(a, b []int) bool { if len(a) != len(b) { return false } if (a == nil) != (
今日こんなツイートをした。 @mattn_jp よろしければベターな理由をm(_ _)m 名前空間を短くする作法なのはわかるのですがメモリやGCやコンパイラなど、どの辺に優しい感じですか? — Ryuji IWATA (@qt_luigi) April 5, 2017 qt_luigi さんからどうしてかを聞かれたので説明したいと思います。 golang では宣言した位置で初めて自動変数としてメモリが確保され、ゼロクリアされます。 for i := 0; i < b.N; i++ { var foo Foo bar, err := doSomething() if err != nil { continue } foo.v = bar fmt.Fprintln(ioutil.Discard, foo) } なので例えばこの様なコードで doSomething() が err を返した場合、
MySQLでランダムに20行をとるためには以下のようにやればいい。 SELECT * FROM table_name ORDER BY RAND() LIMIT 0, 20; 簡単に取得できるのはいいんだけど、行数が増えると劇的に遅い。どれくらい違うかって言うと10万行のデータベースでも↓ぐらい違う。 表示中の列 0 - 19 (20 合計, クエリの実行時間 0.0070 秒) SELECT * FROM table_name LIMIT 0 , 20 表示中の列 0 - 19 (20 合計, クエリの実行時間 1.1884 秒) SELECT * FROM table_name ORDER BY RAND() LIMIT 0, 20; なんでこんなに時間がかかるのかと調べてみると、どうも*を使うから遅いらしい。ということで、列名に主キーを指定して試してみる。 表示中の列 0 - 19
例のleftpad, GCを虐めるためとかコンパイラの最適化を確認するために用意する、「無駄に一時オブジェクト量産するクソコードの典型例」みたいな実装なので、こんな小さい関数のために、信頼できない人のコードを、実装を見るでも無く、依存性追加してたってことで、— INADA Naoki (@methane) March 24, 2016 ここから始まる一連の、モジュールの依存性に関する議論はなかなか興味深いが、自分的に気になったのは以下の一節 GCを虐めるためとかコンパイラの最適化を確認するために用意する、「無駄に一時オブジェクト量産するクソコードの典型例」みたいな実装 ソースを見てみようか。 left-pad/index.js at 0e04eb4da3a99003c01392a55fa2fdb99db17641 · azer/left-pad · GitHub なるほど一見するとクソコー
■ rails4 での assets:precompile の高速化 rails4 で assets:precompile を有効にするようにしてから、デプロイ毎に precompile しているとデプロイ途中にデザインが崩れたり、そもそもデプロイ時間が5分以上かかるようになってしまってリリースの高速化も何もあったもんじゃないなーということで、技術的に解決しておいた。 rails3 の頃は turbo-sprockets とかあって、こういうのを入れれば変更されたファイルだけを precompile するので、こういう gem あるのかなあと探していたら、そもそも本体に組み込まれているというのを知った http://yetimedia.tumblr.com/post/33320732456/moving-forward-with-the-rails-asset-pipeline ようは p
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
WordPress で利用する画像ファイルを最適化するメモです。 前回の Pngcrush に引き続き、jpegtran を使って今度は JPEG 画像を最適化してみます。 インストールおよび行ったテスト内容は以下に記載します。 jpegtranのインストール 利用している FreeBSD 8.3 の環境では、jpegtran コマンドは気付いたら入っていたので特に何もしませんでしたが、ない場合は以下のようにインストールすると良いと思います。 # cd /usr/ports/graphics/jpeg # make install clean CentOS の場合は libjpeg というパッケージに含まれているので yum でインストールします。 # yum -y install libjpeg インストールとしてはこんな感じです。 jpegtranで画像の最適化 JPEG 画像には E
MySQLコミュニティマネージャのMorgan Tocker氏による、テーブルサイズが大きくなるにつれてINSERTのパフォーマンスが落ちてきてしまうことを防ぐ様々な方法についてのまとめ。 今日は、パフォーマンス問題を引き起こす原因になる、サイズの大きいテーブルのパフォーマンスを改善することについて書いてみようと思う。このアドバイスのうちのいくつかは、たくさんのテーブルをまとめて大きくなっているデータベースにも適用できるが、大抵の場合、独立した大きなテーブルというのは特に問題になりやすいものだ。 一般的に知られていると思われるのは、テーブルを変更する時のスピードは、そのサイズが大きくなるにつれて遅くなることだ。以下の図は、一般的なB+ツリーインデックスのパフォーマンスを時系列で見たものだ。 このグラフは、MySQL@Facebookの記事から拝借したものだ。これは、insert buffe
2023-04-25 逆引きUNIXコマンド 逆引きUNIXコマンド/ターミナルで動作するビジュアルなストレージ使用容量確認コマンド 2022-12-12 Ubuntu/GUI操作のWakeOnLAN・gWakeOnLan Ubuntu 2022-12-05 Ubuntu/Ubuntu22.04でデスクトップのアイコンのサイズを変更する手順 2022-08-25 Xubuntu/画面が勝手にオフされる場合の対処方法 2022-08-11 Xubuntu 2022-07-26 Linux環境設定/Windowsネットワークの名前解決と共有フォルダアクセス方法 2022-07-25 Xubuntu/Thunarでssh(sftp)接続しファイルブラウズする手順 2022-07-20 ソフトウェア/デスクトップ/Plankの設定画面を表示する ソフトウェア/デスクトップ ソフトウェア 2022-
Ruby Weekly is a weekly newsletter covering the latest Ruby and Rails news. A few months ago, Ruby Inside wrote about using Spork with RSpec 2 and Rails 3 in order to get a more sprightly spec run. Unfortunately, using the techniques in the article with our fledgling codebase's test suite left us with somewhat disappointing results, so I decided to dig deeper and see if I could do better. Note: Th
この記事は古くなりました。新しい知見は下記を参照。aoking.hatenablog.jp 概要 全文検索エンジン Solr を使用していて、パフォーマンスチューニングに四苦八苦した話。 ここでは、検索時ではなくドキュメントの追加時についてのチューニングについて記してある。 更新自体は参照に比べて頻度が少ないが、参照はレプリケーションして負荷分散しやすい。 更新は整合性を保つために一台のマスターノードに対して行われるので更新はボトルネックになりやすいのだ。 定期的に IO 負荷が高くなる Solr を使っていると、一時的に猛烈に IO 負荷が高まる時がある。fsync になんと1分以上かかるような、猛烈な負荷だ。 これはインデクスのマージ時に起きる IO 負荷で、巨大なインデクス同士のマージだとその合計サイズ分の IO が発生することで IO 処理が専有されたままになっていた。 インデクス
We are constantly looking for ways to make our products faster so recently we spent some time optimizing UI graphics in Basecamp. With better support for CSS3 properties in the latest browsers and solid techniques for progressive enhancement, we began by eliminating some graphics altogether. We found that subtle gradients and drop shadows can be completely rendered with CSS properties and many tim
Facebook campus Photo by Marcin Wichary nori510です。 Facebookのソーシャルプラグインは読み込みが遅い。 そんな迷える子羊の私に天恵、天啓を与えてくれる方がいらっしゃいました。 iPhone研究室のOzk氏です。 iPhone 研究室 » たった一言で「いいね!」ボタンが爆速に!全ブロガーに必須の呪文。 読み込みの遅いいいねボタンを爆速表示する方法です。 Facebook ソーシャルプラグインを非同期読み込み化で爆速に! 方法はとっても簡単で、Facebook ソーシャルプラグインのページから追加し、ヘッダーなどに設置してあるJavascriptの読み込みコード(下記)に、『 js.async = true; 』を追加するだけ。 [html]<div id=”fb-root”></div> <script>(function(d, s,
結局、わかったことは、 次の4つ。 index から 実体へのシークは遅い。 すべてがindex内で完結するクエリーは早い。 limit をつけても where や order by すると意味がない。 indexを張るなら Using indexe をゲットできないと負けかな。 では、select で取得する値すべてに index を張りますか? 場合によっては可能ですが、テーブルに文字列なんかがふんだんに含まれていると難しいものがあり、現実的ではありません。 そこでこんな方法を提案します。2段階にわけてクエリーを打ちます。 A. task テーブルの 2008/6/5 〜 2008/6/18 のデータを開始日順にならべて、先頭5件だけ表示せよ。 select SQL_CALC_FOUND_ROWS * from task where task.task_starttime <= '20
最近Androidとの抗争が激化しているago(@kyo_ago)です。 jQueryはCSSセレクタを多用する特徴がありますが、jQuery内では実行ブラウザやCSSセレクタの記述によって呼び出されるブラウザAPIが変わり、それによって実行速度にも影響が出ます。 この記事では「セレクタAPIとはなにか」、「CSSセレクタの記述によって呼び出されるセレクタAPIの種類」、「高速なセレクタAPIを使用するための方法」、「高速なセレクタAPIが使われるかどうか確認する方法」などを紹介したいと思います。 (※この記事はJavaScript Advent Calendar 2011 (フレームワークコース) : ATNDの1日目の記事です) セレクタAPIとはなにか セレクタAPIとは「#hoge .huga」のようなCSSセレクタから、DOM上に存在する要素を取得するためのAPIです。 jQue
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
サーバのチューニングをする上でかなりやっかいなのがデータベース系。特にログファイルの量が膨大になると後から中身を見て問題を分析するのも一苦労という場合が。そんなときにこのMySQL用topコマンド「mytop」を使えば一体何が起きているのかがすぐにわかるので問題点の把握が容易になります。ベンチマークするときに併用すればかなり効率が良くなるのではないかと。 インストールと使い方は以下の通り。 まずは「mytop」から。以下が公式サイト。 mytop - a top clone for MySQL http://jeremy.zawodny.com/mysql/mytop/ マニュアルは以下にあります。 mytop - display MySQL server performance info like `top' インストールするにはSSHなどを使ってrootでログイン後、wgetでファイル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く