Yoda

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

Да что ты КЭП, правда? А зачем тогда он нужен simple при пошаговом оформлении. По моему у нас опять кружок вредных советов.

Мама, моя дорогая, какой умный... А ничего что 99% американцев не понимают как оформить заказ на одной странице и им нужно пошагово? А ничего что у нас есть магазин в котором мы проводили эксперименты и детальный анализ показал, что пошаговое оформление (с урезанным набором данных) более эффетивно и понтяно для покупателя чем одностраничная колбаса? А ничего что, если убрать меню и хлебные крошки на странице заказа, конверсия может увеличиться на 20-50%. Какие 90%.... Это вас на варезопомойках ваших такому бреду учат?

Модуль текдок, работает через api поставщика. Лог запросов тут не при делах совсе. Не давайте глупые советы. Вам повезло. Но вы даете советы на 99% владельцу вареза... Так как изначально эти вопросы надо отправлять поставщикам сервиса... Вы всегда за варез ? Давайте выложим ваш шаблон бесплатно и дадим на него ссылку на форуме.

У меня получилось поднять все и завести как-то... Подчеркиваю как-то. С десятой попытки. Потратил я на эксперименты наверное недели три..

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

Извините, может я вас расстрою но с таким подходом у вас вылезет тьма подводных камней. Во первых у 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 экстренно пересоздавать. Вобщем добавляейте место под кеш картинок. Если не поможет - приходите!

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

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

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