タグ

pythonとperformanceに関するmoqadaのブックマーク (13)

  • Python Async (ASGI) Web Frameworks Benchmark

    This is a simple benchmark for python async frameworks. Almost all of the frameworks are ASGI-compatible (aiohttp and tornado are exceptions on the moment). The objective of the benchmark is not testing deployment (like uvicorn vs hypercorn and etc) or database (ORM, drivers) but instead test the frameworks itself. The benchmark checks request parsing (body, headers, formdata, queries), routing, r

  • Faruk Akgul - Python Web Frameworks Benchmark

    Falcon is a Python web framework developed by Rackspace. It also has a benchmarking tool to test the framework against other frameworks. Out of curiosity, I wanted to see how other frameworks perform in this benchmark. Frameworks of this benchmark: bottle CherryPy Django Falcon Flask Pecan: This was already part of Falcon's default test. I had never heard of it. web.py Werkzeug: More like a utilit

  • Maximum Throughput

    (Baseline costs of web frameworks) Brian McDonnell, CTO at PageFair.com Twitter: @mcdonnellb Github: github.com/brianmcdonnell Minimum WSGI Implementation Add a Framework to the Mix What's the cost before it hits your code? What computation is occurring? Anyone with high-frequency, low computation requests Analytics (e.g. PageFair) Tracking pixels Real-time geo-positioning data Testing Python Web

  • ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋

    ISUCON4 予選1日目に、 lily white というチームで参戦してきました。 試合中に 62000 点は出していたのですが、最終的に提出したスコアは 60344 点でした。 以降、予選終了までと、その後に気づいたさらにスコアを上げる方法について書いていきます。 実際の提出時のコードは methane/isucon4q-go リポジトリの "final" タグを見てください。 準備 (~前日) 予選方式が発表された時点で、 isucon3 予選と同じ方式だったので、有効な作戦もほぼ同じになる事が予測できました。 具体的には以下のとおりです。 PIOPS な EBS を使わないので、性能が不安定なディスクがネックになる問題は無いでしょう。 1インスタンスのみを使うということから、ネットワーク帯域がネックになる可能性も無いはずです。 ほぼ確実に CPU ネックな問題が出るはずです。 ア

    ISUCON4 予選で workload=5 で 88000点出す方法 (lily white 参戦記) : DSAS開発者の部屋
  • wsgi, Bottle, Flask の速度差 - Qiita

    ISUCON の季節ですね。 ISUCON では慣習的に各言語で代表的なマイクロフレームワークが使われるのですが、 Python では今のところ Flask がずっと使われています。 Flask は確かに、簡単なサンプルアプリを書くときの見た目はマイクロフレームワークになっています。 しかし、構造的には沢山のフック、シグナルがあったりしていて、重量級の設計になっています。 Flask 体と Werkzeug を合わせると数万行のサイズです。単なる Hello World アプリでも、数十の関数呼び出しが裏で動いています。 Bottle も、 Flask と同じくマルチスレッド対応で、スレッドローカルを使ったコンテキストスタックがある、拡張機能もあるフレームワークですが、構造は Flask よりも大分質素です。 ソースコードも1ファイル3000行代で、その分フレームワークのオーバーヘッドも

    wsgi, Bottle, Flask の速度差 - Qiita
  • Benchmark uWSGI vs gunicorn for async workers

    All of the WSGI benchmarks I found were pretty outdated or didn't include async results, so I decided to do some benchmarking myself. I know there's other options for running python WSGI applications, but I settled on just 2: gunicorn, which has the advantage of being pure-python and uWSGI, which has the advantage of being pure-C. I ran these tests on a m1.large Amazon AWS EC2 instance using the l

    Benchmark uWSGI vs gunicorn for async workers
  • Nicholas Piël » Benchmark of Python Web Servers

    It has been a while since the Socket Benchmark of Asynchronous server. That benchmark looked specifically at the raw socket performance of various frameworks. Which was being benchmarked by doing a regular HTTP request against the TCP server. The server itself was dumb and did not actually understand the headers being send to it. In this benchmark i will be looking at how different WSGI servers pe

  • Python 製の負荷試験ツール Locust を試してみた - co3k.org

    Web の負荷試験ツールとして代表的なのは Apache JMeter だと思いますが、 Apache JMeter 自体が結構重いのと、テストシナリオの保守が GUI ツールでは結構ツライ (シナリオファイルは XML ですが、とても人間が手を加えられるような代物じゃない) なあということで代替となるものを探していました。 で、心惹かれたのが以下のツールです。 Gatling Tsung Locust Gatling は非常によさそうなんですが、うーん要 JDK か……あとは複数台から負荷を掛けることができないというのもちょっとマイナスですね。まあどっちもどうにかしようと思えばどうにかなるポイントではあるんですけど。 Tsung は Erlang 製で、仕事で Erlang 使う可能性も出てくる気がするのでこれで慣れ親しんでおくのもいいかなーと思ってシナリオファイルを覗いてみたら ド直球

  • Pythonコードのプロファイリング - shkh's blog

    普段、Pythonのコードは何となく速かろうという、言ってみれば勘で書いているのだけど、その勘とやらは往々にしてウンコードを生むものである。そこで、プロファイラを使っていきたいと思う。 使えそうなツール そういうわけで、いくつか使えそうなツールをリストアップした。 経過時間のプロファイラ ツール名 メモ profile ビルトイン, ピュアPythonの決定論的プロファイラ cProfile ビルトイン, C拡張の決定論的プロファイラ line_profiler 行単位の決定論的プロファイラ Plop 統計的プロファイラ, Dropboxの人が作ってる statprof 統計的プロファイラ, 開発停止? yep 拡張モジュール用の統計的プロファイラ, バックエンドにgoogle-perftools メモリのプロファイラ ツール名 メモ memory_profiler 行単位でメモリ消費量の

    Pythonコードのプロファイリング - shkh's blog
  • pytestを使ってカバレージとか取りながら分割実行してテスト実行時間を短縮する - Qiita

    $ AUTOPEP8_COVERAGE=1 py.test -n4 --cov-config .coveragerc ¥ --cov-report html --cov-report xml --cov-report term-missing ¥ --cov project test/test_project.py

    pytestを使ってカバレージとか取りながら分割実行してテスト実行時間を短縮する - Qiita
  • Dropbox のスケールとか

    Python なサービス みんな大好き Dropbox のスケールとかメモ。以下のページ辺りからピックアップ。Parted? みたいなので、続編がでたら追記するかも。 Scaling lessons learned at Dropbox, part 1 (comment) Dropbox - Startup Lessons Learned (slideshare) Dropbox -Yコンビネーターが生んだスタートアップの軌跡と未来 - スケール関係ないですが、2006 年当時はオンラインストレージサービスがいっぱいあったようで、VC から資金調達したときのやり取りがおもしろい VC "クラウドストレージサービスなんて腐るほどある" Drew "なにか使ってるのありますか?" VC "NO" Drew "..." 完璧で、スケーラブルで、クロスプラットフォームなクラウドストレージ!当時、プ

    Dropbox のスケールとか
  • PythonSpeed

    PythonSpeed 多くの人がPythonプログラムの速度について心配を持っています。でもPythonを使わないと、堪らないくらい実行速度上のロスがありますよね? 中には「なんだ、インタプリタのスクリプト言語か、まるっきり遅いや」なんて結論づける人もいます。また、Pythonを実際に試してみて、実行効率が十分なことに気づく人もいます。でも時には、 とっても遅いプログラムができあがることもあります。 実行速度がそんなに重要?ホントに? 多くの人が必要以上に速度に取りつかれていて、このような種類の問題では、Cが優れた実績を示していることから、全ての面で優れた言語だと考えています。別の人々は、開発の速度がより重要で、Pythonを選ぶのはそのような時に限り、まあそれなりの速度だろうと考えています。そして頻繁に、期待を超えた速度で動いていることに驚かされています。時には、同じ開発時間を費やした

    moqada
    moqada 2008/10/18
    Python の実行速度について。
  • Python Performance Tips (Python パフオーマンスTIPS)

    Python Performance Tips このページはPythonプログラムの実行効率を改善するさまざまなTipsやトリックの紹介に特化しています。誰から得た情報であっても、その情報源を紹介するつもりです。 "fast python"ページをはじめて書いた1996年以降も、Pythonは著しく変化してきました。このことは、幾つかの規則も変化しているということを意味しています。そこで、他の誰かがこのページのメンテナンスを手伝ってくれるという期待をもって、ページをPython wikiに移動させました。 注意:これらのTipsはいつでも、読者のアプリケーションや、実際に使用するバージョンのPythonで盲目的に受け入れるだけでなく、実際に試してみることができます。 これらの新しく独自に書かれたパッケージ、例えば Pyrex 、 Psyco 、 Weave や PyInline のようなも

  • 1