Аренда интернет-магазина

2 Александр Фролов

Совместимость с 1с входит в какой-то тариф или это дополнительная опция? Если дополнительная, то во сколько она обходится к клиентам?



резервное копирование разве не стандартная функция любого хостера? Я тут маханула весь сайт через делит , мне его хостеры почти ночью быстренько восстановили



вроде продвижение сайта не входит в арендную плату?

Александр, вы зачастую правы, за исключением что рассматриваете медаль с одной стороны. Своей. Не упоминая о другой.

Не блокируют, а предлагают перейти на другой тариф. Но стоимость мощностей сегодня и пять лет назад в разы разная. Что давно стоило 3000 рублей месяц, щас рублей 150. И чтобы нагрузить такого хостера — эт надо еще суметь. =)


"Серъезный проект" — при какой пиковой нагрузке?


Есть dreamhost.com
Тааакая рабочая лошадка, что мама не горюй. Сто сайтов в сумме 100 000 посетителей. Стоимость... 6 уе в месяц =)
Правда, последнее время, к русским что-то как-то прохладненько... =(
И нагрузка зависит не только от количества, но и от реализации движка.


То он, зачастую, эти траты потянет с головой.


Однако, оплачивают это клиенты, и поэтому купленное принадлежит им. И вы потом чужие идеи не используете перепродавая другим?


Стоит упомянуть, что не всегда это бывает возможно (из-за реализации). Но при переходе "от к" — надо учитывать (точнее, специалист по дефолту это учитывает).


Придумать может каждый дурак, а вот это реализовать... =)
Что касается бизнес-процессов. Есть просто правила. Придумывай не придумывай все равно упрешься в константу. Другой вопрос, что этого многие не знают (или забывают).

Обычно от 3000 руб. единовременно, но все зависит от сложности реализации. У всех, как правило, разные конфигурации 1С и разные потребности по интеграции.



Да, хороший хостер обязательно делает резервные копии. Но не всякий делает эти копии по схеме 6 ежедневных, 3 еженедельных, 3 месячных, а месячные закачивает и хранит неограниченно долго. Не всякий хостер сможет восстановить товары определенного производителя, которые по ошибке удалили полгода назад, а теперь надо восстановить (такой запрос у нас был пару раз у разных клиентов). Т.е. обычные хостеры восстановят базу, файлы, но они не будут копаться с восстановлением определенных товаров, заказов или контактов. Мы это делаем. Кроме того, мы делаем дополнительные копии на другой физический сервер для быстрого восстановления.



Конечно не входит. Здесь я пытаюсь сказать, что затраты на аренду или приобретение движка пренебрежимо малы по сравнению с затратами на продвижение магазина.

Может я скажу удивительную для кого-то вещь, но есть клиенты, которые интересуются стоимостью аренды или движка в последнюю очередь, т.к. это для них не самое главное. Если дорогой или дешевый движок или хостинг будет простаивать, то ежедневные потери таких клиентов будут намного больше стоимости движка. Поэтому их интересует в первую очередь надежность решения.







На самом деле, именно блокируют, причем автоматически - поинтересуйтесь в Мастерхосте. А загрузить хостера очень просто. Попробуйте, например, сделать несколько выгрузок в день магазина недвижимости с базой размером 500 Мбайт в два-три каталога, когда каждая выгрузка может идти около часа - и все. Вам тут же придется брать виртуальный или физический сервер. У нас, например, есть магазин, в котором 150000 товаров, импортируемых раз в день из базы данных DBF - тоже создает нешуточную нагрузку на наш физический сервер.

Суть моих замечаний по хостингу заключается в том, что для простых и малопосещаемых проектов вполне подойдет обычный недорогой хостинг. Но когда проект разрастается, а сайт становится очень посещаемым, про виртулаьный хостинг можно сразу забыть. Соответственно, резко возрастают затраты на хостинг, и они могут легко перекрыть арендную плату.

Я это говорю не просто так, мы сами набивали себе шишки на виртуальном хостинге несколько лет назад, пока не перешли на физические серверы.



