Важкий сайт пропускної здатності… використовувати спільне місцезнаходження?


11

Я працюю над веб-сайтом, який, ймовірно, має велику пропускну здатність. Основна особливість сайту, коли в активному використанні може затягнути до 1 Мбіт / с за один сеанс. На щастя, щойно користувачі перейдуть на новий фактор іграшок, використання цієї функції, ймовірно, становитиме 1-5% або менше (можливо, набагато менше) часу сеансу.

Однак нові користувачі, швидше за все, гратимуть із цією особливістю, особливо при запуску. Я дуже стурбований використанням пропускної здатності.

Це більш-менш ринкова ніша, тому мені ніколи не потрібно буде масштабувати до шалених рівнів, як YouTube. Однак цілком можливо, що це буде пара терабайт на місяць.

Чи найкращим варіантом є місце розташування? Які дешеві послуги пропускної здатності (колокація / розміщення / хмара / що завгодно) там?


Скільки пропускної здатності ми говоримо насправді (піки), що визначає рівень вашого зобов'язання, що сильно впливає на те, чи є колорія хорошою ідеєю чи ні (з огляду на 95% виставлення рахунків на плитки досить часто)
Tim Post

1
Гаразд, я думаю, що я схиляюся до встановлення жорсткої межі в 10 Мбіт / с. У мене може бути обмежена бета-фаза. Я б розпочав з нього широко відкритим і переключився на обмежені облікові записи попереднього перегляду, якщо я заграв. Це має спрацювати.
darron

Дуже цікаво, який тип динамічного контенту ви генеруєте, для завантаження потрібно 1 Мбіт / с! Відео в прямому ефірі? У будь-якому випадку ви можете перевірити це пов'язане питання: serverfault.com/questions/148629
Грег Брей

Відповіді:


6

Багато що залежатиме від того, скільки паралельних сеансів ви очікуєте. Якщо більше, ніж кілька одночасних сеансів, ймовірно, вам знадобиться щось, що надасть вам 100 Мбіт з'єднання, 1 Гбіт, якщо ви очікуєте більше 50.

Це також буде залежати від того, який тип стійкості вам потрібен - якщо у вас є гарантії безперебійного користування та інші системи угод про надання послуг та / або відмовлення від системи, які потрібно взяти на себе у випадку виникнення проблеми (адже проект досить важливий для короткого простою часу) бути бентежно) тоді ваші варіанти обмежені, а ваші витрати будуть вище.

Якщо ви можете відокремити великі дані від решти програми, тоді вам не потрібно пересувати все до нового хостинг-рішення. Наприклад, якщо великі елементи пропускної здатності - це відеофайли, ви можете десь взяти напрокат виділений сервер із хорошою пропускною здатністю та розмістити їх на цьому - ви можете отримати сервери на хороших хостах із пристойною пропускною здатністю та 100-біт + з'єднаннями напрочуд дешево в ці дні (я плачу 50 доларів на місяць для невеликого сервера з 10Мбітним посиланням, яке я міг би наситити в обох напрямках 24/7, якщо мені потрібно, тому 100Mbit посилання з прикріпленим сервером beefier не буде дорогим, якщо вам не потрібно гарантовано тривалість роботи та інші довідники угоди та / або сервер управління від хостинг-провайдера). Якщо сервер просто обслуговує статичні файли (навіть великі), вам не потрібно багато машини з точки зору процесора та оперативної пам’яті, просто швидкі диски та пропускну здатність. Можливо, варто також ознайомитись із "хмарними" розміщеними рішеннями або мережею доставки вмісту - вони можуть бути простішими в масштабі, якщо ви недостатньо здогадуєтеся, яка пропускна здатність вам потрібна, теоретично набагато більш пружна (тому ви можете отримати гідну гарантію тривалості роботи з компенсацією, якщо вони не дотримуються цієї угоди про угоди). Зберігання роздільної дії пропускної здатності розділеними цими способами має додаткову перевагу, що якщо функція високої пропускної здатності приверне достатньо уваги, щоб вона сканувала, що не блокує всі ваші інші функції одночасно.


Ніяких угод про домовленість, жодних шалених вимог до безперервного часу. Наразі він використовує пристойний шматок процесора / оперативної пам’яті за сеанс. Однак одна осінна коробка повинна обробляти велику кількість одночасних сеансів.
darron

