博文

目前显示的是 五月, 2022的博文

在日本搬家所需要的注意事項

第一。搬入新家之前,给家里有瑕疵的地方拍照,做好备份,这样在退租的时候,尽量避免支付多余修复的钱。 第二,开通电力和瓦斯的那些事。 开通电力和瓦斯,建议在搬家的前一周联系东京电力公司。我是通过电话联系的,客服人员会很温柔的和你沟通,电力和瓦斯是一家的。注意区分下《东日本,西日本》自己住的区域是属于哪边。 第三,买家具。 这方面有很多网站,建议不要分开买。有《新生活セット》里面有套装,这样会更加优惠一些。我的是在乐天买的,注意好,他们送货是否收费。我就没注意好被坑了3000日元。 一定要区分好燃气灶的类型是LP的还是东京gas的,买错的话退起来很麻烦。 一般性:2点セット包含了《洗衣机,冰箱》,3点セット包含了《洗衣机,冰箱,微波炉》,根据自己选择即好 我买的是3点セット,然后有在他们店里掏2000日元买了把电脑椅子,又加了13000买了煤气灶,同一个店铺买,这样会比较超值一些。总共掏了58000。 要不是最后被坑了3000日元,我真会给他5星好评。一定要商量好价格,价格一定要明确,明确下来。 第四,开通网络 开通网络需要提前20天预约,从审核你的住所是否能安装他们公司的网络,到施工结束大概需要花这么多时间。不同的网络公司需要不同的网络设备,有些公司不用再另外掏钱买,有些则不行。 网络最快的就是 NURO 了,光纤实际下载速度可以达到60M一秒,IP是固定的。 现在用的是 《ぷらら 》不推荐使用,网络速度比较慢。ping baidu.com 的话,会有25%的掉包情况。ping google 倒是没啥问题,实际下载速度最大10M。 最后,总结 不要把日本人想象地多美好,不会坑你。他们只是没找到机会。如果你觉得我这句话是错的,不相信,我只能笑你还是太天真。 看房子的时候,一定要看好洗衣机的排水口,距离安装位置是否过远,怎么排水。

大ファイルアップロードする解決案

图片
調査 サンプル画面を書くときに、「400MB」以上のMP4ファイルをアップロード時、JVMからメモリー不足エラーが起こりました。 普段、この時、JVMの占用メモリー引数を修正するだけでいいですが、別の実現し方で、解決しようと思いました。 動作はユーザーさんが複数のファイルを選んでから、ファイルごとにアップロードする、しかし、ファイルが多き過ぎて、Jvmに配れたメモリー資源が足りないことになりました。 画面を見ると、管理画面のファイルアップロードテキストは制限されてない、追加アップロードボタンをクリックすると、ファイルテキストを画面に追加できます。 一つのファイルテキストは選択できるサイズが最大1GBまで、五つのテキストは5GBになる、このように換算する。 アーキテクチャ 処理フロー 解決案 大ファイルを分割して、何回にアップロードするように修正。ファイルを分割して、ファイルブロック単位として、アップロードする。 もちろん、サーバーにアップロードする後、組み合わせて、AmazonのS3に保存する。 幸せなことは、Java APIを見ると、ファイルブロックが直接にS3にアップロードする、全ブロックがアップロード完了する後、シンプルに「組み合わせる範囲」のAPIを呼び出すだけで、リモートのS3サーバーに正常に読み取りができる。 最後 テストする後、一つテキストは2GBでもかまいません、日常使用に対する問題なかった。 インターネットのスピードが調整不能のため、時間がかなりかかる インターネットの有無にも仕方ないだろうか、草 :)

スレッドで処理資源を制限する

图片
課題説明 今って、大きく課題にアサインしてもらった。現状は、データ数が多すぎるので、そして、データ抽出したあとにそのロジックコードも長すぎる、ざっくりみると、20000行以上である。中で別システム連携であるのみにならず、DBデータの再抽出も多い。 テストの最小単位で3万件のデータをダウンロードに試してましたが、ローカルの開発環境で全然無理です。15分ほどにかかったあと、すぐダンしてしまった。 プロジェクトリーダーは「エラーになる行を見て、解決してください。」と言った 僕にとって日本では技術のことが知らないリーダーが多いです、実際はこんなに簡単に解決ではなく、性能問題は開発の段階に考えられるものと思うですが、仕様不備やスケジュールを合わせるため、開発段階にもややこしかったかもしれない ほぼ、現状を把握から解決まで二週間を経った、問題は以下になる loopの中にLoopが多すぎる 全件数を抽出した、未出力のデータって長期にメモリーを占用する 全データ処理後一瞬にファイルを出力する、400MBくらい SQL:where id in(...2000個以上のストリング...) 本番環境のメモリーは4GBがあるのに、2GBだけ使われてる 実現目標 100000件以上のデータがダウンロードできるように修正 アーキテクチャはこうになる 解決案 一番目の解決案はリストタイプをMapタイプに修正すればOKです。 二番目は全件数を抽出したので、回数による処理件数を制御すると僕は考えてます。リーダーさんは、「処理件数」だけで制御いけないかという質問を頂きました。 1人は「500件」、10人同時にダウンロードすれば並列件数が5000件です。30人なら、15000件。 以上の問題をもって、実験したが、5000件以内は別の機能に性能影響が最も小さい。 三番目の解決案は、一行ずつファイルに出力する、処理後にCSVの該当オブジェクトをNullにして、JVMがメモリー資源を自動的に開放できる 四番目は根拠の問題はMySQLのインデックスに走らなかったです、INの結合句は2000以上であるので。これに対すて、新しくテーブルを作成しました、毎回処理の回数データは「 insert into  new_ table_name(申込ID) select * from  old_ table_data 」テーブル