Понятие нагрузки не простое. Может быть сайт, у которого несколько тысяч посещений в день, но все эти посетители обращаются к статическим страницам каталога, а может быть сайт, с посещаемостью в несколько раз меньшей, но каждый посетитель создает большое количество сложных запросов к базе данных. И заранее трудно сказать, какой из сайтов будет больше загружать сервер.

Обычно мы наблюдаем за нагрузкой, которую дает тот или иной магазин, и магазины, которые нагружают сервер очень сильно, переносим на менее загруженные или более мощные серверы.



Да, и еще как зависит от реализации. К нам обратился владелец одного раскрученного магазина, у которого страницы описания товаров загружались больше минуты (!). Магазин был сделан на ос-коммерц. Когда мы посмотрели архитектуру базы данных, то обнаружили, что база была полностью нормализована до 4 формы. При этом формирование каждой страницы товара сопровождалось лавиной запросов к серверу базы данных, в результате чего и происходило такое замедление. У нас все страницы товаров статические, поэтому при их загрузке вообще нет ни одного обращения к базе данных.



Наш подход заключается в том, что мы выполняем заявки наших клиентов на изменение функциональности магазинов. Как я уже писал, большинство заявок касается модификации бэк-офиса под бизнес-процессы каждой конкретной компании, это нельзя продать несколько раз. У нас, например, есть неколько магазинов недвижимости, в которых реализованы соверешнно разные подходы к продажам. Что же касается универсальной функциональности, то она у нас уже давно вся реализована и что-либо новое добавляется крайне редко. Обычно речь идет только о небольшой настройке.



Для того чтобы сохранить результаты поискового продвижения при смене движка, достаточно сделать так, чтобы по старым адресам были доступны старые страницы. В Апаче есть механизм, который позволяет настроить соответствущим образом переадресацию, иногда приходится писать дополнительные модули совместимости. Полагаю, что любому производителю движков для сайтов эти технологии известны и доступны.



Обычно бизнес-процессы развиваются вместе с торговой компанией, меняются при изменении ее масштабов. И там где заканчивается бэк-офис небольшой торговой компании (список заказов, сделанных за день), бэк-офис крупной компании только начинается.

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

Вот здесь обсуждается, что происходит с сайтами, перегружающими Мастерхост: http://forum.searchengines.ru/showthread.php?t=347013

Вот выдержки из Приложения 2 к оферте:

"9.12. В случае превышения лимитов процессы, вызывающие перегрузку, могут быть отключены.

9.13. В случае если подобное превышение лимитов происходит систематически и Абонент не принимает мер по нормализации ситуации, после предупреждения ресурс может быть заблокирован."


Вообще если поизучать этот форум и еще хостобзор, можно много интересного узнать про хостинговых провайдеров. Я выбрал мастерхост потому, что мы долго хостились у них, и ощутили на себе все проблемы виртуального хостинга.

А мастерхост (как и инфобокс) и не рекоммендую выбирать по множеству причин =)


Ну тут, как бы, и сидя на стуле можно шею свернуть и руки-ноги переломать. Было бы желание. =)
Если магазин недвижимости серъезный — по-любому будет свой сервер.


А я дампером 450 000 за 10-15 минут востанавливал (уже писал про dreamhost). С небольшой нагрузкой.
Может тут тоже имеет смысл через формат проводить. На пару шагов длинее, зато потом быстрее.

Обычный хостинг подойдет для многих проектов. Но, согласен, многое зависит от многого.
Можно суметь сделать так, что и один человек положит весь сайт, а можно — что и 10 000 будут комфортно чувствовать.
Тут больше все потому, что многие берут готовый движок (который сам по себе, например, быстрый), но навешивают на него кучу всего (часто ненужного и мешающего) не думая как это будет происходить "внутри".
Ну а если уже предел по посещаемости (когда: "проект разрастается, а сайт становится очень посещаемым"), то часто с конверта уже нормально получается и сумма для аренды своего уже не так смущает.


