高速なCommon LispのWebサーバ「Woo」を作りました - 八発白中
ここ一ヶ月ほど手掛けていたCommon LispのWebサーバ「Woo」が一応の完成に至りましたのでお知らせします。Clack-compatibleなAPIになっており、現状運用しているClackのWebアプリケーションでそのままお試しいただけます。 高速であることを最優先に設計しており、Hunchentootの4倍、Wookieの3.5倍高速に動きます。現状ではCommon Lispのサーバでは最速ではないでしょうか。*1 Woo by fukamachi | GitHub Benchmarks いくつかのCommon Lispのサーバと、Node.js、Go、Pythonのサーバを比較してみました。縦軸はreq/secで、高いほうが多くのリクエストを捌けることを意味します。 Wooは、PythonのTornadoより約9.5倍、Node.jsの約1.9倍のリクエストを捌けます。一方、G
「PostgreSQL 9.4」がリリース、データ型にJSONBをサポート、GINインデックスの性能が改善
最新版では、新たなデータ型として「JSONB」（バイナリJSON）を追加しており、データストアのリレーショナル／非リレーショナルの選択は不要で、両方を同時に利用できる。JSONBは、高速なルックアップと、Generalized Inverted Indexes（GIN）を利用した簡易な検索クエリ記述をサポートし、JSONデータを一般的なデータベースと同等か、それ以上のパフォーマンスで扱える。さらに、テーブルとドキュメントの容易な統合を実現する。 ほかにも、複数マスタのPostgreSQLクラスタ作成をサポートする、双方向レプリケーションのように利用可能な、レプリケーションの読み取り／フィルタリング／操作に対応するAPIの提供を行う。また、レプリケーションスロットや時間差レプリカ、レプリカサーバにおける管理機能などの向上も行っている。 なお、GINインデックスの進化によって、インデックスサイ
Linuxbrew のススメ - Qiita
2019/02/04 追記 本家 Homebrew 2.0.0 にて Linuxbrew を merge して正式にサポートすることになりました。やったね。 追記終了。 What's Linuxbrew "Linuxbrew is a fork of Homebrew, the Mac OS package manager, for Linux." by Linuxbrew というわけで OS X の Homebrew を Linux 環境でも使えるようにしたものです。 Why Linuxbrew Debian や RHEL系(CentOS など) は安定性を重視していることにより公式の package が古くてアワワってなりませんか？ その度に公式の開発版を持ってきたり、公式ではないリポジトリ追加したり、非公式 package を探したりして、そして package の依存関係がゴチャっ
systemdを始めよう
Linux女子部08「Docker勉強会」 http://connpass.com/event/6318/ で使用予定の資料の一部です。 変更履歴 ver1.0 公開 ver1.1 参考資料追加、微修正 ver1.2 pid namespaceの例を変更、微修正 ver1.3 Fedora20 + Docker1.0 に手順を変更 ver1.4 dm-thinprovisiongのイメージを直接操作する手順を復活 ver1.5 LVMによるdm-thinprovisioningの図を追加 ver1.6 微修正 ver1.7 LVMでのdm-thin snapshotは変更できない旨を記載 、スナップショット作成の図を微修正 ver1.8 「LVMでのdm-thin snapshotは変更できない旨」は間違ってたので、snapshotを有効化する方法を追記
Unicornの2倍のパフォーマンスを実現したRackサーバ「Rhebok」をリリースしました - blog.nomadscafe.jp
“Hello World”なベンチマークでUnicornに比べ2倍高速に動作するRackサーバをリリースしました。 rubygems: http://rubygems.org/gems/rhebok github: https://github.com/kazeburo/rhebok PerlのGazelleをベースに作っています。Rackアプリケーションの運用経験がほぼないので、機能不足があると思います。issue等で教えて頂ければ幸いです。 なぜ高速に動作するアプリケーションサーバが必要なのか Unicornは高速に動作します。多くのアプリケーションにとっては十分でしょう。それでもRhebokでさらに上のパフォーマンスを出そうとしたのは、技術的なチャレンジの他に以下のようなアプリケーションで高速なアプリケーションサーバが必要とされると考えているからです。 ソーシャルゲーム、広告サーバ、
Amazon EC2 Container Service (ECS)を試してみた | DevelopersIO
2104/12/20更新 : Dockerの動作に一部不具合があり、ECS-Optimized Amazon LinuxのAMIが更新されました。「3. ECS-Optimized Amazon Linuxの起動」のAMI IDを変更しました。 ども、大瀧です。 AWSのイベント、re:Invent 2014で発表されたDockerコンテナを扱うサービスEC2 Container Service(ECS)のプレビュー申請が通ったので、ドキュメントのチュートリアルを試した様子をレポートします。 1. IAMロールの作成 まずは、Dockerコンテナを実行するEC2インスタンス(ECSインスタンス)からECS APIにアクセスするためのIAMロールを作成します。IAMの管理画面から[Roles] - [Create New Role]で作成ウィザードを表示し、ロール名に「ecs-ec2-rol
CentOS 7のログ管理「journald」
今回は、CentOS 7で採用されている新しいログ管理の仕組み「journald」を取り上げます。またjournaldとrsyslogとの連携やシステム全体に渡って様々なログを収集するsosreportについても簡単に触れます。 CentOS 7におけるログ機構「Systemd Journal」を使いこなす CentOS 7は、ログの管理を行う新しい仕組みが導入されています。従来のCentOS 6系では、長年親しまれてきたsyslogがベースのログ管理手法が採用されていましたが、CentOS 7からは、ログに関するより細かい指定や操作を行うことができるようになっています。CentOS 7でのログ管理は、systemdが担当しています。サービス名は、「systemd-journald.service」です。一般的には、「journald」と呼ばれています。CentOS 6までのsyslogで
オレオレRailsアプリを支えるインフラの作り方 - くりにっき
はじめに これは Ruby on Rails Advent Calendar 2014 - Qiita の19日目です 18日目 @yancya さんの Rails でシングルじゃないテーブル継承 - Qiita でした 19日目：オレオレRailsアプリを支えるインフラの作り方 最近では Heroku などのPaaS*1 も普及してインフラのことを知らなくても簡単にアプリを公開することができるようになりました。 しかしトラブルシューティングやパフォーマンスチューニングなどを行うにはアプリケーションコードだけで完結することは少なく、全体像を把握する必要があります。Railsアプリケーションの裏でどんな構成で動いているかを知っておくかは重要なのでざっくりと紹介したいと思います。 書かないこと Railsアプリを作る上でのノウハウ 便利なgemや外部サービスの紹介 *2 監視 アラート検知 モ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
