タグ

関連タグで絞り込む (32)

タグの絞り込みを解除

performanceに関するgachakku0131のブックマーク (73)

  • 500点出す！ - ゆーすけべー日記


    ﹁Web Speed Hackathon 2022﹂という﹁非常に重たいWebアプリをチューニングして、いかに高速にするかを競う競技﹂があります。 リモート参加で11月1日から27日まで開催されています。 ここで言う﹁高速﹂とはCore Web Vitalsのスコアが高いことを言い、Lighthouseのスコアをベースにした500点満点の争いです。 ISUCONのフロントエンド版ですね。 以前にも同じ課題で﹁学生向け﹂と﹁社内︵サイバーエージェント︶向け﹂が行われたらしく、まだ500点を出した人はいません。 そこで僕は﹁満点を出したい﹂と思い、初日から、いやむしろフライングしていたからその前から頑張ってきました。 そして、先日︵17日︶、ついに500点満点を出しました！ たぶん、レギュレーションはクリアしている、はずです︵もし違反してたらすいません…︶。 自動で行われる﹁Visual Re
    500点出す！ - ゆーすけべー日記

  • 手軽に負荷テストができるツール「Taurus」がスゴい

    modules: jmeter: version: 5.4.1 # ここに書いてあるバージョンを勝手にダウンロードしてくれる properties: log_level.JMeter: WARN log_level.JMeter.threads: WARN system-properties: org.apache.commons.logging.simplelog.log.org.apache.http: WARN 既存ツールのラッパーとして動作 デフォルトでは内部的にJmeterが実行されますが、以下のようなツールで作成されたスクリプトを流用することが可能です。 JMeter Gatling Locust Selenium Vegeta つまり、さきほどはYAMLでシナリオが記述可能とは言いましたが、もちろん既存のスクリプトを流用できるってことです。 いままで作り上げてきたスクリプトや

    手軽に負荷テストができるツール「Taurus」がスゴい

  • “Railsな人” のための低レイヤへの招待 / introduction-to-low-level-mruby

    銀座Rails#34 https://ginza-rails.connpass.com/event/211013/

    “Railsな人” のための低レイヤへの招待 / introduction-to-low-level-mruby

  • 結局、Go言語をやめる理由はなかった件 - Qiita


    この記事は Go2 Advent Calendar 14日目の穴埋め記事です。 はじめに @okdyy75 さんによる Go5 Advent Calendar 14日目の の記事﹁だから僕はGo言語を辞めた﹂ が﹁ベンチマークっていうのはこうやるんだよ﹂というのを説明するために反面教師的な意味で良い教材だと思ったので、反証記事を書きたいと思います。 ベンチマークを取りながらコードを改善して、最終的にGoは遅くないからやめる必要はないということ、そして、なぜ遅いという結論になってしまったのかを掘り下げていきたいと思います。 下準備 幸いなことに、ベンチマークのソースコードがGitHubにある ので、こちらを実行しながら問題点を改善していきましょう。 ちゃんとコードが上がっているのは素晴らしいですね！ 一方で、元記事には測定環境が明記されていませんでしたので、同じ環境で測定することはできま
    結局、Go言語をやめる理由はなかった件 - Qiita

  • レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ


    技術部の外村︵@hokaccha︶です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JSのコードは昔なが
    レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ

  • アプリエンジニア向け：「サーバがなんか重い」時にすること - Qiita


    アプリケーションエンジニアの人には﹁なんか重い﹂という状況に遭遇したらインフラの人にタスクを投げる、という人もいるかも知れません。けど、その重さのどこに原因があるのか。CPUか、ネットワークか、IOかくらいの診断はできた方がアプリ開発においても有益です。 ﹁せっかくつくったシステムがなんか重い﹂ そんな時にアプリケーションエンジニアとしてできることを書きます。 本職のインフラの人にはぬるい内容だと思います。何を隠そう僕自身がアプリ寄りの人間なので、突っ込んだ話はできないのです。あしからずご了承ください。 なんかサーバが重いなー まずはロードアベレージを調べる サーバが重いと思ったら、まず真っ先にすべきことは対象ホストにSSH接続してロードアベレージを調べることでしょう。ロードアベレージとは 実行されずに待たされているプロセスの数 のことで、多すぎるとやばいと認識しておきましょう。ロードアベ
    アプリエンジニア向け：「サーバがなんか重い」時にすること - Qiita

  • MySQLのメモリ設定の勘所 – sawara.me


    MySQLサーバーをダウンさせた夜は数知れず。 その度にmy.cnfの設定を見なおしてみてはトライし、治ったと思いきや突然のダウン。 サーバーがダウンしてしまう原因は何かと聞かれれば、﹁メモリです﹂と断言しましょう。 メモリ設定は諸刃の剣。 パフォーマンスを最大に引き出すこともできればそれと引き換えにサーバーをダウンさせてしまうこともできるんです。 今回はMySQLのメモリの設定の勘所というかたちで紹介しようと思います。 グローバルバッファとスレッドバッファ メモリの設定についてまず﹁グローバルバッファ﹂と﹁スレッドバッファ﹂について理解しておくことが大事です。バッファとは一時的な記憶領域・つまりはメモリの領域のことなのですが。 グローバルバッファ MySQLで使用する全体的なメモリ使用量を計算するには グローバルバッファ + (スレッドバッファ × コネクション数) = メモリ使用量 と
    MySQLのメモリ設定の勘所 – sawara.me

  • わりと本気でウェブサイトの高速化に取り組んだ結果。 - ページ 2 - ONZE

    この連休中に弊社ウェブサイトの表示スピード高速化に取り組みました。 もともと不満が無いほどのスピードを誇っていましたが、さらに完璧を目指して様々なアップグレードを試みたので、その結果と共に、皆様にも参考になるであろう読み込み速度UPのための改善策を提案していきます。 まず前半では診断結果を、後半では改善策を紹介していきます。 先に「改善策」のほうを読みたいという方はコチラからどうぞ。 診断に使ったサイト 今回、ウェブサイトの読み込み速度を診断するために使ったのは以下のサイト。 Google PageSpeed Insights GTmetrix Pingdom Website Speed Test いずれも説明が不要なほど有名な３つのサイトですね。 なお計測は弊社サイトのトップページ（https://on-ze.com）を指定して行いました。 以下、高速化のための改善策を講じた後の診断結果

    わりと本気でウェブサイトの高速化に取り組んだ結果。 - ページ 2 - ONZE

  • Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD


    (訳注‥2016/3/2、頂いた翻訳フィードバックをもとに記事を修正いたしました。) Railsアプリでのキャッシングは、﹁たまに夕食を一緒にするけれど、本当はもっと頻繁に一緒にいるべき友達﹂に少し似ています。パフォーマンスをまじめに考えるRailsアプリのほぼ全てで、もっとキャッシングを使えるはずですが、ほとんどのRailsアプリでは、完全にキャッシングを避けています。それでも普通は、Railsで高速なサーバ応答を達成するための唯一の道は、キャッシングの知的な利用なのです。約250msの応答時間を、簡単に50～100msに高速化できます。 定義についての注意　―　この記事は、アプリケーション層のキャッシングのみを対象としています。HTTPキャッシング︵これは全く別の難物で、あなたのアプリケーションに実装する必要はありません︶は、別の機会で扱いましょう。 するべきキャッシングをしない理由
    Railsアプリを66％スピードアップ ― Railsキャッシュの完全ガイド | POSTD

  • Speed and Performance Optimization

    Log In Get Started for Free Free Ebook - Website Traffic Killers: 13 Costly Mistakes Unlock the secrets to enhancing your website's visibility and performance effortlessly.

    Speed and Performance Optimization

  • Apacheのチューニングメモ - Qiita

    個人的Apacheチューニングのメモ。 間違いがあったら教えて下さい！ prefork 前提 Apacheでは、リクエストはApacheの子サーバプロセスが処理する。 子サーバプロセスは動的にforkで生成されたり、殺されたりする。 が、forkはとても重い処理なので、forkが発生しないように設定するのがよい。 チューニング方針 負荷が高かろうが低かろうが常に一定数のプロセスが動いている状態にする。 preforkの動作 MaxClientsは絶対値。 子プロセス数はこの値を超えない。 （以下正確ではないですが簡単に） Apacheは負荷が高くなってきたら 子プロセスを生成していく アイドル状態の子プロセスはMinSpareServers以上になるよう維持 MaxClients以上の子プロセスは生成しない MinSpareServersよりMaxClientsが強い 負荷が低くなってきた

    Apacheのチューニングメモ - Qiita

  • GridView を超高速化するための 10 の方法 - おともだちティータイム


    写真のギャラリーアプリなどで、四角い画像をタイル状に並べているものが数多くあります。 こういった画面は Android なら GridView というものを使って簡単に作ることができます。 しかし、なにも考えずにアプリを作ると死ぬほど遅い、重い、スクロールがかくつく、最後には OutOfMemoryErrorで死にます。 1. getView() 内で処理をしない GridView の一つ一つの Itemを表示するのが getView() というメソッド。 ここでの処理が重ければ重いほどスクロールはカクツキ、快適度はさがる。 2. ViewHolder を使う findViewById() 、 inflate() は遅いので View は出来るだけ使い回す 3. スクロール中は別スレッドで処理をしない スクロール中にコンテキストスイッチが発生するのもカクツキが発生します。スクロール中は
    GridView を超高速化するための 10 の方法 - おともだちティータイム

  • Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT


    平素よりQA＠ITをご利用いただき、誠にありがとうございます。QA＠ITは﹁質問や回答を﹃共有﹄し﹃編集﹄していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー﹂として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日︵金︶15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。QA＠ITの7年間で皆さまの知識
    Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT

  • 【これは便利】あなたのWebサイト表示のどこが遅いかを一発で調べるブックマークレット | 初代編集長ブログ―安田英久

    【これは便利】あなたのWebサイト表示のどこが遅いかを一発で調べるブックマークレット | 初代編集長ブログ―安田英久

  • ウェブサイト高速化勉強会に参加してきた #tnmk0929 - Diary of absj31


    ウェブサイト高速化勉強会 : ATND 2012/09/29 ウェブサイト高速化勉強会 #tnmk0929 - Togetter さくらのVPSにてサーバ＆ドメイン取得を行った流れもあり、個人用鯖にも何らかのWebコンテンツを配備・公開して行く事になるだろう(てかそういう風にして行きたい)と言うのもあり、ちょうど目にしたこちらの勉強会に目が留まり、参加して来ました。 なので現状のWebサイトを高速化させるために、ってのではなくて今後のために、という意味合いが強いですね。 会場は横浜タネマキ。最近は個人的にはYokohama.groovy等で2週間に一遍は使ってる感じですね。 タネマキ ︻コワーキング ＆ シェアオフィススペース︼ 開始間際、ディスプレイ接続で調整が上手く行かず10分程押した後スタート。 Web Site Optimization for Beginners こもり まさあき
    ウェブサイト高速化勉強会に参加してきた #tnmk0929 - Diary of absj31
    gachakku0131
    gachakku0131 2012/09/30
    YSlowの見方のリンクなど参考になる
    リンク

  • dstatの万能感がハンパない - （ひ）メモ


    サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47
    dstatの万能感がハンパない - （ひ）メモ

  • MySQLのEXPLAINを徹底解説!!


    以前、MySQLを高速化する10の方法という投稿で﹁EXPLAINの見方についてはいずれ解説しようと思う﹂と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
    MySQLのEXPLAINを徹底解説!!

  • Railsの各種サーバーの速度ベンチマーク: Pound、Varnish、Nginx、Unicorn、Mongrel


    Railsの各種サーバーの速度ベンチマーク: Pound、Varnish、Nginx、Unicorn、Mongrel RailsのアプリをPound、Varnish、Nginx、Unicorn、Mongrelを使用して動かした際の速度ベンチマーク。以下の構成での同一Railsアプリをhttperfでベンチマークした結果をまとめます。 Pound -> Varnish -> Nginx -> Unicorn * 2 Varnish -> Nginx -> Unicorn * 2 Nginx -> Unicorn * 2 Mongrel (Rails.env == 'development') node.js (Express + Socket.IO) 全体の構成Poundを80番ポートを公開し、Varnishを81番ポート、nginxを8080番ポート、Unicornの2プロセスをsocke

  • Firefox、メモリ、キャッシュ、SSD、RAMディスク


    Core i7、DDR3メモリトリプルチャンネル6GB、Intel SSD、Windows7。この環境なら、何かのアプリケーションが重くていらだつことはもうないだろうと思っていたあの頃。 SSDの読み込みの速さによる、Windows自体の起動の速さ、アプリケーションの起動の速さにも慣れ、残ったのはFirefoxの動作の重さ…。 まさかWebブラウジングするだけの処理がここまで重いとは…。前の環境で重かった画像処理は快適になったのに、なぜブラウザがここまで重いのか…。 ﹁FirefoxのAutoPagerizeが重かった﹂の後、ページ先読み用アドオンは﹁AutoPager :: Add-ons for Firefox﹂に変えていました。PCのスペックも上がったことで、再びAutoPagerizeに戻していたわけです。でも、やっぱり重い。Greasemonkey版やExtension版のAut
    Firefox、メモリ、キャッシュ、SSD、RAMディスク

  • さいきんの Rails サービスを高速化をしてみた - 2nd life (移転しました)


    先日のももクロハッカソンで出会った wantedly を作ってる仲さんが と言ってたので、面白そうなので wantedly を速くしてみました。 wantedly ちなみにデータが数百万オーダーもなさそうなのに、どのページもログインすると2-5秒ぐらいかかっていたので、確実に速くできそうだなぁという感覚はやる前からありました。 アプリケーションサイドのチューニング 初心者*1にありがちな問題として SQL に適切にインデックス張ってない キャッシュすべき場所をキャッシュしていない 無駄なデータを引きすぎてる ことがよくあります。ので順に実装を見ていきました。 SQLに適切なインデックスを張ってない 張ってありました！びっくり！＼(^o^)／ キャッシュすべき場所をキャッシュしていない Facebook API を利用したアプリケーションなんですが、ユーザのデータの取得を毎回馬鹿正直にHT
    さいきんの Rails サービスを高速化をしてみた - 2nd life (移転しました)
  • 1 2 3 4 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.