Коментар към поста на Мишел за хостинг :)

Пускам го тук, защото както опитмишизираният правилно отбеляза, коментара към темата му „Съществува ли (почти) неограничен хостинг?“ стана прекалено обемист …

Част от електронната кореспонденция с една от компаниите, които не влязоха в класацията ми.

Аз: “Не съм имал проблеми, и дано да нямам. Нека пак така, неофициално, Ви попитам следното – колко милиона, имейл кутии, бази данни, ФТП акаунти и поддомейни мога да направя, преди да ме предупредите? А мога ли без проблем (повярвайте, имам познанията и техническата възможност) да си направя и да ползвам милиарди?”

Те: “до сега не сме имали клиент които да е бил спрян поради превишаване на тези лимити. Естествено лимитите като използвано процесорно време и използвана рам памет не са неограничени и са описани в правилата ни за ползване.
Имаме клиенти които ползват около 500 емайл акаунти (за конкретния клиент – спедиторска фирма, всеки служител има емайл които се проверява когато е на път) и не са имали проблем. Всички тези неограничени параметри са реално достъпни. Опитайте да създадете колкото искате емайл акаунти и ще видите, че няма да имате проблем с това.”

Аз: “Позволете да копирам какво сте написали там:
Системни ресурси: Процесорно използване, SQL процеси
чл. 2 1. Допустимото CPU% (Процесорно време), което моеже да се използва от даден Потребител (потребителки акаунт) е 60-80 минути в интервал от 24 часа.
– 1% CPU = 14.40 минути.
2. Доставчикът е длъжен да уведоми Потребителя за предстоящи действия от негова страна, освен в случаите касаещи чл.2 т.2
3. Доставчикът не е длъжен да уведоми Потребителя за предстоящи действия от негова страна в случаи изискващи моментна реакция и/или превишени лимити на процесорно използване над 75%.

От първата точка на чл. 2 нищо не разбрах, ако може да ми го обясните като на 10-годишен? Втората е ОК, и едва от третата разбирам, че процесорния лимит е 75%, което също не е особено полезно – тоест не знам кой процес колко натоварва някой от процесорите ви, и няма как да го знам … За SQL процеси няма нищо, нито за RAM памет.
Така, значи да разбирам, че няма проблем да създам 5 милиона електронни кутии, в същия акаунт 5 милиона MySQL бази, на същото място 5 милиона ftp акаунта, и пак толкова поддомейна? И ако съм на план, различен от ултима+про – НЕОГРАНИЧЕН месечен трафик? И да започна да ги експлотирам активно? Разбирате много добре, че практически тези неща СА ОГРАНИЧЕНИ по един или друг начин. Именно това е дразнещо за мен – в началната страница да пише, че тези параметри мога да ги ползвам безкрайно, а в условията и правилата – нещо съвсем различно и поне за мен – неясно. Може да е много малко вероятно някой потребител да достигне границите на неограничеността на услугата, но принципното противоречие си остава.
За да не съм само мрънкащо-критичен, едно предложение – до думата неограничен да има примерно две звездички: “неограничен**”, и отдолу с достатъчно читаем шрифт да поясните, че все пак ограничение има, и то е еди-какво-си. Да, пак е евтин рекламен трик, но е по-коректно спрямо потенциалните клиенти.”

Те: “Извинявам се забавата, но се наложи да изискам, позволение да ви пиша от Супервайзър.
1. Може би сте забелязали, че *** е една от малкото или бих казал единствената компания , която ясно описва колко може даден потребител да натоварва даден сървър, ясно се описват позволените норми за споделен хостинг , които са завишени от стандартните такива поради по-големия резерв, който *** осигурява върху сървърите.
2. Ако вие претоварвате акаунта си в продължение на 72 часа и натоварването не спада, оператор на *** е длъжен да Ви уведоми за това за да вземете съответните мерки по оптимизация или ъпгрейд към по-голям план ако е възможно. Пак показател, който много други компании не правят, а просто спират клиентския акаунт.
3. Ако примерно акаунта е подложен на атака или натоварва сървъра извън допустимите норми, то оператор е длъжен да предприеме своевременни мерки за да запази буфера на сървъра , както и безпроблемната работа на другите потребители на дадената машина.
Ако създадете 100000000000000 mysql бази данни, ftp акаунти , mail кутии няма проблем. Защо да се ограничат потребителите с 10 или 50. Нека те решат колко са им нужни. Основния параметър е процесорното използване, по който се ограничават , защото лишаването на даден клиент да има 10 кутии, като с това няма да може да използва пълноценно акаунта си, а ще използва само 10% примерно е неетично.
До колко разбирам дразнят ви високите параметри, а ви привличат ограниченията, така че да не използвате пълноценно даден акаунт. Мен лично ме дразнят жълтите таксита, белите престилки на лекарите, шопска салата с лук … но всеки има своите предпочитания.
Независимо дали ще се предложи на потребителния 1 или 1000000000000000000000 бази от данни или емейл кутии, всеки споделен хостинг, повтарям ВСЕКИ, има ограничение в MYSQL конекциите за секунда или MYSQL заявките за час, както и в броя на изпратените емейли за час (поне поради СПАМ полица). Така че защо НЕ, нека потребителя използва акаунта си на пълни обороти а не да се ограничава всячески.”

