スケーラビリティに関するよくある質問

Q: PaperCutが合理的にサポートできる最大ユーザ数はどれくらいですか?
A: これは回答が難しい質問です。
    ハードウェアの速度や各ユーザが実行する印刷量(1日当たりの印刷回数) など様々要因に左右されるためです。
    ハードウェアは常に向上するため、回答も常に変化します。
    現在のPaperCut社の顧客の中で最大ユーザ数は350,000ユーザです。
    PaperCutを使いだした2008年以来問題なくPaperCutは実行されています。
    PaperCutアプリケーション・サーバとMicrosoft SQL Serverデータベースは別々の筐体で実行されています。
    このお客様は導入以来パフォーマンスの問題なくPaperCutを実行しています。

    この間、ハードウェアは絶えず向上されてきました。これにより、さらに多くのユーザ/プリンタをサポートすることができます。

    ユーザ数が10万人を超えるサイトにPaperCutを導入する場合、
    PaperCut開発チームにシステム構成についてご相談いただくことをお勧めします。
    下記のトピックをカバーする、他の同様の規模の導入から学んだ教訓をお伝えすることができます。
      システムアーキテクチャと設計
      ハードウェアとソフトウェアの推奨構成
      非常に管理するユーザ数とデバイス数が多い環境における一般的なシステム構成と印刷管理のヒント


Q: パフォーマンスの問題が発生する前に、PaperCutが保持できるプリント・ログとトランザクションの総数を教えてください。
A: PaperCutは最新のデータベース プリンシパルをベストプラクティスにするように開発されています。
    Microsoft SQL ServerやOracleなどの主要なデータベース・サーバを使用している場合、
    PaperCutは標準操作のパフォーマンスを損なうことなく機能し続けます。
    データベースにプリント・ジョブ処理のような何百万もの印刷/トランザクションのレコード操作が含まれる場合に
    管理者/ユーザ用Web画面へアクセスしてもパフォーマンスは低下しません。

    すべてのレポートはデータベース・インデックスを効率的に使用するように最適化されているため、
    日/週/月などの指定した期間の標準レポートでも影響を受けません。
    つまり、最近のアクティビティに関するレポートを実行する場合、履歴レコード数がパフォーマンスに影響を与えることはないことを意味します。

    データベースのサイズにより影響を受けるエリアの1つは、データベース全体からレポートを実行する場合です。
    この場合、レポートの実行に所要する時間は、レポートされるデータのサイズに比例します。
    システム履歴全体からレポートを実行することは一般的でないため、これは重要な問題ではありません。
    ほとんどのレポートは前月や前年などの最近の期間を指定して実行され、データベース・インデックスを利用できます。

    要約すると、PaperCutは印刷ジョブの処理、ユーザ管理、および日時作業のような標準操作のための O(1)性能を目指しています。
データベース履歴全体から生成するレポートのパフォーマンスは O(N)になります。


Q: PaperCutは、ページ数/カラー/用紙サイズなどの情報をプリント・ジョブから解析するためにどのくらい時間がかかりますか?
A: プリント・ジョブの解析にかかる時間は、プリント・ジョブのスプール・ファイルのサイズにより異なります。
    一般的なプリント・ジョブの場合、解析には数秒(2~3秒) 以内に実行されます。

    PaperCutは設計事務所やデザイン学校で使用されています。
    これらの場所から印刷される技術設計書やグラフィック・ポスターのスプール・ファイルは数百MBもしくは数GB以上のサイズになる場合があります。
    このサイズのジョブは解析に最大30秒以上かかる場合があります。


