Yoda

Извините, может я вас расстрою но с таким подходом у вас вылезет тьма подводных камней. Во первых у Ukraine VPS устарели. Актуальное железо, если мне не изменяет память у них было в 2013 году, я как раз в тот момент задался для себя поиском сервера и остановился на их железе, так как оно было самое быстрое. Сейчас есть масса впс-хостингов в 2-3 раза дешевле и мощнее... Во вторых. ISP панель и сборка конфигурации, которую они устанавливают устарела, при чем критично. Даже не столько с точки зрения самой панели, сколько с точки зрения дырявых пакетов самой операционной системы, которые создают потенциальную уязвимость вашему магазину. В третьих. ISP 4 и ISP5 - это как старый запорожец и новый мерседес. В пятой версии они сделали безумный скачок. И пятая панель действительно закрывает нехватку навыков администрирования. Четвертая - это ад и Израиль. И еще. Кроме переноса на VPS ему требуется настройка. Почта, бекапы, кеширование статики, тюнинг mysql, изменение потенциально уязвимых портов и так далее...

Да при чем тут пафос. Таблица на 200-300 000 записей умирает при частых операциях чтения не только из-за локов а из-за перестроения индексов. И о чем мы ща спорим? А мы спорим, о том что долбить в нее по одной записи абослютно неэффективно, когда можно пихнуть 1000 записей за один запрос, и закрыть в принципе все проблемы с локами. Что касается ботов и задержки. Ну не ходят они равномерно и по графику. У пассивной нагрузки всегда есть рапределенные стохастические всплески, которые при постоянном обновлении легко валят голые проекты. На InnoDB мешает перейти full-text индексы, который поддерживает только mariadb10, которая недоступна в большинстве хостинг-платформ. И опять же я не понимаю в чем суть спора. Я долблю про технологию партицированного парсинга уже четвертый год. Какая сложность это реализовать ? У меня есть пример магазина, в котором 500 000 товаров. В нем весь каталог товаров подвешен в Sphinx, при этом база постоянно обновляется - ни единого разрыва. Разнесенные хранилища в разные контейнеры - это абсолютно минус головная боль... Да вы сейчас скажете, что сфинкс надо еще поставить настроить. Ок не вопрос. Кто мешает вам сделать два контейнера в рамках Mysql ?

Прочитайте выше внимательнее. Я вас ничего не просил мне объяснять, а просил показать пример проекта, к которому вы имели отношение, который можно было бы хотя бы с натяжкой назвать успешным магазином. Вместо этого вас как остапа понесло и вы начали переходить на личности. Это говорит о вашем "уровне квалицикации более чем". Но к сожалению ваша квалификация высока только в навыках высокопарно разглагольствовать ни о чем. Думаю, что не у меня одного сформировалось подобное мнение. А что я в состоянии или не в состоянии понять и что мне делать, извините, я уж решу без сопливых специалистов разговорного жанра. Спасибо.

Какие цифры... О чем вы сейчас. Я говорю о базовых принципах работы msysql. Когда мы пишем в таблицу, если она в Myisam - она лочится на чтение. В принципе... Если лочится таблица oc_product и у нас есть хоть какой-то трафик даже от ботов, этот лок вызывает лавинообразный поток наслоения процессов apache, потому что php стоит и ждет. Поэтому если происходит нон-стоп парсинг, то у нас постоянно заперта то одна то вторая то третья таблица, а таблиц с товарами допустим пусть будет 10... Соответсвенно 10 мс превращаются в 100. А в это время нас все время ждет очередь запросов на чтение... В итоге нагинается целиком весь проект. Что мешает сделать промежуточные клоны таблиц p2c p2s ps pd и так далее. Загонять в них 500-1000 наборов данных и одним большим запросом мерджить это с боевыми таблицами - я не знаю. Это достаточно просто. Но видимо все очень уверены в своем скиле. Кроме этого. При изменении данных в любой таблице, сбрасывается внутренний кеш mysql, который мог бы работать на тех запросах которые не используют NOW(). К сожалению, вам лень читать мануал. Давайте все таки начнем с того, что вы внимательно изучите принцип работы MySql с таблицами MYISAM, изучите механизм блокировки и работы кеша. А потом мы начнем говорить дальше.... 2.1 ЕЩЕ РАЗ!!! КЕШИРОВАТЬ нативно ЗАПРОСЫ Mysql средствами PHP, это как мыть голову шампунем, одевая резиновую шапочку. Можно - но сродни идиотизму. 2.2 Если сайт непосещаем. Это не значит что он не будет посещаем в будущем. Если мы говорим о проекте даже на 20 000 товаров. То раз в три дня его должны обойти два бота гугл и яндекс. А это 40 000 посещений за 72 часа... А это 555 заходов в час и 9 заходов в минуту. Это при идеальном роботсе и настроенном сео, а так умножайте на 4, и получаем 36 pageview в час. А кроме этого есть другие боты. А кроме этого есть какие-никакие посетители и так далее... Любой проект, должен быть живым "на холодную". Кеширование - это приятный бонус для повышенной нагрузки на повторяющийся контент. Разработка парсера не так страшна, если у вас есть готовая бизнес-логика обновления товаров и вам достаточно поменять драйвер API поставщика контента. По сути ничем не будет отличаться от смены классов используемого хранилища для кеша в в 2.3 opencart. Обновлять реал-тайм данные в контейнере - да легко. Вот тут подробнее: http://sphinxsearch.com/docs/current/rt-overview.html

