Минимум год не планируется. Так что располагайтесь на этом :)
Совершенно корректный вопрос. Почему бы и не поинтересоваться.
Никогда эти две команды не были вместе и потому никогда не разделялись.
Одна команда - которая делает платформу NodeSquad. Она едина и неделима и находится наверху всех своих "дочерних". Но очень тяжело ее внедрять в существующие хостинги, потому что у всех уже свои устоявшиеся системы.
Поэтому они решили на каждую страну делать по два три своих хостинга и вытеснять других конкурентов, вместо того, чтобы стараться переводить их на свою платформу. Пока компания еще маленькая, начали только с России. Самое главное - WS и HLC даже не находятся в собственности NSQ. Сделан упор на максимальную децентрализацию. То есть NSQ поднимает хостинг и дарит его своим сотрудникам (вот мне например). При этом каждая компанию имеет свой саппорт, управление и бухгалтерию, но делегированных сверху системных администраторов. Без NSQ дочерние компании существовать не могут.
WS и HLC - две из трех запланированных российских компаний. Каждая из нас должна занять свою нишу рынка. Например мы (WhiteSuite) должны ориентироваться на домашние вэб-студии, SEO-специалистов ну или в край более или менее опытных в мире вэба людей. А HLC ориентируются на людей, которым надо размещаться свои собственные сайты. Ну например рыбаки про свою рыбалку на личных блогах рассказывают или дамочки с собачками обмениваются мнениями. Потому у них нет тарифов.
У нас Вы все сами видите - спектр тарифов, подразумевающий, что человек знает, что такое крон, виртхост и база данных.
Какую третью компанию запланировали - я не в курсе, но знаю, что сначала хотели запустить в Китае, после чего поняли, что не смогут это сделать на ISPmanager (она написана полностью на русском и не переведена ни на один язык - попробуйте восстановить пароль на английском хотябы :) ). Сейчас NSQ пишут новую платформу под блейды без использования ISPmanager, так как это единственное слабое звено в платформе. Мало того некачественное, так еще и сдерживает всю архитектуру. После этого запустят начатую компанию в Гуанчжоу, а затем третью русскую.
Вам советы от пользователей нужны или предложения хостеров?
Вы лучше не по окончанию, а по продолжению отписывайтесь :) Мы хотим, чтобы Вы на долго пришли.
Но все же мы лучше без антирекламы в следующий раз. И обычной теперь хватает. Особенно сарафанное радио лучше любой контекстной работает.
Огромное спасибо за признание!
Всмысле сделать еще один черный пиар? 😂
Satellit'ы отличаются от Web'ов только дисковым пространством. Там тяжело разместить полноценный сайт. То есть различия только технические (ну не считая того, что сателлиты от 10-ти сайтов).
Reseller'ы отличаются от Web'ов тем, что есть прослойка между нами и хозяином конечного сайта. Технически же в точности тоже самое. Различия только в управлении своими данными. Вы можете взять бесплатный период любого из них и потрогать своими руками, так сказать.
Да. Если, конечно, есть лицензия.
Сервера разные бывают :) Можно поместить 1000 сайтов на крошечный сервер на основе Atom, а можно 1000 таких же сайтов поместить на HP Superdom.
У нас крейсерская загрузка рассчитана на 3000 сайтов на EQ9 от Hetzner (только измененная конфигурация). Но проверить правильность расчетов можно будет чуть позже - пока еще не набрали столько пользователей.
Пожалуйста! Это приятно, что кто-то интересуется темой и работа инженеров получает внимание.
Хотябы понятно ради кого работаем.
Мы можем показать. Но для пояснения что к чему понадобится еще в пять-шесть раз больше текста, а обилие информации отпугивает клиента. Ведь придется объяснять про нелинейные зависимости распределения количества запущенных процессов и еще кучу ненужной клиенту информации. Ведь если на тарифе в один сайт 16 процессов, то это не значит, что на тарифе в два сайта из 32. Их там всего 24. Именно добавление 8 процессов удваивает производительность ровно вдвое, из-за неровного распределения процессов по времени запуска (и времени окончания).
Причем цифра 24 у нас уже три раза подстраивалась (+/-2) в зависимости от накопленной статистики.
Это взрыв мозга для простого клиента, которому всего-то надо сайт расположить. Я лучше, вот как Вам, всем интересующимся буду рассказывать.
Кроме количества процессов также регулируются:
1) Количество прочитанных секторов с диска, в том числе для асинхронного режима. Это что-бы у клиента не было возможности вгрузить диск по полной и не дать другим жить. Так как один сайт читает меньше, чем два сайта, то у него и количество байт будет ниже. Чтобы справедливость восторжествовала.
2) Процессор регулируется по количеству времени работы с ним.
Совершенно прозрачно. Вы просто перепутали две разных вещи. То что написано на сайте - от тарифа не зависит действительно. Размер выделяемой памяти, время работы процесса от тарифа не зависят.
Попробую объяснить еще раз:
Есть время исполнения одного процесса - оно фиксированно для всех тарифов и равно 90 секундам.
Есть объем памяти, выделяемый под один процесс - он фиксирован для всех тарифов и равен 128Mb.
Но в зависимости от тарифа можно запускать разное количество процессов по 128Mb. Например для минимального тарифа это 16 одновременных процессов (на сайте минимальное количество обещано).
Конечно скрипты далеко не все упираются во временные рамки и рамки объема, но все же такое случается. В идеално худшем случае, если каждый пользователь на каждый сайт запустит по 16x128Mb, то мы получим по 2Gb единовременного расхода RAM на каждый из трех тысяч виртхостов на сервере - 6Tb в оперативной памяти при реально физических 36Gb. Понятно, что разместить такую нагрузку мы не можем.
Далее начинается вечная дилема каждого виртуального хостинга: 6Tb не отъедят, потому что на практике столько никому не надо. Но один сайт отъесть свои 2Gb может. И 50 сайтов могут одновременно отъесть своё (тогда 100Gb). Поэтому в границы памяти все же изредка упереться можно. Снижать цифры 128Mb или 16 нельзя также, потому что из-за спасений от этой ситуации, которая настает не чаще раза в неделю ежесекундно будут страдать пользователи (некоторые CMS даже не стартанут на 64Mb). Уменьшать количество процессов также нельзя, потому что отвалятся все AJAX-чаты.
Это была ситуация общая для всех хостеров. Именно поэтому даже при введении жестких ограничений 10 толстеньких клиентов может съесть полностью всю память и положить сервер.
И судя по постам на сервере, это не редкое явление.
Что делать хостерам, если у них на сервере оперативки меньше 100Gb? Вот теперь входят в действие описанные выше механизмы распределения памяти.
В момент когда один пользователь отъел более своей доли, но не мешает никому, никто его не трогает, но как только эта доля понадобилась остальным - начинается уравниловка и восстановление справедливости.
Кроме того, все вышеописанное касается только оперативной памяти. А как делить процессорное время и количество операций ввода-вывода? Ведь там не существует жестких лимитов. Их даже мерять нечем (когда хостер обещает сколько-то герц, то он просто неграмотен и говорит чепуху).
WhiteSuite добавил 02.03.2011 в 12:44
К сожалению у нас нет доменов третьего уровня, но напишите в тикетку и я думаю, мы что-то придумаем инетерсное для Вас :)
