Closed txxxxc closed 2 months ago
nginxでrootに指定したディレクトリが存在しない場合はどうなりますか?
Nginxで`root`ディレクティブに指定したディレクトリが存在しない場合、以下のいずれかの状況が発生します。
1. **404 Not Found エラー**
* Nginxは、指定されたディレクトリ内でリクエストされたファイルを探そうとします。
* ディレクトリが存在しないため、ファイルも見つからず、クライアントに404 Not Foundエラーを返します。
2. **403 Forbidden エラー**
* Nginxの設定によっては、存在しないディレクトリへのアクセスを許可しない場合があります。
* この場合、クライアントに403 Forbiddenエラーを返します。
**対処法**
* **ディレクトリを作成する:** `root`ディレクティブで指定したディレクトリが存在しない場合は、そのディレクトリを作成します。
* **設定ファイルを確認する:** `root`ディレクティブのパスが正しいか、設定ファイルを確認します。
* **Nginxを再起動する:** ディレクトリを作成または設定ファイルを修正した後は、Nginxを再起動して変更を反映させます。
* **エラーログを確認する:** Nginxのエラーログを確認して、詳細なエラー原因を特定します。
**補足**
* `try_files`ディレクティブを使用すると、指定されたファイルが存在しない場合に別のファイルを返すように設定できます。
* `error_page`ディレクティブを使用すると、特定のエラーコードに対してカスタムエラーページを表示するように設定できます。
**例:**
```nginx
server {
listen 80;
server_name example.com;
root /var/www/html;
location / {
try_files $uri $uri/ =404;
}
error_page 404 /404.html;
}
この設定では、/var/www/html
ディレクトリにファイルが存在しない場合、404.html
というカスタムエラーページを表示します。
え、publicディレクトリ作らなアカンのダルい説
いったんroot指定して、public勝手に作られるか調べてみる
いや、言うて普通に/public作るだけか
nginxのconf、いちいちremoteで変えるの面倒すぎるからsymlinkはるか
なんかバグりました
isucon@ip-10-0-1-227:~$ sudo ln -sfv webapp/nginx/isucondition.conf /etc/nginx/sites-available/isucondition.conf
'/etc/nginx/sites-available/isucondition.conf' -> 'webapp/nginx/isucondition.conf'
nginx: [emerg] open() "/etc/nginx/sites-enabled/isucondition.conf" failed (2: No such file or directory) in /etc/nginx/nginx.conf:24
nginx: configuration file /etc/nginx/nginx.conf test failed
相対パスでlnするのは悪っぽい symlink相対パスで死ぬ理由わかった。なんとなく分かった。
$ ln -s [参照先:シンボリックリンクを置きたいディレクトリからみたリンク先の相対パス] [参照元:シンボリックリンクを置きたいディレクトリ]
なんかnginx関係ない説ある
/assetsとかにある画像とかも片手間でキャッシュしたい
それそうかって感じではある
Q. 画像をsql内に保存するのと、nginxでpublicなどのディレクトリ保存するときの違いと、メリット・デメリットを教えて下さい。
データの一元管理: 画像とそれに関連するデータ(例えば、製品情報やユーザー情報)を同じデータベースに保存できるため、管理が容易になります。
トランザクションの整合性: データベースのトランザクション機能を利用して、画像と関連データの更新を原子的に行えます。これにより、データの不整合を防ぐことができます。
バックアップと復元: データベースのバックアップ機能を利用して、画像を含めた全てのデータをまとめてバックアップ・復元できます。
## デメリット
データベースの肥大化: 画像は一般的にサイズが大きいため、データベースのサイズが肥大化し、パフォーマンスに影響を与える可能性があります。
パフォーマンスの低下: 画像の取得にSQLクエリが必要となり、大量の画像を扱う場合、パフォーマンスが低下する可能性があります。
スケーラビリティの制限: データベースのスケーラビリティは、画像のようなバイナリデータを扱う場合に制限を受ける可能性があります。
# Nginxでpublicディレクトリに保存する
## メリット
高速な配信: Nginxは静的ファイルの配信に特化しており、画像を高速に配信できます。
スケーラビリティ: Nginxはスケーラビリティが高く、大量の画像リクエストを効率的に処理できます。
データベースの負荷軽減: 画像をデータベースから分離することで、データベースの負荷を軽減できます。
## デメリット
データの分散: 画像と関連データを別々に管理する必要があるため、管理が煩雑になる可能性があります。
トランザクションの不整合: 画像と関連データの更新を別々に行う必要があるため、データの不整合が発生するリスクがあります。
セキュリティ: publicディレクトリに保存された画像は、適切なアクセス制御を行わない限り、誰でもアクセスできてしまう可能性があります。
どちらを選ぶべきか?
どちらの方法を選ぶべきかは、アプリケーションの要件によって異なります。
小規模なアプリケーションで、画像の数が少ない場合: SQLに保存する方が、管理が容易になるため、適している場合があります。
大規模なアプリケーションで、大量の画像を扱う場合、またはパフォーマンスが重要な場合: Nginxで配信する方が、高速な配信とスケーラビリティの面で優れているため、適している場合があります。
その他の選択肢
オブジェクトストレージ: Amazon S3やGoogle Cloud Storageなどのオブジェクトストレージサービスを利用することも選択肢の一つです。オブジェクトストレージは、スケーラビリティが高く、大量の画像を効率的に保存・配信できます。
CDN: コンテンツデリバリーネットワーク (CDN) を利用することで、画像を世界中のキャッシュサーバーに配信し、より高速な配信を実現できます。
とりあえずpath名はpublic/imagesにしますか
なんかキャッシュされないんですけど!! てかexpiresを追加したらどうなるかあんまり知らん
^~ は前方一致やから正規表現使えない説ありますわ
location ^~ /(.*\.ico|index\.html|.*\.js|.*\.svg|.*\.css)$ {
なんかパスの解決クソだるそうではある https://muziyoshiz.hatenablog.com/entry/2019/06/30/203903
いったんこの説合ってたぽい
いったん~*にしたら治りました普通に
その後curlでhttp2できひんやん問題は、
curlの--http2
が動かなくて、--http2-prior-knowledge
ならいけました。意味わかりません。
https://stackoverflow.com/questions/69779585/cannot-see-output-of-http2-request-using-curl
--http2の場合、いったんhttp1でサーバー側に「http2で通信できる?」って聞くプロセスを踏むから、http2しか対応してないと死んでしまうということですか
--http2 オプションを使用した際、curl は安全な方法で HTTP/2 通信を試みるために、以下の手順を踏みます。
ALPN (Application-Layer Protocol Negotiation) によるネゴシエーション:
HTTPS 通信の場合、TLS ハンドシェイク中に ALPN を使用して、クライアントとサーバーが互いにサポートしているプロトコルを通知し合います。
サーバーが HTTP/2 をサポートしている場合、クライアントは HTTP/2 で通信を開始します。
サーバーが HTTP/2 をサポートしていない場合、クライアントは HTTP/1.1 にフォールバックします。
HTTP Upgrade によるネゴシエーション (HTTP 通信の場合):
HTTP 通信の場合、curl は HTTP/1.1 のリクエストヘッダーに Upgrade: h2c を追加して送信します。
サーバーが HTTP/2 (h2c) をサポートしている場合、 101 Switching Protocols レスポンスを返し、以降の通信は HTTP/2 で行われます。
サーバーが HTTP/2 (h2c) をサポートしていない場合、通常の HTTP/1.1 通信が継続されます。
これらのネゴシエーションにより、クライアントとサーバーは互換性のあるプロトコルを選択し、安全かつ効率的な通信を実現します。
--http2 オプションは、特に HTTPS 通信において、サーバーが HTTP/2 に対応しているか不明な場合に安全な方法で HTTP/2 通信を試みるために有効です。
いや、そんなこともなさそう。普通にhttp2ってnginxにしていしてもhttp2, 1両対応っぽい
HTTP2そもそもHTTPSでしか動きませんでした笑
はい、HTTP/2 を使う際にはいくつかの制限と前提条件があります。
前提条件:
TLS (HTTPS): HTTP/2 はセキュリティ上の理由から、TLS (Transport Layer Security) 上でのみ動作します。つまり、HTTP/2 を使用するには HTTPS 通信が必要となります。
サーバーとクライアントの対応: HTTP/2 を利用するには、サーバーとクライアントの両方が HTTP/2 に対応している必要があります。最近のほとんどのブラウザやサーバーは HTTP/2 に対応していますが、古いバージョンでは対応していない場合があります。
いったんnginxのキャッシュはできたっぽいので、次はmysql内じゃなくてpublic/images配下に画像いれるとこかなぁ
いったん画像の保存はできたっぽいす
init.shの影響で全然カラム変更したらあきませんやん だる
ほなapi/UUID/iconをいじるほうがええのか多分
sqlでnullの場合にデフォルト値を与えるカラムの与え方を知りたい
initializeのsql文をいじれないのが相当ダルいねってなってます
認証ないと見れない画像、キャッシュしてもうたらやばいやんとか思ったけど、別に機密情報っぽいやつじゃなければ大丈夫っぽいわ
Messengerとかの画像もそうやったし、いったんそれくらいのカジュアルな感じで行きますか
アクセス先のURI、ただしサーバー側で生成する部分(IDなど)は文字種([0-9] や [0-9a-zA-Z_] など)を変えない範囲で自由に生成しても良い レスポンス (HTMLのDOM, JSONオブジェクト等) の構造(表示に影響しない範囲での空白文字の増減は許可される) JavaScript/CSSファイルの内容 画像および動画等のメディアファイルの内容
JavaScriptは変えてはいけないので、いったんFEを書き換えるのは無理そう https://isucon.net/archives/55854734.html
リダイレクトについて ベンチマーカーは HTTP リダイレクトを処理しません。
これやばすぎる ほなリダイレクト戦略はあきませんやん https://github.com/isucon/isucon11-qualify/blob/main/docs/manual.md
POST /api/condition/:jia_isu_uuid 100 ミリ秒を超えるとタイムアウトしますが、後述のスコア計算にあるように減点の対象とはなりません。
↑ぇ
まじでマニュアルとレギュレーションはダルいけどしっかり読んだほうがよさそうねまじで
いったんキャッシュはできたっぽい
詰んだ。やっぱりテーブル構造の変えるとダルいのかなあ ERROR 1136 (21S01) at line 64: Column count doesn't match value count at row 1
INSERTとカラムの数が異なってたら吐くらしいけど、Defaultが設定されていたら行けるとも書いてある
だいぶ意味分からんですこれ デフォルト値いけてますやん
なんかローカルで試したらいけるし意味分からん過ぎる
多分これのせいだ普通に省略できるんかい
1. カラムリストの省略
テーブルの全てのカラムに値を挿入する場合、カラムリストを省略できます。ただし、この場合は値の順番がテーブル定義のカラム順と一致している必要があります。
SQL
INSERT INTO table_name VALUES (value1, value2, ...);
ほかimage_nameを追加する方法は無理なのか まあUUIDで画像保存してあったら返すとかで良さそうではある
とりあえずいい感じにロジック組みました。(もっと良い方法はありそうだけど) isuのidとjia_isu_uuidの対で画像の読み取り権限があるのを把握できてなくて2時間くらいハマった;;
お
15:46:48.146196 score: 5387(5390 - 3) : pass
15:46:48.148921 deduction: 0 / timeout: 33
15:46:48.148989 <=== sendResult finish
デバッグの過程で、キャッシュのheader消したりしたので、もう一回追加。もっとscore上がりそうではある
ちょい上がったわ
15:51:29.434849 score: 5797(5800 - 3) : pass
15:51:29.434951 deduction: 0 / timeout: 34
15:51:29.435035 <=== sendResult finish
alpでの順位はかなり上がったのでヨシ まあボトルネックではなさそう(2位→4位)
+-------+--------+------------------------------+-------+-------+-------+----------+
| COUNT | METHOD | URI | MIN | AVG | MAX | SUM |
+-------+--------+------------------------------+-------+-------+-------+----------+
| 43385 | POST | ^/api/condition/[\w\d-]+$ | 0.004 | 0.066 | 0.152 | 2853.624 |
| 906 | GET | ^/api/condition/[\w\d-]+$ | 0.004 | 0.225 | 0.712 | 204.164 |
| 410 | GET | ^/api/isu/[\w\d-]+/graph$ | 0.004 | 0.247 | 0.892 | 101.328 |
| 170 | GET | /api/isu | 0.040 | 0.402 | 1.044 | 68.344 |
| 235 | GET | ^/api/isu/[\w\d-]+/icon$ | 0.004 | 0.229 | 0.596 | 53.924 |
| 51 | GET | /api/trend | 0.036 | 0.965 | 1.028 | 49.220 |
| 221 | GET | ^/api/isu/[\w\d-]+$ | 0.004 | 0.153 | 0.528 | 33.868 |
| 185 | POST | /api/auth | 0.004 | 0.096 | 0.380 | 17.824 |
| 55 | POST | /api/isu | 0.004 | 0.244 | 0.776 | 13.444 |
| 67 | GET | /api/user/me | 0.004 | 0.080 | 0.376 | 5.380 |
| 40 | POST | /api/signout | 0.008 | 0.114 | 0.344 | 4.556 |
| 102 | GET | / | 0.008 | 0.043 | 0.092 | 4.404 |
| 1 | POST | /initialize | 0.296 | 0.296 | 0.296 | 0.296 |
| 18 | GET | ^/isu/[\w\d-]+/condition$ | 0.000 | 0.000 | 0.004 | 0.004 |
| 6 | GET | ^/isu/[\w\d-]+$ | 0.000 | 0.001 | 0.004 | 0.004 |
| 54 | GET | /assets/vendor.ee7444dd.js | 0.000 | 0.000 | 0.000 | 0.000 |
| 6 | GET | ^/isu/[\w\d-]+/graph$ | 0.000 | 0.000 | 0.000 | 0.000 |
| 53 | GET | /assets/logo_orange.svg | 0.000 | 0.000 | 0.000 | 0.000 |
| 54 | GET | /assets/logo_white.svg | 0.000 | 0.000 | 0.000 | 0.000 |
| 54 | GET | /assets/index.23dac98b.js | 0.000 | 0.000 | 0.000 | 0.000 |
| 54 | GET | /assets/favicon.d0f5f504.svg | 0.000 | 0.000 | 0.000 | 0.000 |
| 3 | GET | /register | 0.000 | 0.000 | 0.000 | 0.000 |
| 54 | GET | /assets/index.144d8ca8.css | 0.000 | 0.000 | 0.000 | 0.000 |
+-------+--------+------------------------------+-------+-------+-------+----------+
リクエスト数も減ってるのでちゃんとキャッシュされてそう
dbに画像のインサートまだやってたので消します。
さらに上がりました👏
13:49:09.555768 score: 6339(6342 - 3) : pass
13:49:09.555833 deduction: 0 / timeout: 33
13:49:09.557645 <=== sendResult finish
これ流石に知らんすぎる
コマンドラインでの指定: makeコマンド実行時に 変数名="値" の形式で指定された値が最優先されます。
環境変数: 環境変数に設定されている値が次に優先されます。
Makefileでの定義: Makefile内で定義された値が最後に参照されます。
したがって、make mysql/query QUERY="xxxx" とした場合、QUERY変数の値はMakefile内の定義で空文字列に設定されますが、コマンドラインでの指定 "xxxx" が優先されるため、最終的に QUERY 変数には "xxxx" が格納されます。
いったんnginxをいじらなアカン説あります。