Перші дні в Інтернеті: як не вбити свій сайт

Припустимо, у вас є цей фантазійний новий сайт, з великою кількістю даних (наприклад, великих зображень), і ви збираєтеся розмістити його в Інтернеті. Якщо ви робите «занадто багато» реклами, протягом перших днів сайт буде переповнений запитами.

Як я можу зменшити цей ризик?

Я подумав

• жити поступово, як SO та SF: "приватна" бета, публічна бета, публічна
• дозволити X з'єднання сеанси одночасно, тому підключений користувач все ще має хороший досвід роботи сайту, а інші мають гарне повідомлення про вибачення

Я не можу:

• купуйте більше серверів, так як після перших днів на сайті буде набагато менше трафіку :)

1. Кешуйте стільки, скільки можете. Будь-які сторінки, що створюються динамічно, повинні кешуватися, щоб користувачі отримали статичну версію. На компонентах сторінки, які запитують db, також слід кешувати.
2. Спробуйте скористатися зовнішньою службою, на зразок Amazon S3, для розміщення зображень та мультимедіа (або підготуйте її до використання, якщо сайт раптом потрапить у тону трафіку).

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

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

Скільки планування входило у вашу модель даних? Ви створили схему, яка дозволить вам збільшити обсяг запиту без дорогих сортів, двійкових стовпців чи складних приєднань? Ви налаштували резервну копію вашої бази даних (якщо вона є)?

Як ви обслуговуєте свої "великі образи"? Чи можете ви розділити це на окремий процес веб-сервера, навіть окремий домен?

Ви завантажили тестовану систему? Такі інструменти, як ApacheBench і Siege, безцінні.

Чи вся ваша конфігурація у svn? Чи розгортається автоматичне розгортання? Ви будете раді цьому, коли вам доведеться розгорнути нашу програму на 2-му сервері.

Система запрошень іноді може бути хорошим способом контролю за користуванням сайтом користувачем. На початку видайте певну кількість запрошень, щоб сайт не перевантажувався. Потім дайте кожному користувачеві кілька запрошень, щоб передати їх іншим, повільно збільшуючи кількість користувачів на сайті. Таким чином, ви не наберете занадто багато людей, які потрапляють на сайт на початку, і ви не отримаєте масового піку трафіку.

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

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

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

Ви можете заглянути в стороннє розміщення хостингу статичного вмісту, такого як Amazon S3. Залежно від вашої програми, це може бути достойним і для того, щоб заморозити деякі (наскільки я ненавиджу молитву) за допомогою Amazon EC2.

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

DreamHost - один із прикладів:
http://www.dreamhost.com/hosting-vps.html