- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
MageMerlin, причем тут трафик? Речь идет только про обработку базы.
Вы же, как покупатель, не готовы ждать пока VDS переберет миллионов десять вариантов, а потом еще поищет совпадения в прайсах, по каждой найденной позиции?..
А если свои каталоги? )))
Не. Это стойка, а то и две. Либо партнерские дела, как выше уже говорили.
Я не знаю, как вы себе представляете функционирование скриптов, реально это выглядит так приблизительно - скрипт выполняет локальные операции, потом выполняет запрос в БД, потом его отрабатывает и выдает результат. Здесь два узких момента
1) инфраструктурные расходы на посетителя на веб-сервере (апач и т.д.)
2) расходы на запрос и обработку запроса к БД
Если у вас тяжелый в смысле вычислений код - то оторвать руки программисту, или нечастая задача, которая не является типичной для посетителя сайта. Поэтому тут влияет кол-во юзеров
Если у вас база маленькая и оптимизирована, но запрос кривой - то и 1 пользователь долго ждет. Избавляется от джоинов и все будет летать (то есть вопросы к оптимизации запросов к БД)
А вот если у вас все оптимизировано - втает проблема
1) размера базы
2) кол-ва юзеров, одновременно ее дергающих (то есть трафик)
Т.к. у типового ИМ база не может быть большой (большая база - это миллионы транзакций весом в десятки гигов, которые постоянно висят в оперативе в силу специфики формата БД, содержащие какие-то относительно длинные текстовые данные типа useg agent посетителя, referer и так далее) - то горлышко бутылки при прямых руках - именно трафик в смысле посещений
Хотите стойку купить - покупайте. Наверное, на битриксе сидите. Нормальные скрипты не предъявляют таких требований к железу на малых посещениях
Поэтому
Приблизительный, расчетный объем номенклатуры 2-3 ТБ - это что касается только основной номенклатуры, т.е. без сайтов, движков, статики и пр.
Из того, с чем я косвенно сталкивался. Базу номенклатуры VW Мускул не тянет, адекватно работать с ней получилось только на мелкомягком, а там цена бодрящая.
Не знаю у кого там руки кривые были на тот момент, но не трудно догадаться, что VW это не самая большая марка, есть еще BMW и MB... а есть GM.
Вот по этой причине есть десяток магазинов типа exist, и все остальные.
Все остальные просто выкладывают свое наличие + некие сервисы для увеличения конверсии, чаще арендованные. Этот вариант и на шареде можно выложить:)
Мускул бывает разный
1) версия (ага она влияет)
2) тип таблиц
3) структура таблиц (такого можно наваять...)
4) правильно расставленные ключи
5) запросы (опять же, есть любители JOIN запросов, их ИМХО нельзя использовать там, где не надо)
6) архитектура самого "кластера" (если вы выделяете под мускул сервер с достаточным кол-вом оперативы и правильно его настраиваете - все будет ок)
Поэтому как-то так. С одной стороны - есть пример, 150к хостов в сутки, каждый хост генерит 2-3-5 хитов, не очень много. 80% инсерт запросы, 20% селекты. Внутри замороченная архитектура, но все оптимизированно. Так вот, под БД выделен за $150 сервер с 16 гигами оперативы, поднарастили до 32 впоследствии. Все летает.
И альтернативный пример. Не знаю какой трафик, бд 160 гигов, и написана очень-очень криво. Так вот, там куплено что-то немеряно дорогое, но все равно каждый alter table - только с дауном на несколько часов и только по подписанной служебке.
Так что оно по разному бывает
По функционалу фронтенда exist почти ничем не отличается от других таких же сайтов на основе каталога TecDoc - единственый и существенный плюс у них , это то что сразу можно по ВИН коду вбить и будет предложен выбор запчастей под конкретную модель авто.
П.С. Как вариант можете поюзать такой как у меня в подписи
igor3310, какие оптимальные требования к хостингу?
6. На ваши овермного+ позиций будет накладываться проблема чуть ли не ежечасной переоценки товара т.к. поставки валютные, а торговля за рубль. Это ОЧЕНЬ большая проблема. А если вы не автоматизируете это - прямая дорога к недовольству клиентов, заказывающих это все по одной цене, а получающих по совершенно другой после перерассчета
Поддерживаю все пункты кроме шестого. Это вообще не проблема. Кроме времён, когда курс меняется несколько раз в день.
Прайс в уе. Приход в уе. Учётная цена в 1с в уе. Можно вести учётную цены во множестве валют. У нас доллар, евро, гривна.
И проблема номер один - трафик.
Совет всем начинающим. "А давайте сделаем ещё один экзист" это путь в никуда. Попробуйте придумать что нибудь оригинальное.
igor3310, какие оптимальные требования к хостингу?
Диск не менее 90ГБ , сейчас стоит оперативы 4ГБ - (но прайсы когда глотает нагрузку дает - я на локале импортирую , а потом СуперДампексом перекидую) , и все более никаких требований более нету , разве что РАМ побольше
У меня друг владелец СТО и магазина запчастей, а также они создали ИМ - но там много тонкостей, с удовольствием помогу тебе найти все ответы на твои вопросы.
Вам нужно найти человека, которому вы сможете довериться, и который знает все нюансы.