842 replies to this topic

[Юра Мамонтов]

Странная проблема после размещения на хостинге, перестала работать корзина. 

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

 

ДНС тестировал, запись А находит, на хостинге сказали глянуть в .htaccess, а уменя там тишь да гладь, пока ничего не правил.

 

Кто-нибудь сталкивался с таким, в чем может быть проблема?

[laRus]

Юра Мамонтов, ссылку на сайт не дадите?

[Юра Мамонтов]

Ссылки:

 

http://www.gorod-remesel.com/ и http://gorod-remesel.com

 

в категории можно тизер увидеть, там кнопки для добавления в корзину.

Edited by Юра Мамонтов, 27 April 2015 - 09:20.

[laRus]

с www., то работает, а без www никак не хочет

Можно сделать перенаправление с сайта без www на сайт c www - как возможное временное решение 

[Юра Мамонтов]

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

[isay777]

Вопрос-проблема с переиндексацией базы после импорта. 

 

Примерна такая ситуация. В каталоге 7000 товаров к примеру. Я примерно от 1 до 7-10 раз на дню планирую импортировать товары. Импортировать по разному и новые штук 10-20 и цены поменять. И еще разное. 

Но вот обновление базы после импорта занимает минут 35-45... И как быть? После каждого мелкого импорта делать переиндексацию? 

 

PS За рабочий день я могу сделать максимум 8 импортов грубо говоря... 

Edited by isay777, 27 April 2015 - 09:58.

[Станислав]

Вопрос-проблема с переиндексацией базы после импорта. 

 

Примерна такая ситуация. В каталоге 7000 товаров к примеру. Я примерно от 1 до 7-10 раз на дню планирую импортировать товары. Импортировать по разному и новые штук 10-20 и цены поменять. И еще разное. 

Но вот обновление базы после импорта занимает минут 35-45... И как быть? После каждого мелкого импорта делать переиндексацию? 

 

PS За рабочий день я могу сделать максимум 8 импортов грубо говоря... 

 

Сталкивался с подобной проблемой вот на этом.

 

Один товарищ также горел желанием обновлять цены и поступления на этой базе несколько раз в день.Только импорт проходил не 35-45 минут, а почти 6 часов (~40к товаров). Увеличение доступной памяти под PHP / MySQL ощутимого на глаз эффекта прироста скорости не давало вообще, поэтому появилась идея продублировать алгоритм индексации через серверное приложение на C++ c прямым доступом в базу, которая по идее должна работать ощутимо быстрее. Сами понимаете, что это приличный кусок работы, поэтому после озучивания ценника, клиенту стала больше нравиться идея запускать импорт и индексацию в 22-00 раз в день

Как обойти грабли быстродействия системы, которая использует объектную модель на интерпретируемом языке, коим является PHP, по другому - очень большой вопрос. И стоит он не столько в плоскости оптимизации кода, сколько в специфике инструментария как такового. Мой основной инструмент в повседневной работе C#, MS SQL и XPO (разновидность ORM). Специфика работы ORM примерно такая же, как и работа с табличными данными MySQL через объектную модель ZOO (удобнее, но медленнее) и периодически возникают ситуации, когда объектная модель, которая является дополнительным слоем между бизнес-логикой и данными, является бутылочным горлышком при сотнях или тысячах транзакций в секунду. Тогда приходится откладывать в сторону C# и  XPO, и запрягать С++ и ODBC скорость разработки на которых ниже, зато вот скорость работы приближается к маскимально возможной. Вот и получается, что приходится использовать 2 подхода в одном продукте: там где быстродействия хватает с запасом - используются штатные средства, а там где надо просто адская производительность - используется другой "скорострельный" инструментарий. Кстати, примерно такая же беда в 1С, который также построен на объектах, и где от оптимизации кода скорость может вырасти в разы. Только там еще проблема прямого доступа к данным весьма затруднительна в плане документированности модели данных и запретов самой 1С на "общение" с базой данных напрямую

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

Edited by Станислав, 27 April 2015 - 14:43.

[SmetDenis]

На самом деле мы еще не оптимизировали процесс индексации.

Она сейчас медленнее чем была примерно в 20-30 раз. В основном из-за дополнительных обходов.

1. Материалы

2. Элементы

3. Множественность (раньше циклы заканчивались тут)

4. Цены

5. Варианты

6. Элементы цены по отдельности.

 

Сама база как раз не тормозит. Т.к за 1 шаг происходит один большой insert для SKU и штук 10 для остальных.

 