В смысле заранее трудно? Это же ваша система (единая для всех магазинов) и вы знаете узкие нагрузочные места (запросы)? Почему не переписать или изменить структуру? Кэшировать запросы. Результаты запросов (не всех, а части). Контент. Как весь так и часть. Разнести таблицы и т.п.


А тут всё зависит от количества товаров (если они переводятся в статические) и от того как организована эта статика.
Если статика как она и есть (т.е. если обращаются /folder/page.html) и эта страница там и лежит (в этой же папке) — это одно.
А если статика при обращении выдается из папки кэша — это другое.
Если товаров очень много — то тратиться время на поиск этого файла с диска и его выдачу. Спасает разбивка по папкам, но тоже время.
Поэтому тут надо замерять что будет быстрее. Смотреть как и что.
Оскомерц (не его модификации. т.е. голый) он сам по себе тяжеленький и требует подточки. Но и новички с ограниченным бюджетом его не выбирают.


Посещаемость просядет.
Ведь будет зависеть не только что по этой ссылке пошел редирект на другую (сопоставленную). Но и от содержимого той новой страницы. Ведь на новый движок не переходят на 100% сохраняя всё. Часть переделывают или по другому организовывают-реализовывают. Вот эти переадресации (редиректы 301 или 302) как команда поисковику переиндексировать страницу. Вдруг она уже не та и не удовлетворит прежним условиям (фильтрам) по ранжированию.
Если не дает модреврайт - спасет "модуль совместимости". Если не спасет модуль совместимости — ничего не спасет.
Ведь модуль совместимости — это скрипт с описанием правил что за что считать и куда перенаправлять. И бывает что алгоритм даже и не составишь. В силу количества когда нельзя автоматизировать, а всё руками.

Тут дело не конкретно в мастерхосте, любой провайдер считает деньги и контролирует использование своих ресурсов. Вопрос в том, что провайдер будет делать, когда ваш ресурс начнет загружать хостинговый сервер слишком сильно.




Вовсе не обязательно брать свой сервер и налетать на большие затраты. У нас, например, на одном довольно мощном сервере успешно работают несколько крупных проектов. За счет особенностей нашей архитектуры ПО и распраделения нагрузки эти проекты не испытывают взаимного влияния.

Приличный сервер стоит 80000-100000 руб., его размещение может обойтись примерно в 3000 руб. в месяц, услуги администрирования - еще несколько тысяч рублей в месяц. Кроме того, нужно будет купить хостинг или второй сервер для хранения бекапов, если нужна защита от потерь данных при выходе из строя основного сервера.

Так что по затратам приобретение и содержание своего сервера может обойтись заметно дороже аренды магазина недвижимости (и не только недвижимости).



Структура и запросы у нас уже оптимизированы, кэширование встроено в ядро. Для наших проектов мы можем примерно оценить, что будет с нагрузкой, и принять правильное решение о размещении на том или ином нашем сервере, либо о приобретении дополнительного сервера под тяжелый проект.

Что же касается абстрактных оценок нагрузки неизвестно какого сервера сайтами, созданного на базе чужих движков в зависимости от количества посетителей, то мы их не делаем, т.к. не видим в такой работе никакого смысла. Хотя если провести анализ, то это можно сделать. Другое дело, что обладателям виртуального хостинга или даже виртуальных серверов обычно не бывает доступна системная статистика загрузки сервера. Для анализа также недоступна загрузка сервера другими сайтами.

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

Обычно происходит так - клиента перестает устраивать скорость работы сайта, и он начинает искать людей, способных решить эту проблему. Мы предлагаем свое решение - переводим сайт на наше ПО, на наш сервер, и проблема низкой скорости загрузки страниц исчезает. Клиенту не надо думать о выборе хостинга, оптимизации, кэшировании и пр.



Да, конечно. У нас уже есть наработки, поэтому мы знаем, как сделать так, чтобы арендованные у нас сайты работали быстро.



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



Тут все зависит от опыта компании, которая разрабатывает движок и переносит на него магазин. Авторы движка могут доработать его любым необходимым образом, чтобы сохранить и контент, и адреса страниц. Если же переносом занимается человек, который только умеет устанавливать чужой скрипт и выполнять его простейшую настройку, то результаты могут оказаться плачевными для продвижения.

