小規模、低パフォーマンス、低トラフィックの Web サイトの設計と開発の原則

小規模、低パフォーマンス、低トラフィックの Web サイトの設計と開発の原則_PHP チュートリアル

WBOY

リリース： 2016-07-13 10:17:47

オリジナル

941 人が閲覧しました

小規模、低パフォーマンス、低トラフィックの Web サイトの設計と開発の原則

小規模、低パフォーマンス、低トラフィックの Web サイトの設計と開発の原則_PHP チュートリアルいくつかの技術サイトで、大規模で高トラフィック、高パフォーマンスの Web サイトのアーキテクチャ設計を分析した記事をよく見かけます。記事は基本的に満足度が高い人々の好奇心を刺激しますが、読んだ後の実際の利益はそれほど大きくないかもしれません。なぜなら、多くの人にとってこのような機会に触れる機会はあまりないかもしれないからです。たとえそれに触れたとしても、実際に遭遇する状況は、あなたが読んだ多くの記事とは異なることがよくあります。

さらに、このような記事を読みすぎると人々が興奮しやすくなり、歩くことを学ぶ前に走ることを学ばせてしまうという副作用があり、その結果、多くの人が過度にデザインし、過度に拡張し、離れてしまいます。多くの条件が満たされていない場合、不必要な問題について考えるのが早まってしまい、逆効果になることがよくあります。

今日の記事では主に、小規模、低パフォーマンス、低トラフィックの Web サイトを設計および開発する方法について説明します。

サイトが初期段階のマシンまたはスペースである場合 (www.phpernote.com、毎日の IP が 5,000 未満のサイトなど)、現時点では、データの分割と負荷分散に注意を払う必要があります。影のあるものではありません。多くの大規模サイトの経験を真似してはなりません。これは、現実の状況に基づいて問題を弁証法的に見るための最後の言葉です。

使い慣れたテクノロジーを活用する

ウェブサイトを構築するとき、何を使用するか、自分がよく知っていることを他人に尋ねたりしないでください。ウェブサイトを書くのに苦手な技術的手段を使用すると、書き終わる頃にはニッコウキスゲが終わってしまう可能性があります。寒くなる。したがって、既製のソフトウェアコンポーネントが利用可能な場合は、自分で車輪を再発明しないでください。 Python は素晴らしいと言われますが、PHP しか知らないので、.net しか知らないのであれば、それも悪くありません。悪いテクノロジーを使用することは恥ずかしいことではありませんが、良いテクノロジーを悪用することは恥ずかしいことです。

アーキテクチャレベルをクリア

アーキテクチャのレベルは初期段階で明確に決定する必要があります。それらが混在していると、事業が拡大したときに元の山が分離できないと非常に苦しいことになります。

Web サーバー (AppServer)キャッシュ (例: Memcached)DB

階層の明確さの 1 つの現れは (LAMP アーキテクチャを例にとります)、たとえマシンが 1 つしかない場合でも、Memcached のインスタンスをセットアップする必要があり、その効果は確かに非常に優れています。一般の人々に、DB にすべてを置くなとは言いません。DB の I/O 負荷はすべてディスクに送られるため、問題はすぐに明らかになります。はい、DB 自体も独自のキャッシュを使用しますが、結局のところ、DB のキャッシュと Memcached の設計の出発点は異なります。

データの冗長性を正しく表示する方法

多くの人はデータベース設計の専門家ではありません。プロジェクトでテーブル構造などを自分で設計する必要がある場合、基本的にはそれを一時的に行いますが、多くの人はこの 3 つのパラダイムをよく覚えています。ウェブサイト問題は、小さなプロジェクトが数十の時計を生産したということです。このパラダイムのことは忘れてください!

現在、ディスク容量はそれほど高価ではありませんが、時間は常に容量よりもはるかに高価であることを忘れないでください。データ層に取り憑かれる時間が長くなればなるほど、製品への投資は少なくなります。ユーザーが最も気にするのは製品のデザインです。

フロントエンドの最適化は非常に重要です

現時点では、トラフィックが少ないため、訪問者がそれほど多くない可能性があります。トラフィックが少ないほとんどのサイトでは、ページが数メガバイトになる可能性があるため、ページが大きすぎないように注意する必要があります (スタートアップを見た)。 2 日前のホームページのサイズは 4MB でした)、これは驚くべきことです)、ユーザーは 30 分眺めてもページを開くことができません。どのように発展すると思いますか?まず基本的な条件を満たしてから、フロントエンドの最適化を検討してください。

機能を追加するときは注意してください

80/20の原則はありませんか？最も重要なエネルギーを、最も大きなビジネス価値をもたらすことができる場所に投入してください。一部の派手な機能には多額の費用がかかりますが、効果はほとんどありません。小規模なサイトの場合、最も価値があるのはビジネスモデルであり、テクノロジーの素晴らしさではないことを忘れないでください。テクノロジーはビジネスに役立つものであり、自分のスキルをひけらかす必要はありません。

一部の Web サイトは機能を追加し続けており、これらの新機能が機能を壊す藁に変わってしまいます。

パフォーマンスを最初から考える

これはオプションですが、重要です。アプリケーションを設計するときは、最初にプロファイルを考慮する必要があります。アプリケーションが後の段階で効果的に最適化および拡張できるかどうかは、より適切なプロファイルメカニズムがあるかどうかによって主に制限されます。付け加えておく必要があるのは、パフォーマンスを考慮する際には、関連する過去のデータを考慮する必要があるということです。

優れたアーキテクチャは設計されていない

これが最後の追加点です。優れたアーキテクチャは初期設計と関係がありますが、最も重要なことは開発における進化です:

開発->問題の発見->フィードバック->問題の解決(実行)->改善->次のステージへの進化--新たな問題の出現(サイクル)

サイトによっては、ある段階で前進が止まり、ユーザーからのフィードバックを受けても改善の原動力がなくなってしまう場合があります。結局、死んだ豚は熱湯で火傷することを恐れません。私が最も恐れているのは、「ビジネスがそれを許可していない」という言い訳です。想像してみてください。改善しなければビジネスはまだ許可されますか?バリア。

この記事は模倣の雰囲気が強いので、あまり真剣に受け止めないでください。短く、平坦で、迅速な方法でコピーサイトを構築している場合は、自分にとって有益な点を参照できます。同意できない場合は、反論するメッセージを残す必要はありません。