2 - нет нет и еще раз нет. Во первых это возможно только для Яндекса, гугл в упор не видит эту директиву. Во вторых. Снижать частоту посещения ботов - это равнозначно грызть себе руку. 2.1 - так же в корне неправильно, читаем мануал к mysql. Она отлично сама кеширует запросы, но в формает постоянно обновляемых данных и данных о просмотре товаров, данная техника неактуальна от слова совсем. 2.2 - в нынешних реалиях от memcache есть прирост только при обращении к повторяющимся данным, как-то например в сео про с кешем от фрилансера. Но на 50 к товаров в сео про кеш вреден больше чем полезен. А в остальных ситуациях, когда происходит одинарное чтение данных из кеша, прирост от memcache по сравнению с файловым кешем ssd - минимален. А при небольшом тюнинге библиотеки файлового кеша и вовсе нивелируется в рамках статистической погрешности. 3. У ботов нет дня и ночи, они не спят. Получить от яндекса пессимизацию с его новым оценочным алгоритмом, который требует ttfb < 3 сек - можно автоматически при такой технике. Топик стартер совершенно верно формулировал мысль но не довел ее до конца. Если мы говорим о идеальном парсинге. Нам обязательно нужен промежуточный контейнер. В виде какого-то хранилища. Либо мы можем использовать технику перевода front-end выдачи каталога на индекс sphinx целиком, а не только поиска, и парсинга товара в базу данных с периодической переиндексацией сфинкса. Для регулярного real-time обновления данных о товарах opencart в коробке и существующие парсеры к сожалению, не сильно подходят. Я обсуждал концепции порционного обновления боевых таблиц как с @usergio так и с @MaxD несколько лет назад. Дядя Сережа покивал головой, сказал круто и забыл. А второй персонаж даже не понял зачем нужны какие то промежуточные таблицы, ведь и так же все вроде работает.

Я абсолютно в этом уверен. Так как после 20 000 товаров. Возникают технологические сложности не связанные с движком, а связанные с технологическими особенностями PHP и MYSQL. Из которых, чтобы вам понятно было, конкретно явные - это : а) быстрый контексный поиск, который слабо реализуем на php+mysql, даже через match against б) резервирование нагрузки системы под всплески посещений ботов в) если мы говорим о конкретном случае. И регулярном парсинге остатков, наличия, цен. Необходимы механизмы обхода блокирования таблиц в базе данных при постоянном обновлении данных и перестроении индексов. мог бы дальше продолжить, но мне кажется этого достаточно. приведите аргументы, если не прав хотя бы по этим пунктам.

Простите, но мне очень интересно. Серега ломик и спектрум - это одно лицо или нет. Если да - то почему он переименовался.. Накосячил и стыдно и прячется за другим ником, либо за ним есть другие косяки, о которых не знает сообщество. А так же меня очень волнует смог ли этот "специалист" оптимизировать его супертормознутые стикеры, и убрал ли он загрузку своих поделок с собственного дырявого сервера ?

не рекомендую связываться с человеком с рейтингом 1 в реализации сложной задачи! При полном заполнении не тормозит и миллион! А вы спросите, прежде чем такое пишите! от 20 000 товаров - это не сайт - это сложный проект!

Положить вот такой .htaccess RewriteEngine On Options +FollowSymlinks RewriteBase / DirectoryIndex index.html RewriteRule ^(.*)$ index.html [L]

Подсказки дают в MIT 5 лет подсказок, обойдутся вам в 300-500 000$ долларов. Но нет гарантии, что после курса подсказок вы сможете написать парсер.

Перенос + настройка сверера $100 апдейт верси от $300 Retail - 200 Серт - $50 Все цены от... Если тянете - расскажу где вам сделают без промывки мозгов и рассказок про то какие все крутые специалисты. Вот ничего не будут рассказывать а просто сделают!

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

ну 50 мегабайт, это не 2-3 гигабайта. Так что вполне вероятно у вас вся проблема в нехватке места под кеш изображений. Выход только один - добавлять место!

