Comments 63
По посещаемости трудно определить какая нагрузка при этом будет на сервер. Все это зависит от системы, ее настроек и самого сайта, того, как он написан. В случае с Wordpress они знают что будут хостить свой скрипт и знают какую нагрузку он дает, облачный же хостинг не знает ведь заранее насколько грамотный сайт у вас будет на их сервере.
Но ведь можно же рассмотреть какие-то типовые «конфигурации» и указать приблизительную их стоимость.
На облаке админ вы, на хостингах вроде wordpress вам доступ никуда не дают. Если облачные провайдеры будут показывать такие графики, к ним постоянно будут приставать — вот я посмотрел график, сделал себе так же, а не работает — почему?
Я же не говорю о точности до цента, а о «при вот таких условиях это будет стоить примерно столько».
Например, на сайте мебельного магазина я могу приблизительно прикинуть сколько будет мне стоить то, что я хочу, хотя вариаций там также очень много.
Например, на сайте мебельного магазина я могу приблизительно прикинуть сколько будет мне стоить то, что я хочу, хотя вариаций там также очень много.
Угу, а потом ВЫ положите себе чудо скрипт на сайт или малость модернизируете движок и нагрузка увеличится а десять раз.
Плюс она и так зависит от контента. На одном и том же движке она может отличаться в разы не только из-за настроек, но и и из-за содержимого сайта — сколько новостей на главной, сколько разделов, что за новости и как оформлены и т.п.
Плюс она и так зависит от контента. На одном и том же движке она может отличаться в разы не только из-за настроек, но и и из-за содержимого сайта — сколько новостей на главной, сколько разделов, что за новости и как оформлены и т.п.
И что?
Если я сделал что-то, что стало потреблять больше ресурсов, чем в рассмотренной «типовой конфигурации», то я сам олень и к этому топику никакого отношения не имеет.
Если я сделал что-то, что стало потреблять больше ресурсов, чем в рассмотренной «типовой конфигурации», то я сам олень и к этому топику никакого отношения не имеет.
Да, я не об этом. Я о том, что «типовая конфигурация» — сфероконь в вакууме. Добавите пару новостей на главную, чуть подправите облако тегов, пару фич в стиле AJAX и — опаньки! нагрузка выросла в два раза.
У меня стойкое ощущение, что мы разговариваем на разных языках.
Что вы твердите всё «добавите», «подправите» и т.п.
Мне надо знать что примерно вот это при примерно таких условиях стоит примерно столько, а вот при примерно таких условиях это уже будет стоить примерно столько. И всё. На основании этого я могу примерно прикинуть сколько будет мне стоить моё чудо. Даже если оно на другом движке.
Попробую объяснить на пальцах — я хочу купить авто, допустим, стоимостью в 40 килобаксов. Если я захочу потом поставить ксенон, слепящий истребители в стратосфере, или аудисистему из 20 динамиков, я могу прикинуть сколько это будет мне стоить и потяну ли я это. Но я твёрдо знаю, что изначально авто будет мне стоить ~40k$.
Что вы твердите всё «добавите», «подправите» и т.п.
Мне надо знать что примерно вот это при примерно таких условиях стоит примерно столько, а вот при примерно таких условиях это уже будет стоить примерно столько. И всё. На основании этого я могу примерно прикинуть сколько будет мне стоить моё чудо. Даже если оно на другом движке.
Попробую объяснить на пальцах — я хочу купить авто, допустим, стоимостью в 40 килобаксов. Если я захочу потом поставить ксенон, слепящий истребители в стратосфере, или аудисистему из 20 динамиков, я могу прикинуть сколько это будет мне стоить и потяну ли я это. Но я твёрдо знаю, что изначально авто будет мне стоить ~40k$.
вас точно устроит точность оценки ± 2000%?
Попытаюсь выступить переводчиком. Человек вам говорит, что специфика такова, что ксенон ваш может оказаться платиновым, ценой в 120k$, что сделает бессмысленным первоначальную ориентировку на 40 — уж больно большой разброс, в разы.
И к тому же вы ведь понимаете что нагрузка идет не линейно? что 100 одновременных пользователей вам обойдутся в $7, 105 в $30, 110 в $100, а при 120 ляжет по любому.
Я не против того чтобы знать эту информацию, но вот в том виде как вы просите она бесполезна, не несет никаких знаний, для вашего конкретного случая.
Можно разве что собирать статистику посещаемости и стоимости, а на основе нее предсказывать с какойто точностью границы стоимости для предполагаемой нагрузки.
Я не против того чтобы знать эту информацию, но вот в том виде как вы просите она бесполезна, не несет никаких знаний, для вашего конкретного случая.
Можно разве что собирать статистику посещаемости и стоимости, а на основе нее предсказывать с какойто точностью границы стоимости для предполагаемой нагрузки.
Проблема в том что не будет ни одного человека у кого совпадет конфигурация с типовой.
Да на тотже типовой вордпресс поставь один плагин, одним кликом, и он создаст нагрузку в 10 раз больше. Поставь другой — наоборот упадет в 10 раз меньше.
И это все в пару кликов на типовой конфигурации, а что делать для случая когда ставят не вордпресс, а своб разработку, как считать?
Да на тотже типовой вордпресс поставь один плагин, одним кликом, и он создаст нагрузку в 10 раз больше. Поставь другой — наоборот упадет в 10 раз меньше.
И это все в пару кликов на типовой конфигурации, а что делать для случая когда ставят не вордпресс, а своб разработку, как считать?
Она и не должна совпадать.
Допустим возьмём, что есть информация «Движок такой, его конфигурация такая, http-запросов столько, sql-запросов столько, чего-то там столько, стоит столько» и то же самое ещё несколько раз только с изменённой нагрузкой.
Имея это на руках, я могу, как минимум, поднять у себя такую же конфигурацию, замерить и скореллировать на собственную систему. Отлично пониманию, что не попаду цент в цент, но хоть приблизительное представление иметь буду.
Допустим возьмём, что есть информация «Движок такой, его конфигурация такая, http-запросов столько, sql-запросов столько, чего-то там столько, стоит столько» и то же самое ещё несколько раз только с изменённой нагрузкой.
Имея это на руках, я могу, как минимум, поднять у себя такую же конфигурацию, замерить и скореллировать на собственную систему. Отлично пониманию, что не попаду цент в цент, но хоть приблизительное представление иметь буду.
Ничто не мешает показывать статистику в деньгах. Т.е. я фактически хочу видеть нагрузку на сайт за минуту (не обязательно), сколько это стоило и возможность подключить счетчик посетителей, что бы выразить 1 посетителя в центах/копейках.
Зная сколько «стоит» один посетитель можно понять «сколько» стоит 50 тыс.
Зная сколько «стоит» один посетитель можно понять «сколько» стоит 50 тыс.
Как говорили выше — нагрузка возрастает не прямо пропорционально количеству посетителей. Не говоря уже о том, что разные действия посетителя — разные затраты ресурсов.
По статистике «типовых решений» — тоже затруднительно судить, единственное изменение настройки CMS может значительно повлиять на нагрузки, а грамотная оптимизация может в несколько раз снизить нагрузки.
Оценивать стоимость пользования ресурсом можно, например, исходя из следующих взаимосвязанных параметров:
— обращения к диску
— нагрузка на процессор
— потребление памяти
— нагрузка на сеть
Это легко поддаётся учёту и оценке. И по тесту своего сервиса можно будет примерно представить, к чему готовится по оплате.
Разумеется, можно и предложить значения по «типовым ситуациям», но они будут очень приблизительные и это уже маркетинг.
По статистике «типовых решений» — тоже затруднительно судить, единственное изменение настройки CMS может значительно повлиять на нагрузки, а грамотная оптимизация может в несколько раз снизить нагрузки.
Оценивать стоимость пользования ресурсом можно, например, исходя из следующих взаимосвязанных параметров:
— обращения к диску
— нагрузка на процессор
— потребление памяти
— нагрузка на сеть
Это легко поддаётся учёту и оценке. И по тесту своего сервиса можно будет примерно представить, к чему готовится по оплате.
Разумеется, можно и предложить значения по «типовым ситуациям», но они будут очень приблизительные и это уже маркетинг.
Тестирование сервиса под нагрузкой в 10-20 тыс «посетителей» — накладное занятие, которое фактически будет дороже оплаты «сервера» по факту (если только не нарваться на ddos специально).
но все равно кнопка «затраты денег за последнюю минуту/час/день» было бы очень удобным + возможность задать алерты на превышение показателей.
но все равно кнопка «затраты денег за последнюю минуту/час/день» было бы очень удобным + возможность задать алерты на превышение показателей.
Я имел ввиду не тестирование под реальной нагрузкой, а «простой» тест. Условно говоря, предоставляется $N для теста. И Вы видите, как быстро они расходуются при Ваших действиях. Оценка будет приблизительной, но куда реальнее, чем в сравнении с «типовыми решениями».
От огромного перерасхода можно спастись, установив интегральный максимум ресурсов в единицу времени, разумеется, с алертами, Вы правы.
От огромного перерасхода можно спастись, установив интегральный максимум ресурсов в единицу времени, разумеется, с алертами, Вы правы.
Если я не ошибаюсь, то недавно в топике с анонсом облачного хостинга от Google, в том числе, были указаны цены за различные типы http-зарпосов. Я ещё близко с этим всем не сталкивался, но если такая политика присутствует у всех, то стоимость посещаемости можно оценить.
Ещё можно, например во время тестового периода, зафиксировать нагрузку приложения для наиболее частых случаев. И на основе этой информации рассчитать примерную стоимость.
Т.е. клиент загружает свое приложение, указывает где-нибудь в настройках хостинга что нужно мониторить(например скрипт index.php и список GET-запросов). Потом запускается тест, определяется созданная нагрузка и строится график «посещаемость/цена».
Ещё можно, например во время тестового периода, зафиксировать нагрузку приложения для наиболее частых случаев. И на основе этой информации рассчитать примерную стоимость.
Т.е. клиент загружает свое приложение, указывает где-нибудь в настройках хостинга что нужно мониторить(например скрипт index.php и список GET-запросов). Потом запускается тест, определяется созданная нагрузка и строится график «посещаемость/цена».
а как же проект Scalr.net который как раз и работает по приведенной на рисунке схеме?.. только в реальном времени. Он и создавался чтобы экономить деньги.
И там еще куча плюшек. Есть даже opensource версия.
И там еще куча плюшек. Есть даже opensource версия.
смысл в том, что когда у вас увеличивается нагрузка на сайт — поднимается новый виртуальный сервер по заданной и выбранной конфигурации или из снапшота.
Как только нагрузка упала, то через заданное вами время кол-во серверов постепенно уменьшается.
Фишки [b]Amazonа[/b], а в будущем и др. клауд платформ — в одном месте.
Как только нагрузка упала, то через заданное вами время кол-во серверов постепенно уменьшается.
Фишки [b]Amazonа[/b], а в будущем и др. клауд платформ — в одном месте.
Если указать оценку стоимости для «типовых» примеров:
— сайт на популярной ЦМС (Wordpress, Drupal, Joomla!, 1С-Битрикс и т.п.) с посещаемостью 1000 челвоек в день,
— миллион загрузок 15 КБ .gif-картинки,
— 1000 загрузок 10 МБ архива,
— импорт десяти тысяч записей в БД из файла,
— ну и т.п.
то этого уже будет достаточно, чтобы прикинуть, во сколько обойдется хостинг твоего сайта.
— сайт на популярной ЦМС (Wordpress, Drupal, Joomla!, 1С-Битрикс и т.п.) с посещаемостью 1000 челвоек в день,
— миллион загрузок 15 КБ .gif-картинки,
— 1000 загрузок 10 МБ архива,
— импорт десяти тысяч записей в БД из файла,
— ну и т.п.
то этого уже будет достаточно, чтобы прикинуть, во сколько обойдется хостинг твоего сайта.
1000 загрузок 10мб архива или миллион загрузок гифки с сервера — на windows или linux? nginx/apache/IIS/ftp (ftp-серверов много очень)
:)
все зависит от софта и настроек
:)
все зависит от софта и настроек
Безусловно, от конфигурации зависит очень много.
Суть предложения именно в том, чтобы представить оценку стоимости, а не точный ценник.
Но на то она и оценка, чтобы направить ход мыслей и расчетов потенциального клиента.
Суть предложения именно в том, чтобы представить оценку стоимости, а не точный ценник.
Но на то она и оценка, чтобы направить ход мыслей и расчетов потенциального клиента.
Оценка будет на порядо отличаться для appache и nginex при равном количестве пользователей.
Какая разница? Сделайте 2-е оценки: для индейца и nginx. Сделаете ещё и для других серверов — вообще супер.
госпадя, сделать пару сотен тестов на стандартном конфиге различных решений (вордпресы джумлы и тд) и сделать на его основе калькулятор — соотнести нагрузку на сервера/поток посетителей(просмотров)/тип решения ~ цена за месяц.
а потом в админке говорить клиенту, что у вас вордпрес тянет как два друпала, так что платите как за два друпала — оптимизируйте!
а потом в админке говорить клиенту, что у вас вордпрес тянет как два друпала, так что платите как за два друпала — оптимизируйте!
Вот да, очень правильно что нужно иметь тариф с технически практически безлимитными ресурсами (благо виртуализация и распределение это кое-как позволяют) при том чтобы просто за перегрузку начислялась дополнительная плата. НО чтобы она легко поддавалась прогнозированию (желательно предоставить для этого формулы с примерами из жизни или онлайн-калькулятор) и чтобы провайдер старался отбивать DDoS-атаки, вместо того чтобы радостно записывать в счёт.
ИМХО — Правильная позиция облачных хостеров сгенерить несколько тарифов с гарантированным ресурсами. Весь оверхед должен прозрачно масштабироваться по еще нескольким тарифам.
Может уже пора ввести какие то стандарты для замеров, разработать набор тестов, эмитирующий нагрузку на ряд популярных CMS в дефолтной комплектации со средним размером базы?
Полностью поддерживаю топиккастера! Пора уже давно, вместо абстрактных мегагерцев, указывать гарантированный минимум, операций, способных выполнить сервис под нагрузкой. Я все прекрасно понимаю, и если серверное ПО позволяет указать только процентное соотношение от мощности плюс хостер жестко оверселит ресурсы (это удобно, выгодно и запудривает мозги 'тем, кто не в курсе') то нет никакой необходимости (читай — не выгодно) вводить какой-то другой измеритель, может даже и более удобный для пользователя.
Например Google apps engine считает (и предлагает соответствующие тарифы, позволяющие гибко приобрести именно часы) использование процессора в минутах/часах и на страницах документации приводит даже примеры конфигурации, с которой можно сравнивать и хоть как то оценить наперед затраты.
P.S. Что то непонятное с ценами на этом облаке, даже в минимальной конфигурации цены ощутимо кусачее, чем могут предложить другие представители мира VPS (например находил в интернете варианты от 10$ за xen 128Mb/133mHz или 50$ за тот же xen 1гб озу/1mHz/32Gb диск… что по сравнению с тарифом здесь минимум в два/три раза завышены. В конечном итоге арендовать простенький выделенный сервер (цены от 800р за 2гб/2mHz + 2cpu/320Gb + безлимитка без соотношений порядка 20мб-50мбит по тестам круглосуточно) значительно выгоднее чем туманная надежда на то что запустим сервис в минимальной комплектации и будем повышать нагрузку в зависимости от потребностей… если покрутить параметры до вказанного конфига выделенного сервера, то суммы взлетают до 300$ и выше в месяц, такую цену я считаю несколько неадекватной предлагаемым услугам, особенно в разрезе того, что сама технология виртуализации добавляет ряд потенциальных дополнительных проблем (во время миграции, высокая неконтролируемая нагрузка соседей,..)
но, согласен, побольше конкурентов, больших и маленьких и 'да упадет цена вниз'.
Полностью поддерживаю топиккастера! Пора уже давно, вместо абстрактных мегагерцев, указывать гарантированный минимум, операций, способных выполнить сервис под нагрузкой. Я все прекрасно понимаю, и если серверное ПО позволяет указать только процентное соотношение от мощности плюс хостер жестко оверселит ресурсы (это удобно, выгодно и запудривает мозги 'тем, кто не в курсе') то нет никакой необходимости (читай — не выгодно) вводить какой-то другой измеритель, может даже и более удобный для пользователя.
Например Google apps engine считает (и предлагает соответствующие тарифы, позволяющие гибко приобрести именно часы) использование процессора в минутах/часах и на страницах документации приводит даже примеры конфигурации, с которой можно сравнивать и хоть как то оценить наперед затраты.
P.S. Что то непонятное с ценами на этом облаке, даже в минимальной конфигурации цены ощутимо кусачее, чем могут предложить другие представители мира VPS (например находил в интернете варианты от 10$ за xen 128Mb/133mHz или 50$ за тот же xen 1гб озу/1mHz/32Gb диск… что по сравнению с тарифом здесь минимум в два/три раза завышены. В конечном итоге арендовать простенький выделенный сервер (цены от 800р за 2гб/2mHz + 2cpu/320Gb + безлимитка без соотношений порядка 20мб-50мбит по тестам круглосуточно) значительно выгоднее чем туманная надежда на то что запустим сервис в минимальной комплектации и будем повышать нагрузку в зависимости от потребностей… если покрутить параметры до вказанного конфига выделенного сервера, то суммы взлетают до 300$ и выше в месяц, такую цену я считаю несколько неадекватной предлагаемым услугам, особенно в разрезе того, что сама технология виртуализации добавляет ряд потенциальных дополнительных проблем (во время миграции, высокая неконтролируемая нагрузка соседей,..)
но, согласен, побольше конкурентов, больших и маленьких и 'да упадет цена вниз'.
А чо, нормальная реклама получилась. Всё по чесноку :-)
Я вот теряюсь когда амазон меня спрашивает сколько POST/GET/UPDATE запросов будет к S3 и их BD. Правда для себя я сделал замеры на своем тазике, сделал стресс тестирование, понял какие деньги я буду платить и записал.
Взяли бы VPS вместо облаков. У меня вот за $20 предоплачено 200GB траффика (+сам VPS в той же сумме включен). Хабраэффект на счете никогда не сказывался.
вряд ли ваш VPS выдержал бы хабраэффект, описанный в топике
Мой VPS не заметил даже SlashDot+Twitter+Facebook+HackerNews совместный эффект (статья разошлась), который я заметил только по логам гугл аналитики (сервер не лег и не тормозил). Хабраэффекты не замечаются.
nginx + php-fpm спокойно могут отдавать 10-20 страниц в секунду (а грамотно написанные скрипты с кэшем и eaccelerator — сотни могут давать), а это миллион-два-десять запросов в день. В статье речь идет о 15 тысячах запросов, даже если каждый из них делает еще 3 посещения (очень глубоко) и на все это еще приходится 30 картинок — это полмиллиона запросов в день всего (остается еще полмиллиона-миллион в запасе).
Просто отказывайтесь от Apache для личных целей, от бегемотов вроде WordPress и «эффекты» будут мало страшны. (Пока не узнаете что такое heise.de-эффект :)) вот это было страшно, боюсь представить какой-нибудь китайский эффект — у них там есть блоггер, которого читает миллиард людей в месяц — название даже если бы запомнил — не смог бы воспроизвести)
nginx + php-fpm спокойно могут отдавать 10-20 страниц в секунду (а грамотно написанные скрипты с кэшем и eaccelerator — сотни могут давать), а это миллион-два-десять запросов в день. В статье речь идет о 15 тысячах запросов, даже если каждый из них делает еще 3 посещения (очень глубоко) и на все это еще приходится 30 картинок — это полмиллиона запросов в день всего (остается еще полмиллиона-миллион в запасе).
Просто отказывайтесь от Apache для личных целей, от бегемотов вроде WordPress и «эффекты» будут мало страшны. (Пока не узнаете что такое heise.de-эффект :)) вот это было страшно, боюсь представить какой-нибудь китайский эффект — у них там есть блоггер, которого читает миллиард людей в месяц — название даже если бы запомнил — не смог бы воспроизвести)
UFO just landed and posted this here
А пока не написали (хотя наверное уже писали) вот вам пища для ума: www.insight-it.ru/highload/
Хм… если есть тестовый период, то можно было бы выдавать гибкий анализ будущей стоимости в зависимости от уже реально оцениваемой нагрузки.
К примеру есть сайт с посещаемостью 80000 посетителей в сутки, и пиковыми просмотрами по 12000 в час. Проходилось делать нестандартный кеш который очень неплохо жрет inodes. Load average на сервере в пике при VPS был в районе 4. Сейчас на выделеном сервере работает с load average 0.8-1.
Как мне посчитать стоимость сколько я буду платить? Запросов в БД немного (1-5 в минуту) так как основная масса сайта лежит в кеше (сайт новостной потому нет смысла постоянно к базе обращаться).
Как мне посчитать стоимость сколько я буду платить? Запросов в БД немного (1-5 в минуту) так как основная масса сайта лежит в кеше (сайт новостной потому нет смысла постоянно к базе обращаться).
Спасибо, учтём, попробуем показать типовые нагрузки.
Скажите, а вы использовали их Cloud Servers или Cloud Sites? (IaaS или PaaS)
В случае с Sites, действительно стоимость, не совсем очевидна, а с Servers все предельно ясно, но масштабироваться придется самому
В случае с Sites, действительно стоимость, не совсем очевидна, а с Servers все предельно ясно, но масштабироваться придется самому
Использую CloudSites (действительно, стоило написать об этом).
CloudServers пока не использую, но скоро буду. Во-первых, для того, чтобы организовать memcached (они его предлагают только так организовывать). Во-вторых, у CloudSites есть ограничения на количество отправляемых в день email-сообщений (не более 5 тысяч в день; у меня в сервисе работает рассылка со статистикой каждому пользователю — когда достигну предела в 5000 сообщений в день, рассылку можно будет делать только с CloudServers). Ну и в-третьих, для бекапов.
CloudServers пока не использую, но скоро буду. Во-первых, для того, чтобы организовать memcached (они его предлагают только так организовывать). Во-вторых, у CloudSites есть ограничения на количество отправляемых в день email-сообщений (не более 5 тысяч в день; у меня в сервисе работает рассылка со статистикой каждому пользователю — когда достигну предела в 5000 сообщений в день, рассылку можно будет делать только с CloudServers). Ну и в-третьих, для бекапов.
А у вас Rackspace CloudSites или CloudServer? Если сервер, то какой базовый instance используете для сайта?
(mt) тоже берут только за использованные ресурсы: mediatemple.net/webhosting/gs/faq.php#63
Да, конечно, поддерживаю. Мне было бы интересно решение на 300 руб в день Х, далее, 200-300 рублей в первые месяцы.
Я не делаю крупных стартапов, и не собираюсь держать видеохостинг. Раньше размер оперативной памяти был критичным, сейчас (с появлением nginx) он отходит на второй план, предоставляя руль количеству ядер (воркеры) и ширине канала. Так что в целом решение, приведённое сегодня меня устроило, но на вопрос мощности и стабильности каналов ответ был весьма лаконичным.
Я не делаю крупных стартапов, и не собираюсь держать видеохостинг. Раньше размер оперативной памяти был критичным, сейчас (с появлением nginx) он отходит на второй план, предоставляя руль количеству ядер (воркеры) и ширине канала. Так что в целом решение, приведённое сегодня меня устроило, но на вопрос мощности и стабильности каналов ответ был весьма лаконичным.
если вы хотите донести эту информацию до хостеров, продублируйте пост или укажите ссылку на него на форуме hostobzor.ru
у нас в странице никогда не было цен, аналогичным крупнейшим хостинг провайдерам за границей, и с облаком все также, цены на мой взгляд будут выше, может и на порядок
Как и в любом бизнесе, нужно делать продукт, который будет максимально понятен клиенту. ТС очень правильно все написал.
А зачем нужна такая точность?
7 долларов разницы из примера топикстартера — это 210 рублей. При этом сайт с обычной посещаемостью около 2k получил за 2 дня 52k visits.
На какое решение реально повлияло знание, что это стоило топикстартеру $7? Ну вот действительно?
7 долларов разницы из примера топикстартера — это 210 рублей. При этом сайт с обычной посещаемостью около 2k получил за 2 дня 52k visits.
На какое решение реально повлияло знание, что это стоило топикстартеру $7? Ну вот действительно?
UFO just landed and posted this here
Sign up to leave a comment.
Обращение к облачным хостинг-провайдерам