タグ

ブックマーク / qiita.com/haminiku (5)

  • たった1人から始める社内テストコード文化

    # -*- coding: utf-8 -*- from __future__ import absolute_import, unicode_literals # テストする関数 def add(a, b): return a + b # テストコード 関数名はtest_ から始めるのがpytestでのお作法 def test_add(): assert add(1, 1) == 2 assert add(1, 2) != 2 >>> $ py.test ../tests/test_add.py =============================================================================== test session starts ================================================

    たった1人から始める社内テストコード文化
  • 【Ruby vs Python】RailsとFlaskをベンチマーク比較 - Qiita

    Pythonの軽量WebフレームワークFlask導入にあたり、DBアクセスとテンプレート継承有りでRailsと比較しました。外部のWeb Framework Benchmarksと異なったRailsの方が早いという結果がでたので原因を特定して解消する記事です。 ベンチマーク結果 個人PJでの利用を想定しているので、用途に特化したベンチマークを書いて比較しました。結果Rails はFlask より1.493倍高速に動作 することが判明しました。Railsすんごいはやい。 Web Framework Benchmarksと異なる結果になった Web Framework Benchmarksと異なる結果になりました。Flaskが遅いのはコード側に問題がありそうなので検証していきます。 ベンチマーク条件 用途に特化したベンチマーク試験となっています。 DBアクセスして1レコード取得し結果をテンプレ

    【Ruby vs Python】RailsとFlaskをベンチマーク比較 - Qiita
  • SQL Alchemyを魔改造した - Qiita

    PyramidやFlaskの標準O/RマッパーであるSQL Alchemyを魔改造しました。 SQL Alchemyのsyntax問題 シンプルに記述できるように魔改造してみました。また速度面ではDBコネクションをThreadLocalStorageを使ってconnection poolingしてるので未使用と比較して8倍速くらいで動作します。ローカル環境だとselectクエリ1回8msから1msに高速化しました。 # -*- coding: utf-8 -*- from module.book import Book # select book1 = Book.get(1) books = Book.objects().filter(Book.price==2160).all() # insert book_rye = Book(pk=None, title="The catcher i

    SQL Alchemyを魔改造した - Qiita
  • Python3.5で実装されたasync/awaitを使って軽量スレッドの性能ベンチマーク - Qiita

    Python3.5でasync/awaitが追加されていたのでメモリ消費量とコンテキストスイッチのコストの観点でベンチマークを取ってみました。 async/await構文とは 非同期処理やノンブロッキングI/O処理を良い感じに書ける非同期処理のパラダイムにおける最先鋭の構文です。C#に実装されたあと、C++,VB,Node.jsに実装されついにPythonにもやってきた!という感じです。特徴はいままでThreadingで頑張って書いてた非同期処理が、より簡潔により強力に書けるようになります。軽量スレッドとはマイクロスレッド、ファイバーとも呼ばれるもので、「C10K問題」(クライアント1万台問題)と言われるI/O待ちによってクライアント数が多いとハードウェアの性能が生かしきれない問題の解決策の1つです。I/O待ちの際に高速にコンテキストスイッチして他のクライアントを捌くことでハードウェアの性

    Python3.5で実装されたasync/awaitを使って軽量スレッドの性能ベンチマーク - Qiita
  • Redis 本番障害から学んだコードレビューの勘所

    Redis不適切利用による問題は番運用が始まってから顕在化することが多く、時限爆弾みたいな存在です。事前に防ぐにはコードレビュー段階で叩くしかありません。 Redisはスクリプト言語と相性が良く、適切に利用するとRDBと比較し驚くほど高速なプログラムを組むことができます。昨年尊敬する先輩にコードレビューで斧100くらい(レビューコメント)投げられて血まみれになりつつ学んだことを、まとめて書いてます。概要は『消えても良いデータならRedis』 Redisのメモリが溢れたら... (この話は事実ではなくファンタジーです。) 深夜電話で叩き起こされました。どうやらアクセス障害みたいです。 何人かで実機確認したら、まったくゲームが遊べない。データ不整合怖いのでメンテIN。 ほどなくしてRedisが溢れメモリ不足で新規書き込みが出来なくなっていると判明。サーバのメモリ容量は64GByteでこれ以

    Redis 本番障害から学んだコードレビューの勘所
  • 1