Тут скорее жалобу должна подавать @Katalina за плагиат! А не человеки!

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

Места- мало! И входящий трафик - совершенно логичный результат, так как боты переиндексируют регулярно статические ресурсы. А у вас когда кеша нету вместо них динамическая 404 страница, а так как скорее всего магазин у вас тупой - это 1.5-2 секунды загрузки. А кешированнных превьюшек у вас должно быть на 10 000 позиций 40-50 000. Вот к вам боты пришли, картинок нет. Пошли активно проверять а их совсем нет. Убили ваш сервер + забили лог ошибок если он у вас есть. Кеш изображений без особой надобности чистить нельзя! А если почистили, надо пауком типа xenu экстренно пересоздавать. Вобщем добавляейте место под кеш картинок. Если не поможет - приходите!

По вопросам проблем с доступности - обращайтесь! Дорого и круто!

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

Кеш картинок, логи ошибок, кривые бекапы, кривой кеш. Если кеш картинок - то единственный вариант расширять место на серванте. Если все остальное решается. И да - нагрузку тоже надо искать.

А теперь развернуто и по теме, дабы не обвинял меня никто в голословности. Так как opencart - по своей сути это система для генерации динамического контета, она не может быть абослютно защищена от ДДОС - потому что ключевое слово динамическая. Если говорить о том, как сделать действительно работающую защиту, то нужно понимать что она должна быть многослойной. а) ваш хостер должен вас защищать от UDP и sin флуда. б) у вас должен быть оооочень быстрый магазин с запасом ресрурсов в 500-1000%. в) в вашей системе должен быть настроен мониторинг нагрузки г) у вас должны быть настроены инструменты оперативного реагирования на нестандартные всплески. д) ни один глобальный кешер вас никогда не спасет - так как подделать post-данные и сформировать реальную сессию пользователя, которую невозможно кешировать - это задача для школьника. е) капчи не спасают, китайцы все еще едят лапшу в горных пещерах и сервисы по обходу каптч безумно дешевы. ж) вышевысказавшийся персонаж рассказывает про ISP и запароливание админки через htpass, должен расстроить дважды. Во первых htpass - техника придуманная во времена, когда ips еще в памперсы мочилась, во вторых они ввели фичу паролирования директорий, не потому что А потому что это нормальная практика в принципе. Но более нормальная практика, держать на продкашене только фронтенд, если мы говорим о том "как надо" и практиках. з) И реально господа, вот вы когда создаете подобные темы, вас же вроде в гугле не забанили. Это очень обширный вопрос, который в рамки форума никак не помещается. И то что можно сделать средствами движка - это скажем 10-20-30%. Все остальное это серверно-админские технологии, по которым советов и рекомендаций в гугле читать можно на пару месяцев.

Вы знаете, не в обиду будет сказано гомосексуалистам, но в их среде бытует мнение что массаж простаты - это некая божья благодать, и всем пренепременно необходимо прочувствовать всю глубину глубин сего волшебного действа. К счастью, гомосексуальных особей в любой популяции не больше 4%. К сожалению ваши вопли, попытки возмущаться, строить из себя суперспециалиста, и аппелировать к неким спецам из ISP в безвыходной ситуации, мною воспринимаются не более, чем хвальба массажа простаты четырьмя процентами популяции. Уж простите, но такой имидж у вас сформировался в моих глазах, в глазах моего подельника, и я думаю что не только у нас такое стойкое мнение. Поэтому, прежде чем задавать мне вопросы подобного толка, разберитесь в себе, почему создается устойчивое впечатление, что вы вы апологет массажа простаты. Возможно все-таки у вас есть малюсенький шанс изменить свою ориентацию, ну или по крайней мере, научиться перестать навязывать ее проявления другим. UPD для администрации. Я готов на бан за этот пост на неделю, месяц, год, но извините Sitecreator со своим "всемогузнаювсеменявсеобижают" уж очень портит ленту форума, и читать его профанские посты в каждой второй теме, и бесконечно опровергать его чушь у меня увы иссякли силы.

Наш вовсевовпросыответ-герой выучил новое слово DDOS атаки. Скажите вы не устаете от своей бесконечной клоунады сами? Какой ДДОС на админку? На админку может быть брутфорс! А укладывать магазины через админку - фу фу... Можно же применить более изощренные методы, которые известны школьникам, а вы про них даже не догадываетесь!

Продам готовый интернет-магазин одежды и обуви Украина 45000-50000 грн. 3000-5000 грн за "посмотреть".

Нет не лукавят.

centos7 + isp5 Панель вам снимит 99% головной боли с адмнистрированием. А centos имеет более продвинутый механизм установки пакетов, нежели дебиан или убунта.