Изводът – всички да хукнем към *** и да тестваме :)

7 мнения по „Коментар към поста на Мишел за хостинг :)

  1. Мерси, че създаде нов пост (и така „пренесе“ коментара от моя пост)! :)

    Накратко и тук да добавя само:

    Неограничен хостинг не съществува! Това е ясно и на децата в първи клас;-)

    Не ми се вярва да мога да създам 1′000′000 бази данни на който и да е от съществуващите в момента хостинги… Но, от друга страна – за какво са ми един милион MySQL бази данни? Та аз не мога да ги използвам!

    В моя случай (optimiced.com), аз мога да хоствам неограничен брой домейни, имам много голямо дисково пространство, ползвам PHP5 и мога да създам колкото си искам бази данни. Но аз просто нямам нужда от толкова голям ресурс.

    Всеки хостинг е лимитиран от сървърното натоварване много повече, отколкото от гигабайтите заето сървърно пространство или от броя сайтове, които се хостват. Ако моят хостинг план използва разумна част от този сървърен ресурс, мисля, че няма значение, дали хоствам един или 100 сайта…

    Поради това смятам, че получвам добра сделка. Ако един ден имам сайт със 100′000 посетители дневно — е, тогава ще му мисля, къде и колко сървъра да наема за целта :-D

    Но дотогава – фактът, че имам контролен панел, където броят хоствани от мен сайтове или количеството създадени MySQL бази данни не е ограничено, не ми пречи да си ползвам удобно моя хостинг. Да, хостингът ми не е неограничен. Но не е и „лъжа и измама“, защото знам, че има лимити на сървърното натоварване в shared hosting environment, и аз съм в рамките им.

    В моя случай, ако имам добре направен сайт, съм сигурен, че няма да имам проблем и с 5000 посетители дневно. Именно заради принципа 90-10! А ако наистина един ден имам сайт(ове), които искат 24 CPU hours/day… е, май много преди това ще ми е ясно, че ми трябва собствен сървър, а не shared такъв и няма да има от какво да се оплаквам ;-)

  2. Сещам се, че вече сме писали в коментарите към поста ти за М. Дейвидсън – ползата от wp-cache за WordPress при големи натоварвания :). В смисъл, че ми се струва добра идея да не се натоварва излишно споделения хостинг, който се ползва, с интелигентно и правилно настроено кеширане на блога. Когато се наложи де … или когато очакваме нещо подобно на digg ефекта.

  3. Да, прав си за кеширането. Но ако блогът ти има трафик от около 200-500 посещения дневно, няма нужда от кеширане, според мен – рано е:)

    Иначе е вярно, ако имаш кеширане, трафикът не е толкова голям проблем… :)

  4. Хехе , неограничен хостинг :) .

    Имам няколко web приложения , които ако ги кача където и да било за 10$/месец, ще ме изгонят на първия час. Едното приложение доста успешно натоварва 3Г пентуим на 100% и изяжда цялата памет.

    Най сигурната работа е собствен сървър забутан, я на колокация, я при местния доставчик за малко пари .

  5. @ss7:

    Аз ползвам WordPress и не мисля, че товаря сървъра и на 1% ;-)

  6. Честно да ви кажа с тези темпове на покачване на скоростта на интернета в цяла България не ви трябва „чужд“ хостинг … Хоствайте си сами ;)

  7. Pingback: Blog.Caspie.Net

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *