Introducing a Technology Preview of NGINX Support for QUIC and HTTP/3 - NGINX
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
bash で TCP 通信 - Qiita
使い道あるかわからないけれど、/dev/tcp/{hostname}/{port} で TCP 通信できる。（※ただし bash に限る？） #!/bin/bash # 使い方 # $ ./http_client.sh host path # http://host/path に GET 投げる exec 3<> /dev/tcp/$1/80 echo -e "GET $2 HTTP/1.0\n\n" >&3 cat <&3 $ ./http_client.sh qiita.com / HTTP/1.1 200 OK Server: nginx/1.0.9 Date: Wed, 22 Feb 2012 01:19:59 GMT Content-Type: text/html Content-Length: 151 Last-Modified: Tue, 01 Nov 2011 15:07:
gRPC WebがGAになったのでそろそろ理解してみる
2018/10/23に「gRPC-Web is Generally Available」というタイトルでgRPC-WebがGAになった事がgrpc公式ブログで発表されました。 https://grpc.io/blog/grpc-web-ga 翌日にCNCFのブログでも「gRPC-Web is going GA」というタイトルで同等の内容が公開されました。 https://www.cncf.io/blog/2018/10/24/grpc-web-is-going-ga/ 今までブラウザからgrpcが使えるgRPC-Webの存在は知っていましたが、ちまたで実際に利用しているというのもあまり聞かなかった為ほとんど気にしていませんでした。 この度GAになったのをきっかけにエコシステムができあがってくれば間違いなくパラダイムシフトになると思いちゃんと検証してみました。 この記事で書く事 gRPC-W
nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita
nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser
nginx の worker_connections は worker 当たりの同時接続数だと思ってたけどどうも違うっぽい - noob
※2014-12-18 追記※ はてブとかtwitterがついててちょっとビックリしてます． そしてtwitterで貴重なご意見をいただきました． 1024以下でもう少し増やすとどうなるかなぁ。workerに偏りがあってエラー出てるのかも。例えば8*768とか。 / “nginx の worker_connections は worker 当たりの同時接続数だと思ってたけどど…” http://t.co/5aLNa0VeOy— MATSUMOTO, Ryosuke (@matsumotory) 2014, 12月 16 なるほどー． ということでworker_processes 8, worker_connections 768でざっくりですが早速試してみました． 結果，worker_connections are not enoughエラーは見られなくなったように思います． # というの
nginx最大パフォーマンスを出すための基本設定 | Node.js技術
解説 worker_processes auto; - Nginx本体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