1

Чисто історично:
Ще за часи до ігор у Facebook люди все працювали на веб-переглядачах, текстовому форматі MMO.

Порівняно новим був Огаме. Вона була важкою графікою і картографічною системою в 9 разів 999 сторінок (9 всесвітів з 999 секторами, що вміщають по 15 планет кожна, і кожна планета могла мати місяць).

Кількість приєднаних користувачів була божевільною, а кількість трафіку - тим більше.

То що вони зробили, щоб вирішити це? Вони почали використовувати систему шаблонів PHP і дозволили користувачам розміщувати самі зображення та файли CSS. Все, що вам потрібно було зробити, - це встановити прапорець і ввести абсолютний шлях до базової папки. Вони зберегли б це у своїй базі даних, використали <base>елемент HTML і, і система шаблонів встановила URI з http: // path / to / image to file: /// path / to / image

Після цього всі img-посилання можуть залишатися однаковими. Нічого не потрібно було завантажувати, оскільки користувачі вже мали це. Це означає швидше завантаження сторінки для користувача (маючи на увазі кращі відгуки про товари), а також зменшення пропускної здатності для компанії, що розміщує сайт.

І як додатковий бонус, вони продавали його як "зробити власні власні фони та зображення, чи не ми милі хлопці за те, що дозволяли вам це робити?"


1

Ми маємо сайт з високим трафіком і маємо багато зображень, які завантажуються на кожну сторінку. У нас є виділені сервери, але вирішили розмістити фотографії на Amazon S3 . Це здається, що ви можете говорити про відеофайли чи якийсь інший великий файл, який, на мою думку, все ще застосовуватиметься тут. Ось кілька плюсів і мінусів (для нас)

Плюси

  • Менше дискового простору потрібно на наших серверах
  • Менша пропускна здатність для наших серверів
  • Наших файлів журналів значно менше
  • Ми можемо легко інтегрувати його з Amazon CloudFront, щоб зробити завантаження відвідувачів ще швидшим

Мінуси

  • Це коштує МАЛО дорожче. Ми могли б заощадити трохи грошей, розмістивши їх на власних серверах
  • Менший контроль над ними (Амазонка) знижується ... пощастило нам, вони насправді не знижуються. :)

Інші думки

Якщо про ваші розмови це не мультимедійні файли чи великі завантаження файлів, моя відповідь та кілька інших можуть не мати сенсу. Дайте нам ще детальну інформацію, і ми зробимо все можливе, щоб допомогти.


0

Це звучить як те, що вам потрібно подивитися, це такі CDN , як Amazon Cloudfront .

Ознайомтеся з цими питаннями для обговорення використання CDN:


Коло може насправді мати більше сенсу, якщо він може обґрунтувати мінімальну комісію (як правило, 5 Мб) 95-й відсотковий рахунок. Це означає, що він ніколи не збирається платити за найвищі 5% піків, що в кінцевому підсумку коштує дешевше, ніж сторонні CDN. Важко сказати, нам дійсно потрібно точно зрозуміти, скільки він використовує.
Тім Пост

Моє використання буде майже повністю динамічним контентом, з великим слідом процесора / пам'яті на сеанс. Після гри з інструментом оцінки цін AWS, здається, набагато дешевше піти з колорацією.
darron

Ах, я припускав, що важкі шматки пропускної здатності будуть носіями, на які можна нанести CDN, звучить так, що я гадав неправильно. Хоча якщо у вас є динамічні шматки, які обробляються передбачувано (обмежений набір можливих "фрагментів даних"), ви все-таки можете все це помістити в CDN. Зараз я перестаю намагатися здогадуватися про ваш додаток. :-)
artlung

0

Залежно від цільового стану / країни (або світу), я б використовував багато кластерних ("хмарних") рішень у різних місцях (локальні мережі слід заглянути ;-)). З одного боку ви маєте повний контроль над своїм CDN, а з іншого - вам належить багато зробити (наприклад, моніторинг, догляд за інфраструктурою програмного забезпечення та багатьох інших).

Тож "керовані" рішення, як AWS або щось подібне. Є багато провайдерів CDN / Cloud, що надає широкий спектр функцій.

OFFTOPIC: Погляньте на Лялечку [1] :-)

[1] http://www.puppetlabs.com/


0

Так, вам слід використовувати Amazon AWS щось подібне.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.