インタフェースが返すデータ量が大きすぎて非帯域幅がかかります
1330 ワード
最近のオンラインプロジェクトでは多くの問題が明らかになっていますが、一つの問題は帯域幅が足りないということです.最初の30 Mから60 Mに加えてから200 Mになりましたが、私たちの日活は全部で10000にも満たないということです.この問題は、原因をよく調べることにしました.
占有帯域幅はインタフェースが返すデータ量が大きすぎることにほかならないので、私は次のプロジェクトの中でデータ量の大きいいくつかのインタフェースを返して、その中の1つもアクセスが頻繁なインタフェースがインスタントリストインタフェースを取得して最大の戻りデータ量は2 Mを超えることがあります!!もっと恐ろしいのは、このインタフェースかポーリングインタフェースか、5秒でフロントが呼び出されます.
はい、原因が見つかりました.このインタフェースによるものです.最適化しましょう.
1.業務ロジックは当該データがページングできないことを規定する
2.このインタフェースは分割できません.多くのデータは一度に返さなければなりません.
3.ポーリングは変更できません
OK ...
それからデータ圧縮を考えました.私たちのプロジェクトはspring-bootプロジェクトなので、Gzipを追加するのは2行の構成を追加するのに便利です.
しかし、追加後は何の効果もなく、インタフェース呼び出し後も表示データが圧縮されていません.
ひんやりとした
spring-bootバージョン番号の問題を排除するために、私は自分の前の小さいプロジェクトを使って小さいdemoテストを書いて、圧縮しない時データ3 Mを返して圧縮して帰ってきたデータ60余りKb....
この圧縮は確かにいいものですが、私たちのプロジェクトでは使えません.
いろいろ考えた末、その端緒を発見したGET POST
GZIPを使用するにはgetリクエストが必要です
しかし、フロントパッケージは即座に更新できず、旧バージョンのPOSTでGETを変更しても後続バージョンでしかストレスを解消できないことを考慮すると、mark下では、後でデータ量の大きいインタフェースに戻り、機密情報にかかわらない限り、必ずGETリクエストを使用することで、多くのことを省くことができます.
転載先:https://www.cnblogs.com/zhaiyt/p/11410904.html
占有帯域幅はインタフェースが返すデータ量が大きすぎることにほかならないので、私は次のプロジェクトの中でデータ量の大きいいくつかのインタフェースを返して、その中の1つもアクセスが頻繁なインタフェースがインスタントリストインタフェースを取得して最大の戻りデータ量は2 Mを超えることがあります!!もっと恐ろしいのは、このインタフェースかポーリングインタフェースか、5秒でフロントが呼び出されます.
はい、原因が見つかりました.このインタフェースによるものです.最適化しましょう.
1.業務ロジックは当該データがページングできないことを規定する
2.このインタフェースは分割できません.多くのデータは一度に返さなければなりません.
3.ポーリングは変更できません
OK ...
それからデータ圧縮を考えました.私たちのプロジェクトはspring-bootプロジェクトなので、Gzipを追加するのは2行の構成を追加するのに便利です.
server.compression.enabled=true
server.compression.min-response-size=1024
server.compression.mime-types=application/json
しかし、追加後は何の効果もなく、インタフェース呼び出し後も表示データが圧縮されていません.
ひんやりとした
spring-bootバージョン番号の問題を排除するために、私は自分の前の小さいプロジェクトを使って小さいdemoテストを書いて、圧縮しない時データ3 Mを返して圧縮して帰ってきたデータ60余りKb....
この圧縮は確かにいいものですが、私たちのプロジェクトでは使えません.
いろいろ考えた末、その端緒を発見したGET POST
GZIPを使用するにはgetリクエストが必要です
しかし、フロントパッケージは即座に更新できず、旧バージョンのPOSTでGETを変更しても後続バージョンでしかストレスを解消できないことを考慮すると、mark下では、後でデータ量の大きいインタフェースに戻り、機密情報にかかわらない限り、必ずGETリクエストを使用することで、多くのことを省くことができます.
転載先:https://www.cnblogs.com/zhaiyt/p/11410904.html