15日目のものになります。こんばんわ!!だんだん寒くなってきましたね。私たちは普段GCPも多く利用しています。すると得体の知れない使用されていないリソースが大量に出来上がっていて、コストを圧迫する問題があったりします。cliにはそれを探すコマンドがありますが、goolgle-cloud-sdkのgcloudコマンドにはありません。そこで、それを作ることにしました。検索するようにしました。projectでは検索が遅いです。Cacheを使うことを選びました。パフォーマンス測定を行ってみることにしました。packageは、今回初めて使ってみました。cacheになります。今回はTuningはせずにDefaultのままで検証してみます。Packages試してみたのは、以下の3種類になります。様々なCache機構と連携できるようにするのがコンセプトのようです。既存のものを取り入れていくスタイルで開発されています。gocacheの注意点この中で一番クセがあります。大きさに高速対応したcacheです。パフォーマンスを出すために、並行処理で例えばsync.RWMutexでは書き込みがブロックされるためにそういったものを利用するのは避け、シャードを用いて適切に分散させてゴルーチンのブロックを避けられる工夫をしているそうです。シャードの数が比較的多く、ハッシュ関数が一意のキーに対して適切に分散された数を返す場合、ロックの競合はほぼゼロに最小化できるとのことでシャードを使用することにした理由だそうです。1.6はRCにありました。要求の処理時間を短縮するための最初の取り組みは、最新のRCバージョンに更新することでした。私たちの場合、パフォーマンスはほぼ同じでした。HTTPサーバーを提供するライブラリです。文書によると、合成テストでは標準のHTTPハンドラーの10倍の速度になる傾向があります。減らして高速化されているようで、検証結果も良いパフォーマンスが出ました。次のような特徴を持っているようです。(水平スケールが可能なオープンソースのグラフデータベース。HTTPに対応とのこと)で競合のないキャッシュが必要で開発された。https://github.com/dgraph-io/benchmarks/tree/master/cachebench/ristrettohttps://blog.dgraph.io/post/introducing-ristretto-high-perf-go-cache/高いヒット率のようです。ここに載っているベンチマーク結果を見ると、とてもヒット率が高く、スループットも良いようです。https://github.com/dgraph-io/ristretto#searchでは実際どうでしょうか。これらを試してみることにします。https://github.com/k-oguma/go-cache-benchmarksのようなものを作りました。測定ルールとフローとしては次のようになります。Get、およびDeleteの測定を行う以上のような測定内容となっています。それでは実際に計測をしてみます。Getが出来ることを確認しています。gocacheは少々特殊なので、コメントアウトしているものを参考にしてください。6.365s----------------------グラフにしてみます。以下は実行できた回数。一回あたりのメモリ割り当て回数となっていて、少ない方が良いです。予想外の結果になりました。今回はDefault設定で行い、全くチューニングしていませんので、それらでも変わるかも知れません。cacheみたいなCacheの連結も出来たりしていますので、高機能な方向へ向かうようです。go-cacheを利用させていただくことにしました。packageがありましたら、教えていただけると幸いです。そのうち調べてみたり自分でも作ってみたいと思います。upLoginユーザーは見つかりませんでした。