В том то и дело — что нормальный провайдер предупредит и даст определенный срок. Либо переделывай, либо переходи на тарифный план более тебе подходящий.
Александр, если чесно я не поверю, что у вас на площадке интернет-магазины типа Озона или Лабиринт-шопа. Но судя по вашим сообщениям о нагрузке — так оно и есть =)


Либо вариант не брать свой и ставить в стойку (colocation), а за те же 3500 арендовать точно такой же. Только не всем это надо. Свой сервер нужен не каждому. Хостинга многим и очень многим просто хватит с головой. А кому понадобиться сервер, то означает, что большая нагрузка. А большая нагрузка в большинстве из-за посещаемости. И в большинстве конверт уже такой, что для него 3500 будет не проблема. А просто так с тысячи человек чтобы не хватало хостинга и надо переходить на свой — так не бывает. Ну за исключением, если там не болтается что-то убийственное. Но и убийственное тоже же надо еще смочь сделать.


Александр, давайте не будем рассматривать уж совсем крайности. =)
Даже в крайнем случае есть админы датацентра, которые заинтересованы чтобы вы от них не съехали и не создавали нагрузок. Подскажут или укажут проблему.


Политика компании (о разглашении) разрешит на них посмотреть?


И стоить это ему будет столько, что этот перенос никто не потянет. =)
Ну, например, Лабиринт-Шоп решил к вам переехать. Сколько ему будет стоить полностью перенестись к вам?
А Озон?
А Амазон?

Вот в этом как раз и проблема. Мы начинали с виртуальных хостингов, и когда провайдер начал блокировать скрипты, то предложил нам перейти на физический сервер. У нас было всего два дня, чтобы купить сервер, установить его на площадку и перенести сайты. Все это время скрипты то и дело блокировались, и нам пришлось вручную их переключать.

Пока мы возились с переносом, магазины работали с перебоями...



Нет, у нас нет магазинов, которые требуют для работы многосерверных кластеров с системами балансировки нагрузки. Но есть магазины с количеством посещений порядка несколько тысяч в день, с размером каталога порядка 120000 товаров, а также со встроенным складским учетом, логистикой, учетом продаж, развитой отчетностью и другой очень сложной функциональностью бэк-офиса.



Аренда сервера в хорошей конфигурации стоит в разы больше. Кроме того, в аренду сдаются, как правило, не очень мощные и надежные серверы. Как правило, в них нет встроенного KVM, поэтому если потребуется доступ к консоли, не всегда его можно быстро получить.

Мы арендовали серверы, но перешли на собственные, т.к. нас не устраивали предложенные конфигурации, в том числе и по надежности.



Как раз и не обязательно. В случае, о котором я рассказывал, большая нагрузка возникала потому, что просмотр страниц каталога товаров вызывал огромное количество обращений к базе данных с созданием временных таблиц.



Они подсказывают. Мне, помнится, заблокировали скрипт добавления товара в корзину, который просто создавал одну запись в одной таблице, и предложили его оптимизировать)

В реальной жизни провайдер предлагает перейти на свой сервер, что вызывает многократный рост ежемесячных затрат.



Не вижу особого смысла, т.к. не с чем сравнивать - старого магазина уже нет на прежнем хостинге. Но можно просто посмотреть сайты в нашем портфолио.

Что касается переноса с других хостингов, то мы можем создать точно такие же страницы, которые были раньше, и по тем же адресам. При этом страницы будут загружаться быстро, и я не вижу причин, по которым могла бы упасть посещаемость.



Здесь не нужно смешивать такие разные проекты. Проекты такого масштаба, которые мы можем потянуть, переносятся, как правило, не дороже стоимости открытия нового магазина аналогичной функциональности.

Что касается Озона и Амазона, то на создание подобных проектов требуются огромные деньги, для них открываются отдельные компании, датацентры, нанимается персонал на полный рабочий день. Если с этими магазинами что-то не так, и программисты не справляются, можно просто нанять новых, более опытных)