Из-за вложенности степень алгоритма увеличилась ( (O) в 6 или 7 степени, а было 3-4)

После оптимизации станет легче.

 

Например, первый вариант этой страницы грузился 30-40 сек  - http://beta.jbzoo.com/hundred Караул, да?)

 

После оптимизации вполне нормально, с кэшем даже быстрее чем старый JBPrice Advance.

[isay777]

Станислав спасибо. Надо будет подумать. 

 

Тут дело просто в том, что у меня импорт не один раз в день. А именно в рабочие часы прислал поставщик прайс к примеру, или вот прям сейчас позвонил ген дир и просит прям сейчас поменять цены на 20-30 продуктов. Ранее до jbzoo как раз был двиг написанный на C, но к можалению приходится от него уходить. 

Так вот вопрос мой именно в мелких импортах по 10-50-100-500 товаров... Пока до оптимизации, как написал Денис, я так понял нужно просто обновлять базу для фильтра 1 раз в сутки например.  

[Станислав]

Станислав спасибо. Надо будет подумать. 

 

Тут дело просто в том, что у меня импорт не один раз в день. А именно в рабочие часы прислал поставщик прайс к примеру, или вот прям сейчас позвонил ген дир и просит прям сейчас поменять цены на 20-30 продуктов. Ранее до jbzoo как раз был двиг написанный на C, но к можалению приходится от него уходить. 

Так вот вопрос мой именно в мелких импортах по 10-50-100-500 товаров... Пока до оптимизации, как написал Денис, я так понял нужно просто обновлять базу для фильтра 1 раз в сутки например.  

 

У вас будут только 2 нюанса:

1. Новый товар не попал в параметризованную выдачу до индексации. Критично? Да ни разу. Просто задаем себе вопрос "А если бы поставщик добавил новый товар завтра?". Может ли это быть очень критично? Теоретически, да. Если заказчик торгует айфонами и новая модель в первый день официальных продаж не проиндексирована после добавления в прайс. Только обычно в таких случаях на сайте уже висит баннер на полстраницы с прямой ссылкой на товар

2. Имеющийся товар до индексации не будет попадать в фильтр по диапазону цен. Возьмем обычный юзкейс: "выбрать недорогой планшет за 60-80 у.е. для убийства  времени в транспорте или ребенку по улице бегать, чтобы было не очень жалко если разобьется, потеряется, будет украден". Многие ли поставят в поиске диапазон цен 60-80 или 0-80? 99,9% поставят с запасом минимум 20-30%. Если скачок цен не будет аномальным (как например в Украине, при аномальном скачке курса доллара с 17,5 до почти 40 в феврале), то тут тоже особо ничего не грозит, так как в большинстве случаев параметры поиска, выставленные с запасом, буду охватывать новую цену.

 

Для Дениса.

 

Оптимизация может существенно ускорить индексацию по сравнению с нынешней. Но как бы вы оценили теоретическую возможность сокращения импорта и индексации до максимум 15-20 минут на каталоге из 50тыс. наименований, в которых все товары имеет примерно 20 параметров? Я подозреваю, что для ответа на такой запрос подойдет фраза из "Операции Ы" "Вы ставите нереальные планы!" А если найдется клиент (который всегда прав), который захочет добиться таких показателей? Сразу будем опускать лапки и с виноватым видом бурчать про "Архитектура такая и не заточено под такие объемы?".

 

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

 

1) при манипуляциях в #_zoo_jbzoo_index не нужно будет дополнительно искать ID элементов параметров по их имени - можно сразу оперировать ID. Критично это или нет для такого случая? Причем, у меня пока что добавлены только 3 типа и у меня уже 94 параметра, окончательно ожидается 1000+ параметров.

 

2) при манипуляциях в #_zoo_jbzoo_index_<тип> не нужно будет искать соответствующее поле (включающее ID и тип данных - string, numeric, date) для параметра по имени. Скриншот структуры таблиц индексов для типа. Обратите внимание на количество полей и это еще не предел.

 

3) дополнительно не надо проверять - появились ли новые параметры в товарах или нет.

 

4) некоторые записи индекса #_zoo_jbzoo_index, включащие в себя _itemauthor, _itemcreated,_itemmodified, _itempublish_up, _itempublish_down можно обновлять одним запросом в таблицу или вообще не обновлять.

 

Скажите, если я не прав, недооцениваю возможности оптимизации или неправильно понимаю принципы работы импорта и индексации, или описанные мною проблемы надуманные

Edited by Станислав, 28 April 2015 - 00:38.