Q: レポート生成速度に影響を与える可能性のある要因は何ですか?
A: レポート生成速度を決定する最大の要素は、レポート生成期間です。
    期間が長いほどレポートを生成するために多くのデータを処理する必要があります。

    一般的な期間(例: １ヵ月のプリント・ログ)でレポートを生成する場合、すぐに実行されます。
    例えば５年分などの長期間のレポートを生成する場合、処理するデータ量に基づき比例して長くなります。

    もう１つの重要な要素は、最先端のデータベース(Microsoft SQL ServerやOracleなど)が、
    十分なリソースが割り当てられているデータベース・サーバで実行されている必要があります。
    過去に、過負荷もしくはリソース不足のデータベース・サーバでPaperCutを実行しているお客様において問題が発生したことがあります。
    弊社では、データベース・サーバに十分なリソースが割当らえておらず、
    また複数のアプリケーションで共有されている状況で問題が発生したのを確認したことがあります。
    (例: 頻繁に利用されているファイナンス・アプリケーションと同居)


Q: 1年間で400万枚の印刷/コピーのレポートを生成する場合、どのくらい時間がかかりますか?
A: 実行するレポートの種類によって大きく異なります。
    個々の印刷ジョブをリストしたレポートを比較すると1年間に印刷した総ページ数をカウントしたレポートは大きな差異があります。
    パフォーマンスはデータベース・サーバのハードウェアによっても大きく影響される可能性があります。

    PaperCutのレポートはレポートのパフォーマンスを向上させるため、データベースのインデックスを利用するように最適化します。

    高性能のデータベース・ハードウェアを使用している場合、このデータに関する概要レポートの生成には通常1～2分かかります。
    より詳細なレポートを生成する場合は、さらに数分かかる場合があります。


Q: PaperCutはプリント・ログとトランザクション・ログのアーカイブをどのように処理しますか? これは必要ですか?
A: PaperCut社はプリント・ログやトランザクション・ログをアーカイブすることを推奨していません。
    最新のハード・ディスク・サイズと比較すると、プリント・ジョブ・データはそれほど多くのディスク容量を消費しません。
    大規模サイトの顧客の多くは、データをアーカイブせずに長年PaperCutを実行しています。
    高性能のデータベース・ハードウェアを使用すると、大量のプリント・ログ・データがあってもシステムは最適に動作し続けます。

    PaperCutシステム上に過去の印刷レコードが保存されるため、ほかのシステムへアクセスする必要はなく簡単に表示やレポート生成ができます。

    最新のハード・ドライブを使用する場合、10年分のプリント・ログ・データが保存できます。
    データベースのサイズ設定と容量要件の計画については別紙「【補足資料】キャパシティ・プランニング」をご参照ください。

    印刷レコードのアーカイブを実行する技術的な理由はありません。

    印刷レコードをアーカイブしないことで、すべてのデータを単一のロケーションへレポートすることができます。
    これは代替えシステムでデータへアクセスするよりもはるかに便利です。

    アーカイブが必須の場合、次の方法で実現できます。

     1. PaperCut管理画面のオプションから古いログ・データを削除するように設定する
     2. 古いログを削除する前に、使用しているデータベースのバックアップ手順に従いDBスナップショットを保存する


Q: PaperCutはプリント・サーバのクラスタリングをサポートしていますか?
A: PaperCutは複数のクラスタリング環境/システムをサポートしています。
    　Microsoft Cluster Services
    　Microsoft Failover Cluster
    　Veritas Cluster
    　Novell Cluster Services
    　Linux HA


Q: PaperCutのどの機能がスケーラビリティに役立ちますか?
A: メインの機能は次の通りです。
     1. 異なったタスクを同時に実行する複数のサービスを一つのものとして負荷分散させることが可能
        　データベース・サーバ
       　 アプリケーション・サーバ
        　複数のプリント・サーバ
     2. MS SQL ServerとOracleなどの高性能の外部データベースをサポート
     3. アプリケーション層, データベース層, およびプリント・サーバ層のクラスタリングをサポート
     4. スケーラビリティを念頭に置いて最初から設計された最新のSOAアーキテクチャとコード・ベース
     5. 64bit オペレーティング・システムをネイティブ・サポート



-------------------------
https://www.papercut.com/kb/Main/CommonScalabilityQuestions