PythonでCSVを高速＆省メモリに読みたい - tkm2261's blog
今日はPython (Pandas)で高速にCSVを読むことに挑戦したいと思います。 Kaggleに参加するたびに、イライラしていたので各実装の白黒はっきりさせようと思います。 R使いが羨ましいなぁと思う第一位がCSV読込が簡単に並列出来て速いことなので、 なんとかGILのあるPythonでも高速に読み込みたいと思います。 ただ、この検証ではコーディング量が多いものは検証しません。 CSV読込は頻出するので、フットワークの軽さが重要です。（オレオレライブラリ嫌い） Pickleは早いけど。。。 結論はDask使おう！ 検証環境 データ 速度検証 pandas.read_csv() pandas.read_csv() (dtype指定) pandas.read_csv() (gzip圧縮) numpy.genfromtxt() pandas.read_csv() (chunksize指定 +
pixiv private isucon 2016 攻略 (1/5) : DSAS開発者の部屋
攻略記事一覧: pixiv private isucon 2016 攻略 (1/5) pixiv private isucon 2016 攻略 (2/5) pixiv private isucon 2016 攻略 (3/5) pixiv private isucon 2016 攻略 (4/5) pixiv private isucon 2016 攻略 (5/5) pixiv さんが社内で開催したプライベート ISUCON の AMI を公開してくれたので、手順を残しながら攻略していきます。 ISUCON6出題チームが社内ISUCONを開催！AMIも公開！！ リポジトリ この記事の対象読者は途中で何をすればいいかわからなくなってしまう ISUCON 初心者です。 Go を利用して攻略していきますが、他の言語で参加する場合でも考え方などは参考になると思います。 最低限の初期設定 ssh の公開
Impalaのパフォーマンスガイドラインとベストプラクティス(翻訳) - Qiita
Clouderaのドキュメントに書かれているImpala Performance Guidelines and Best Practices が非常に素晴らしい内容なので翻訳した。 内容は Apache Impala (incubating) (以下 Impala) をターゲットとして記述しているが、パーティション設計などについては Hive にそのまま適用できる内容なので、Impala を使用していない人でも読んで損はないと思う。 環境 CDH 5.7.0 (Impala 2.5.0) 本文 このドキュメントは、Impalaを利用するCDHクラスタのための、計画、実験、パフォーマンスチューニング時に利用可能なパフォーマンスガイドラインとベストプラクティスです。この情報は全て、Impala ドキュメンテーションの他のページでより詳細に記載されているものです。これらの情報はクックブックとして
Pythonによる機械学習の最前線
トップエスイー実践プログラミングセミナーシリーズ 「TensorFlowによるニューラルネットワーク入門」 で使用した資料です。 http://topse.or.jp/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%82%BB%E3%83%9F%E3%83%8A%E3%83%BC%E3%80%8Ctensorflow%E3%81%AB%E3%82%88%E3%82%8B%E3%83%8B%E3%83%A5%E3%83%BC%E3%83%A9%E3%83%AB%E3%83%8D/ 2016/11/17 ver1.0 公開 2016/11/28 ver1.1 Update 2017/01/21 ver1.2 Update 2017/01/24 ver1.3 Update
MySQL5.7 / RDS / Aurora / Cloud SQL の性能比較 | 外道父の匠
CloudSQLの価格は実戦的という意味で、per Dayの価格を24hourで割った価格にしています。 メモリは2GBあれば検証としては十分なので格差は関係ありません。 IOPSはEBSならGeneral Purposeの1000GB*3で最大確保しています。 その他、ネットワーク周りなどポイントがあれば都度、補足していきます。 ベンチマークのデータ 今回、採取した全データはこちらになります。一部、目的に対して不要と判断したら省略しています。まぁ、こんなオレオレメモデータを見ても楽しくないでしょうから、１つ１つ考察していきましょう。 手法について 私がよくやる計測方法なのですが、innodb_buffer_pool_size がデータ容量より大きい健全な状態と、最小の16MBで過負荷ストレージを演出し、それぞれで参照／更新を別々にランダムアクセスをすることで、最初のボトルネックを炙り出し
Webサーバのチューニング
2010/12/10の勉強会で発表。 主催者ページ↓ http://d.hatena.ne.jp/oranie/20101212
nginxのパラメータチューニングとh2o - Qiita
(追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調
無料で開いたタブのメモリ消費量が確認できるFirefoxアドオン「Tab Data (+Memory usage)」
どのタブがメモリをどれだけ消費しているか一目で分かる無料のFirefoxアドオンが「Tab Data (+Memory usage)」です。メモリ消費量上位5位までのタブの表示や、不要になったメモリ領域を解放するガベージコレクションを実行する機能も付いています。 Tab Data (+Memory usage) https://addons.mozilla.org/ja/firefox/addon/tab-data/ 上記サイトの「＋ Add to Firefox」をクリック。 「今すぐインストール」をクリック。 「Tab Data がインストールされました。」と表示されたらインストールの完了です。 Firefoxのタブにメモリ消費量が表示されます。なお、20MB以上のメモリ消費量のタブは赤色で表示されます。 開いているタブの中で、メモリを多く消費しているタブを確認する場合、ブラウザ右上の
ActiveRecordを速くしたいだけの人生だった - Qiita
Help us understand the problem. What is going on with this article? Rails3.2からRails4.2に上げたらActiveRecordが遅くなったので、どうやって調査して、どのように対処したかを語ってみたい。 とても長いので、ダルい人は最初と最後だけ読めばよいです。 TL;DR 環境: Ruby 2.1.5 ARオブジェクトを大量に(ざっくり750kくらい)loadするバッチ処理 3.2系での実行時間は約480sec、 4.2系では約2900sec 約6倍の性能劣化 原因: preloadで性能劣化してた CollectionProxyの生成周りで遅くなってた Rails4からARオブジェクトの1attribute毎にObject生成するので遅い GCの時間も増えた 調査方法: Githubのcommit、Issueを
海の向こうにあるZabbixサーバの表示をWebサーバのチューニングだけで高速化する - Qiita
海外で展開しているサービスがある関係上各サーバの監視に利用しているZabbixサーバも海外にあるのですが、ほとんどチューニングされておらず、ZabbixのWebUIの画面をロードするのが遅くて遅くてしょうがないので頑張ってチューニングしてみた時の話です。 また、チューニング前後でダッシュボードのロードにかかった時間を計測してみました。 準備 まず、Google ChromeのDeveloper Toolsでキャッシュを無効にします。 チューニング前の状態 ZabbixはよくあるApache+mod_phpによる構成です。この状態でZabbixのダッシュボード(dashboard.php)にHTTPSでアクセスするとブラウザ左下のステータスバーにページのロードにかかった時間が表示されます。 2.7秒かかっています。すごく遅いです。体感でわかるくらい遅いです。 Zabbixが定期的にポーリング
nginxパフォーマンスチューニング〜静的コンテンツ配信編〜 - Qiita
今回はHTMLやCSS、Javascriptといった比較的軽量な静的コンテンツの配信をnginxでやるケースに絞ってチューニングする際のポイントについて紹介しようかと思います。 (注：worker_rlimit_nofileやsysctl.confのネットワーク周りの設定のような定石的なチューニングについてはあえて解説しないのであらかじめご了承ください。) コンテンツをgzip圧縮する 何はともあれgzip圧縮です。ネットワーク帯域に比べればCPUリソースなんて安いものです。 しかし、多くの場合これだけでは十分ではありません。何故ならnginxはデフォルトではContent-Typeがtext/htmlのコンテンツしか圧縮しないためです。圧縮対象のContent-Typeを増やすにはgzip_typesを使います。 単純なWebサイトであれば上記の設定で十分ですが、場合によってはappli
Webフロントエンドに従事するお前らはいい加減高頻度イベントとレイアウトとスタイリングの付き合い方を考えろ - Qiita
もうなんかこの際マジで言わせていただくんですけど、知ってるか知らないか分かりませんが世の中にはすごい頻度で呼ばれうるDOMイベントって言うのがいくつかあるわけですよ 例えば scroll mousemove, touchmove devicemotion 辺りですよ。 で、高頻度で呼ばれるって言うことは必然的に処理量が増えるって分かりますよね？？？？？while(1) {}じゃないとはいえUIスレッドに十分影響を与えうる頻度で呼ばれる訳です。分かりますよね？？？？？？？？ そうなると当然そのイベント内で重い処理を行えば人間が認識できるレベルでのレスポンス遅延が起きるっていうのはご理解できますよね？ 重い処理っていうのはまぁ想像出来るとは思うんですが例えばよくあるのが DOMのレイアウトプロパティへのアクセス offsetTop、offsetLeft、offsetWidth、offsetHe
GoogleのHTTPロードバランサーの破壊力があり過ぎる #gcpja - Qiita
そもそもGoogle Compute Engineのロードバランサー、GCE LBは、1インスタンス・1グローバルIP・ウォームアップなしでいきなり100万リクエスト／秒を捌けてしまう謎性能を備えていて、既存の他社クラウドのLBだけこれで置き換えたい！ という声もちらほら聞かれるほどの強力LBサービスであった。 From Compute Engine Load Balancing hits 1 million requests per second! そして今回、正式公開ではないLimited Preview版ではあるものの、GCE LBの新機能としてHTTP Load Balancingが発表された。その性能と機能の破壊力があり過ぎるので、GCPブログ記事のリンクをシェアするだけではあまりにもったいない！ と思い、要点を訳してみた。 DNSに頼らない、1グローバルIPによるUS、EU、A
GlusterFSのパフォーマンス関連トピック
GlusterFSのパフォーマンス関連トピック Presentation Transcript GlusterFSの パフォーマンス関連トピック もりわかかかずお 構成例 10GbEスイッチ x 2 10GbE接続 10GbE / 1GbE接続 ・・・ ストレージノード x 4 クライアントノード 群 s213s211 s212 s214 GlusterFS サーバ GlusterFS クライアント Native Clientイメージ gluster srv. gluster cli. gluster srv. gluster srv. gluster srv. glusterfs独自プロトコル FUSE Native Clientのネットワーク転送量 ● レプリケーション個数分、クライアントは各サーバに writeをおこなう ● サーバ間の通信は基本的に発生しない ● 例: レプリケーシ
はてなブログにおけるページ表示速度改善の取り組みについて - Hatena Developer Blog
こんにちは、id:hakobe932です。はてなブログではユーザ体験の改善のために、ページ表示速度を向上させるための様々な取り組みを行っています。このエントリーでは、はてなブログで行っている、ブラウザキャッシュの活用、JavaScriptのページ最下部での読み込み、JavaScriptの圧縮、という3つの取り組みについて解説します。 ブラウザキャッシュの活用 同じ内容のJavaScriptやCSSを、ページを表示するたびにダウンロードすると、余分なHTTPリクエストが発生しますし、読み込み時間がかかります。 ブラウザのキャッシュを利用できれば、余分なリクエストを減らすことができます。はてなブログでは、なるべく長い間ブラウザにキャッシュを保存するために、JavaScriptなどの一部の種類のファイルのレスポンスに、以下のようなヘッダを指定しています。 $ curl -I http://hat
Nexus 7（2012）のファイルシステムを「F2FS」に変更してストレージ性能を高める方法が公開 | juggly.cn
Nexus 7（2012）のファイルシステムをNANDフラッシュ用に開発されたF2FS（Flash-Friendly File System）に変更して、端末のI/O性能を高めようという実験的な開発作業がXDA Developersで進められています。 F2FSは、Samsungが中心となって開発したSSDやeMMC、SDメモリなどのNAND型フラッシュメモリに特化したファイルシステムで、Linuxカーネル3.8でメインラインにマージされました。特にNANDフラッシュへのランダムライトで他のファイルシステムよりも良い性能を発揮するとされています。ちなみに、F2FSはMoto Xなど一部のAndroid端末では既に採用されています。 ストレージのI/O性能が改善されるとプチフリといった現象が軽減され、体感的にも動作が軽くなった印象を受けるはずです。 XDA Developersで公開された導
MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ
もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました（と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです） 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 –
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
#plackcon で喋ってきました - blog.nomadscafe.jp
それほど成果のある内容ではありませんが、strace芸の一つとしてみて頂ければ幸いです 主催のYappo++。発表者のみなさまありがとうございました~。 スライド表紙のダンボーは、ISUCON3の副賞でもらった。データホテルのロゴ入りロボダンボーです。ちゃんと動きました！ \n\nそれほど成果のある内容ではありませんが、[strace芸](http://b.hatena.ne.jp/y_uuki/20131120#bookmark-170026522)の一つとしてみて頂ければ幸いです\n\n主催のYappo++。発表者のみなさまありがとうございました~。\n\nスライド表紙のダンボーは、ISUCON3の副賞でもらった。データホテルのロゴ入り[ロボダンボー](http://www.vstone.co.jp/products/danboard/)です。ちゃんと動きました！\n\n \n\n \
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブパフォーマンスの基礎とこれから
