DLag: Торговая марка Geliar, которую вы так искали между прочим официально зарегистрирована.
- честно говоря, мне это параллельно (юмор: virtuozno), просто потрясание числами VPS аккаунтов показалось на редкость бессмысленным (без обид, просто рассуждения о числах и их относительной ценности)
Brim.ru добавил 13.05.2009 в 23:50
QuickAurum: Было утверждение, что на 64 мб не встанут апач и майэскуэл, а не апач, майэскуэл и ЦМС, требующая 256 мб. Это утверждение опровергнуто эксперементом. Если б шел разговор про то, что на 64 мб не поставить пхп-скрипты требующее 256 мб я бы спорить не стал, и дураку понятно, что если требует 256 то не зря требует :)
Но для проверки напустил ab на phpinfo . При 10 одновременных запросах 2 секунды на один запрос. Если не одновременные то по 0.1 секунде. Уже неплохо, но пропогандировать такой тариф как пхп-хостинг не буду, компания прибыль потеряет :)
- извините, но Вы вроде изначально представлялись как маркетолог, возможно Вы не знаете что при обращении к phpinfo запросы к MySQL не идут и то что Вы поставили MySQL на аккаунт это хорошо, но с таким же успехом Вы могли поставить PostgreSQL, Oracle, Bitrix, Drupal и т. д., обращения к phpinfo их никак не тестируют. Т. е. фактически Вы протестили Linux+Apache+PHP, причем что то победных реляций, о свободных 18Мб после запуска ab, уже не слышно (рад уже тому что Вы перестали чморить конкурентов не предлагющих никому Xen-64).
- если Вы настаиваете на своей позиции, никто не мешает любому заинтересованному лицу провести "нормальный" тест предложенного тарифа и вывесить соответствующие скриншоты ;)
QuickAurum: Сейчас поставил на True10 (самый маленький тариф) с 64 Мб физ. оперативы и 128 Мб спаввинга пресет Simple LAMP - mysqld, apache2, mod_php. phpinfo показывается вполне быстро. Свап не используется вообще. free показывает 18 Мб свободной памяти.
- многие популярные CMS требуют для PHP!!! 64-256Мб ОП. Понятно что "Hello, World!" на одном запросе отработает нормально :) но это не имеет мало отношения к реальным сайтам :) Если не трудно, дайте URL, народ сможет коллективно потестить этот сайтик (хорошо бы к MySQL шел запрос, а то она как-то ни при делах оказывается, только зря место на диске занимает) - получится для Вас бесплатное нагрузочное тестирование и реклама, если все работает нормально.
- поразительно что в этом форуме встречаются лузеры которых хостер прогнал за нагрузку, ведь как оказывается весь LAMP умещается 64Мб ОП и еще 18Мб остается 😂
LineHost: Это ничего не значит, если говорим о серверах. К примеру, но я то знаю ситуацию какая она у нас ;)
- я не спорю, но зачем людям в лицо тыкать "вы знаете, вы не знаете"? Если бы речь шла о публичных компаниях, тогда можно было бы поговорить об отчетах и т. п., но хостеры закрыты (на IPO не выставляются) и получить адекватную информацию о рынке и его масштабах затруднительно, только по косвенным данным (например 1stat для ru/su зон, блоки ip адресов, whois и т. п.). В связи с чем число 438 VPS лично мне ничего не говорит :) (клиенты распределяются по странам, VPS распределяются по типам и т. д., так что 438 это почти "ответ на Основной Вопрос Жизни, Вселенной и Всего Остального"). Если кто то может сказать что рынок VPS имеет емкость 100000 клиентов, то можно как-то, худо бедно, оценить число 438 (и то если верить на слово пользователю форума)
DLag: Данные только по нашей компании.
Общее количество VDS сейчас 438, не нужно быть маркетологом чтобы понять что это ощутимая доля общего рынка.
...
Вы совершенно не знаете ситуации.
- не только мы не знаем ситуации, но похоже и 1stat тоже ;)
Кстати, если говорить серьезно, без минусов в репу и т. п., разве это они предоставляют хостинг? Вроде хостинг через них продает rusonyx? Раньше эта информация была на сайте reg.ru, а сейчас видимо просто убрали.
Boris A Dolgov: У FastVPS на XEN давным-давно получилось ;)
Тогда объясните почему они отказались от этого чудесного и выгодного тарифа? Сейчас у них минимальный тариф XEN-1 имеет 150 MB RAM и лично меня это ни сколько не удивляет, тарифы Xen с 64Мб это добровольная порча своей кармы ;)
Boris A Dolgov: 1. В принципе, согласен. Но под что-то простое и 64 хватит (например, bind под вторичный сервер, nginx чтобы отдавать статику на пару тысяч парковочных доменом, под ту же самую почту). Важно понимать, что для каждого случая - свой тариф.
- попробуйте запустить *nix + bind (или не важно что еще) на 64Мб - теоретически это возможно, практически - это не доставит Вам никакого удовольствия и по всюду будут ограничения и проблемы, малейшая нагрузка и все уйдет в свопирование. Для Вас это возможно, потому что на OpenVZ это не 64Мб, а 64Мб+ (в плюс попадает все что еще есть свободного на сервере), и пока у сервера есть еще какие-то ресурсы аккаунт чувствует себя нормально и работает на этих 64+ Мб ОП. Если Вы забьете весь сервер не оставив резерва по ОП такими аккаунтами, то окажется что все работает очень хреново, так как аккаунт получит 64Мб+0. Xen в этом плане абсолютно предсказуем - есть 256Мб ОП и если на них все работает, то оно и будет работать независимо от того как далеко простирается моя жадность.
Boris A Dolgov: 2. Увы, мой опыт работы с XEN нулевой, знаю только теорию. Если не сложно, поясните.
- речь идет о разумной работе со своп разделами аккаунтов (советы очевидные любому сисадмину, типа - не делай своп на RAID 1, и т. д.)
Boris A Dolgov:
3. А почему? Ведь когда 5 впсок активно юзают рандом по диску - скорость будет выше, чем когда 40 впсок активно юзают рандом по диску.
- что касается диска, проблемы тут у всех технологий примерно одинаковые (можно и шаред вспомнить) - чем больше аккаунтов, тем больше проблем :) и решения тут те же что и на шаред - SAN и т. п.
Boris A Dolgov: Особенно плохо придется, когда впски начнут свопиться на свои виртуальные диски.
- чтобы такой проблемы на возникало, надо:
1. Не делать VPS c маленьким количеством ОП! IMHO, 128 Мб это тот минимум который позволяет Xen VPS работать без свопирования, но который нельзя использовать под мало мальски нагруженные сайты. А уж разговоры про 64Мб у меня постоянно вызывают, мягко выражаясь, недоумение и сомнение.
2. Как говорил тут кое-кто, "надо уметь их готовить" 😎 (я имею в виду свопы - кто в теме поймет, кто не в теме, тому и знать не к чему)
3. Если будет "плохо" это станет ясно сразу, а не когда жадный хостер забьет весь сервер аккаунтами по 64Мб. Если будет "хорошо", то ничего не изменится, даже если хостер забьет весь сервер аккаунтами. В этом плане Xen-виртуализация (с учетом правильного создания хостером свопов) существенно более предсказуема, в отличие от OpenVZ, где проблемы с диском также могут возникнуть при увеличении количества аккаунтов, а вот память на аккаунтах по 64Мб может исчезнуть совершенно неожиданно и как тогда будет работать софт, на гарантированных 64Мб, остается только гадать (а потом клиенты начинают рассказывать байки - был хороший хостер, да испортился, сначала летало все, а теперь еле ползает).
Торговая марка Geliar, которую вы так искали между прочим официально зарегистрирована.
- честно говоря, мне это параллельно (юмор: virtuozno), просто потрясание числами VPS аккаунтов показалось на редкость бессмысленным (без обид, просто рассуждения о числах и их относительной ценности)
Brim.ru добавил 13.05.2009 в 23:50
Было утверждение, что на 64 мб не встанут апач и майэскуэл, а не апач, майэскуэл и ЦМС, требующая 256 мб. Это утверждение опровергнуто эксперементом. Если б шел разговор про то, что на 64 мб не поставить пхп-скрипты требующее 256 мб я бы спорить не стал, и дураку понятно, что если требует 256 то не зря требует :)
Но для проверки напустил ab на phpinfo . При 10 одновременных запросах 2 секунды на один запрос. Если не одновременные то по 0.1 секунде. Уже неплохо, но пропогандировать такой тариф как пхп-хостинг не буду, компания прибыль потеряет :)
- извините, но Вы вроде изначально представлялись как маркетолог, возможно Вы не знаете что при обращении к phpinfo запросы к MySQL не идут и то что Вы поставили MySQL на аккаунт это хорошо, но с таким же успехом Вы могли поставить PostgreSQL, Oracle, Bitrix, Drupal и т. д., обращения к phpinfo их никак не тестируют. Т. е. фактически Вы протестили Linux+Apache+PHP, причем что то победных реляций, о свободных 18Мб после запуска ab, уже не слышно (рад уже тому что Вы перестали чморить конкурентов не предлагющих никому Xen-64).
- если Вы настаиваете на своей позиции, никто не мешает любому заинтересованному лицу провести "нормальный" тест предложенного тарифа и вывесить соответствующие скриншоты ;)
Как это:
хостингу на РЕГ.РУ уже около полугода
сочетается с этим:
просто хостинг рег.ру работал на базе Русоникса и при поддержке его специалистов, в остальном - абсолютно разные вещи.
- так чей же хостинг и кто его фактически оказывает?
Сейчас поставил на True10 (самый маленький тариф) с 64 Мб физ. оперативы и 128 Мб спаввинга пресет Simple LAMP - mysqld, apache2, mod_php. phpinfo показывается вполне быстро. Свап не используется вообще. free показывает 18 Мб свободной памяти.
- многие популярные CMS требуют для PHP!!! 64-256Мб ОП. Понятно что "Hello, World!" на одном запросе отработает нормально :) но это не имеет мало отношения к реальным сайтам :) Если не трудно, дайте URL, народ сможет коллективно потестить этот сайтик (хорошо бы к MySQL шел запрос, а то она как-то ни при делах оказывается, только зря место на диске занимает) - получится для Вас бесплатное нагрузочное тестирование и реклама, если все работает нормально.
- поразительно что в этом форуме встречаются лузеры которых хостер прогнал за нагрузку, ведь как оказывается весь LAMP умещается 64Мб ОП и еще 18Мб остается 😂
Интересное обсуждение в тему.
- читаю это и понимаю что нас и других Java-хостеров либо не существует, либо надо существенно повышать цены на Java-хостинг 😂
Это ничего не значит, если говорим о серверах. К примеру, но я то знаю ситуацию какая она у нас ;)
- я не спорю, но зачем людям в лицо тыкать "вы знаете, вы не знаете"? Если бы речь шла о публичных компаниях, тогда можно было бы поговорить об отчетах и т. п., но хостеры закрыты (на IPO не выставляются) и получить адекватную информацию о рынке и его масштабах затруднительно, только по косвенным данным (например 1stat для ru/su зон, блоки ip адресов, whois и т. п.). В связи с чем число 438 VPS лично мне ничего не говорит :) (клиенты распределяются по странам, VPS распределяются по типам и т. д., так что 438 это почти "ответ на Основной Вопрос Жизни, Вселенной и Всего Остального"). Если кто то может сказать что рынок VPS имеет емкость 100000 клиентов, то можно как-то, худо бедно, оценить число 438 (и то если верить на слово пользователю форума)
Данные только по нашей компании.
Общее количество VDS сейчас 438, не нужно быть маркетологом чтобы понять что это ощутимая доля общего рынка.
...
Вы совершенно не знаете ситуации.
- не только мы не знаем ситуации, но похоже и 1stat тоже ;)
gelihost.com - 1stat серверов не нашел
sun.geliar.com - 1stat серверов не нашел
- может Вы продаете VDS под другой торговой маркой? может tuthost.com? - 1stat нашел 8 серверов
Кстати, если говорить серьезно, без минусов в репу и т. п., разве это они предоставляют хостинг? Вроде хостинг через них продает rusonyx? Раньше эта информация была на сайте reg.ru, а сейчас видимо просто убрали.
У FastVPS на XEN давным-давно получилось ;)
Тогда объясните почему они отказались от этого чудесного и выгодного тарифа? Сейчас у них минимальный тариф XEN-1 имеет 150 MB RAM и лично меня это ни сколько не удивляет, тарифы Xen с 64Мб это добровольная порча своей кармы ;)
1. В принципе, согласен. Но под что-то простое и 64 хватит (например, bind под вторичный сервер, nginx чтобы отдавать статику на пару тысяч парковочных доменом, под ту же самую почту). Важно понимать, что для каждого случая - свой тариф.
- попробуйте запустить *nix + bind (или не важно что еще) на 64Мб - теоретически это возможно, практически - это не доставит Вам никакого удовольствия и по всюду будут ограничения и проблемы, малейшая нагрузка и все уйдет в свопирование. Для Вас это возможно, потому что на OpenVZ это не 64Мб, а 64Мб+ (в плюс попадает все что еще есть свободного на сервере), и пока у сервера есть еще какие-то ресурсы аккаунт чувствует себя нормально и работает на этих 64+ Мб ОП. Если Вы забьете весь сервер не оставив резерва по ОП такими аккаунтами, то окажется что все работает очень хреново, так как аккаунт получит 64Мб+0. Xen в этом плане абсолютно предсказуем - есть 256Мб ОП и если на них все работает, то оно и будет работать независимо от того как далеко простирается моя жадность.
2. Увы, мой опыт работы с XEN нулевой, знаю только теорию. Если не сложно, поясните.
- речь идет о разумной работе со своп разделами аккаунтов (советы очевидные любому сисадмину, типа - не делай своп на RAID 1, и т. д.)
3. А почему? Ведь когда 5 впсок активно юзают рандом по диску - скорость будет выше, чем когда 40 впсок активно юзают рандом по диску.
- что касается диска, проблемы тут у всех технологий примерно одинаковые (можно и шаред вспомнить) - чем больше аккаунтов, тем больше проблем :) и решения тут те же что и на шаред - SAN и т. п.
Особенно плохо придется, когда впски начнут свопиться на свои виртуальные диски.
- чтобы такой проблемы на возникало, надо:
1. Не делать VPS c маленьким количеством ОП! IMHO, 128 Мб это тот минимум который позволяет Xen VPS работать без свопирования, но который нельзя использовать под мало мальски нагруженные сайты. А уж разговоры про 64Мб у меня постоянно вызывают, мягко выражаясь, недоумение и сомнение.
2. Как говорил тут кое-кто, "надо уметь их готовить" 😎 (я имею в виду свопы - кто в теме поймет, кто не в теме, тому и знать не к чему)
3. Если будет "плохо" это станет ясно сразу, а не когда жадный хостер забьет весь сервер аккаунтами по 64Мб. Если будет "хорошо", то ничего не изменится, даже если хостер забьет весь сервер аккаунтами. В этом плане Xen-виртуализация (с учетом правильного создания хостером свопов) существенно более предсказуема, в отличие от OpenVZ, где проблемы с диском также могут возникнуть при увеличении количества аккаунтов, а вот память на аккаунтах по 64Мб может исчезнуть совершенно неожиданно и как тогда будет работать софт, на гарантированных 64Мб, остается только гадать (а потом клиенты начинают рассказывать байки - был хороший хостер, да испортился, сначала летало все, а теперь еле ползает).