Yoda

Ну вот видите, не такой я злой и страшный, а иногда даже могу что дельное подсказать. И даже вы оказались на моей темной стороне. :ugeek: Дальше если развивать тему. Почему файловый кеш для атомарных контейнеров медленне, чем запросы в грамотно настроенную базу. 1. Mysql - это хранилище с поддержкой быстрой выборки по ключам. Уже на 3-4-5к файлов в папке будут тормоза с поиском файла, и механизм индексирования к файловой системе не особо применим. 2. Правильно сконфигурированный сервер базы, позволяет держать все таблицы в памяти, обеспечивая все таки более быстрый доступ к данным, чем даже обращение к файлу на SSD диске. 3. Очередь обращения к данным в памяти практически не влияет на скорость доступа, а вот очередь обращения к файлам опять же на том же ssd, никуда не денешь. Если говорить о реализации тяжелого проекта, в котором надо реализовать подобную задачу, и говорить о жестокой реализации. То нужно денормализовать структуру. Создать отдельный справочник (category_id, data_subcategory) обновляемый при любых изменениях в категориях. И использовать его, вместо постоянных запросов с JOIN. Равно как и для getTotalProduct, можно сделать RT-индекс и подвесить все в тот же сфинкс. Вы забыли три страшных слова - шардинг, партицирование и репликация. Но боюсь, что ответ все равно будет из серии "а в моей песочнице, все равно ведерко синее".

Правил тут недавно магазин, в котором стоял модуль оплаты сбером. В модуле есть инструкция по оплате, которая приходит клиенту с отчетом о продаже. Вобщем суть какая. Инстркция эта заполнена в модуле HTML полем. В метод addOrderHistory эти данные приходят как plain-text в переменной $comment, и соответсвенно идут в письмо как листинг HTML,а не как HTML-сущности. Правится легко. В модель order После public function addOrderHistory($order_id, $order_status_id, $comment = '', $notify = false, $override = false) { Добавляем $comment = html_entity_decode($comment); И получаем красивый HTML в письме. Вот собственно вопрос. Может Даниэлю пулл-реквест запулить, или нафиг не надо ?

Параметры базы, параметры сервера, структура таблиц, индексы на таблицах, количество файлов в папке с кешем, очередь чтения c диска в боевом режиме, внутренний механизм кеширования mysql - не, не слышал? Если на reg.ru на шареде за две копейки - разница будет раз в 100 отличаться. Только разница между вашими теоретическими выкладками и моими тезисами в том, что вы знаете слово teamlead и живете в синтетических тестах, а я сутки на пролет занимаюсь построением больших систем и оптимизацией средних. Поэтому все о чем вы сейчас пытаетесь с пеной у рта рассказать, пройдено в третьем классе так сказать. Я долго не мог понять, кто эти специалисты, после которых люди приходят ко мне со словами "пятеро уже работали, а тормозит как тормозило". И еще конкретно этот пример оптимизируется совершенно иным методом. Если речь идет о методе из 2.x, если внимательно посмотреть в запрос в нем идет выборка SELECT * из нескольких таблиц c последующей сортировкой по lcase(name). Если включить немного мозг и изучить матчасть по mysql. То логичным будет делать выборку SELECT category_id с составным индексом по полям status и parent_id. В этом случае скорость работы запроса увеличвается в несколько сот раз на больших магазинах. И после этого к результирующему набору дособрать необходимые данные (name, title, descr etc...) и уже средствами php по минимальному набору данных осуществить сортировку по названию. Ни один кеш стандартного метода и рядом стоять не будет, я уже молчу про глобальное снижение нагрузки на всю систему.

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

Я работал. И однозначно могу сказать что вы пишите бред! Mysql - резиновый и упирается только в ресурсы сервера. Большое количество товаров - это большое количество постоянных изменений данных, поэтому кеш здесь не то что не панацея - а совсем не вариант. А бывает что не только базы выносят на сервер, а под сегменты таблиц ставят отдельную редиску, которая обслуживает к прмеру клиентов, у которых имя начинается на A, а потом еще одну, у которых на B и так 33 штуки до Z. 630 000 - это не мало и не много. MySql кушает и не кашляет. Но вот некоторые реализации требуют напильника. Умные матюки про teamlead - оставьте молоденьким девчонкам. 100 файлов кеша на getCategory это в 100 раз хуже, чем один кеш на все дерево. И в 10 000 раз хуже, чем один запрос на все дерево и формирование дерева через узлы массива. Вобщем крайне рекомендую, прежде чем писать такие комментарии всерьех подумать, есть ли у вас для них квалификация.

30 Скачать / Купить дополнение СуперТаб http://ocshop.info/supertab.png Добавил Yoda Добавлено 14.11.2016 Категория Прочее Системные требования Метод активации Без активации Ioncube Loader Нет ocStore 1.5.5.1.2 OpenCart.Pro, ocShop OcShop 1.5.6.4.х Обращение к серверу разработчика Нет  

Если у вас много сайтов и оно лезет и лезет, найдите кто поставить вам Suhosin и отключит eval() в php. Так как 99% зловредов используют примитивную обфускацию, которая без eval ну никак не обходится, сразу вы закрываете львиную долю дыр. Это первый шаг. Второй - это вот, самое то для WP.

Это называется "Закон парных случаев". Погуглите - кому интересно.

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

1 - нет 2 - нет информации.

Про MyIsam - не понял шутки. По факту они быстрее чем InnoDB, а в Opencart и намека нет на использование защищенных транзакций посредством механизма InnoDB. Так что переводить таблицы в эту структуру - это такая же глупость, как и кешировать mysql запросы на уровне php.

На пальцах просто банальный пример. key_buffer_size - сколько в mysql по умолчанию? Даже если у нас будет оооочень много памяти, почему вдруг mysql начнет использовать ее по полной, в обход конфига? Из моей практики 10% администраторов серверов знают о возможности тонкой настройки mysql, а из них половина, просто про это забывают. Так что в реальности получается, сервер купили, а из-за дефолтных настроек, он часто работает хуже чем хороший шаред.

Необходимость в https в нынешней конъюнктуре обусловлена не доверием пользователей а блажью Гугла. С нового года все сайты без http будут помечаться в выдаче как небезопасные. Что касается ситуации, почему у вас не работал абсолютный редирект - это кривые настройки хостинга.

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

Могут и очень легко... Вы часто видели корректно настроеный дедик.

В последнее время, многие авторы шаблонов, начали поголовно практиковать пагубную технику встраивания целых кусков чужого кода в свои шаблоны, без разбора полетов. В связи с этим, по моим данным, около 10-15% популярных шаблонов и содержат в себе потенциальные уязвимости. С теми, у кого у меня есть прямая связь, в частном порядке мы закрываем эти дыры с уведомлением покупателей. Но со многими я просто физически не могу связаться, так как они отказываются идти на контакт. Поэтому давайте сделаем наши магазины безопаснее вместе. Вот очень полезная статья с большим набором заплаток от разного рода попыток взлома сайтов. Она правда для WP, но по сути техники взлома не сильно отличаются. https://perishablepress.com/6g/ Для продвинутых пользователей, там все достаточно ясно-понятно. Для новичков, я бы рекомендовал добавить в .htaccess хотя бы это: <IfModule mod_rewrite.c> RewriteCond %{QUERY_STRING} (eval\() [NC,OR] RewriteCond %{QUERY_STRING} (javascript:)(.*)(;) [NC,OR] RewriteCond %{QUERY_STRING} (base64_encode)(.*)(\() [NC,OR] RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC,OR] RewriteCond %{QUERY_STRING} (<|%3C)(.*)script(.*)(>|%3) [NC,OR] RewriteCond %{QUERY_STRING} (\\|\.\.\.|\.\./|~|`|<|>|\|) [NC,OR] RewriteCond %{QUERY_STRING} (boot\.ini|etc/passwd|self/environ) [NC,OR] RewriteCond %{QUERY_STRING} (\'|\")(.*)(drop|insert|md5|select|union) [NC] RewriteRule .* - [F] </IfModule> Встраивать эту конструкцию необходимо после строки RewriteEngine On После добавления, рекомендую запустить Xenu's И проверить доступность всех ссылок вашего магазина. Если появятся страницы с кодом 404 или 500, проведите анализ и удалите исключения из списка, которые мешают нормальному отображению страниц.

Найдите в таблице oc_product_description все записи с id 7137 Удалите ненужную дублирующую локаль и будет у вас все ок. Видимо в процессе записи в базу произошел какой то сбой в подключении

Скажите, у вас много своих магазинов, много из них с запросами в топе, вы много магазинов вывели в топ? Что позволяет вам разбрасываться такими громкими фразами про секту noindex follow ?

Видимо по аналогии для HTTP_SERVER - ввести адрес сайта с http протоколом а для HTTPS_SERVER - без. Ошибки в seo_pro у вас появляются, в случае если вы вводите значение без префикса, определяющего протокол.

Правку тебе в личку кинул к фиксу...

Добрый день господа. Уже который раз приходится сталкиваться с косяками на ukraine.com.ua В связи с тем что у них очень сложная система конфигурации виртуал-хостов с подключенным mod_pagespeed, очень часто происходят казусы. Поэтому. Если вы столкнулись с проблемами, пишите в саппорт, чтобы они фиксили. Какого рода есть проблемы. 1 - если у вас настроен автоматический редирект с www на без www или наоборот в панели хостинга. Нужно его отключить и редирект делать средствами htaccess. 2 - если у вас включен предварительный резолвинг dns или lazy load, его тоже нужно отключить, так как у вас может быть подхвачен некорректный алиас домена. 3 - если у вас выделенный айпи для домена, возможны проблемы с отдачей параметра http_host, изза которого может не срабатывать редирект на уникальное зеркало. 4 - если вы даже использовали https фикс и в исходном коде у вас все ссылки https, возможны ситуации изза кривог конфига nginx на стороне хостера, в следствии чего некоторые изображения отдаются с некорректным заголовком как plain/text и для них происходит 301 редирект на http. 5 - в index.php замените строку if (isset($_SERVER['HTTPS']) && (($_SERVER['HTTPS'] == 'on') || ($_SERVER['HTTPS'] == '1'))) { на if ((isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == '1' || $_SERVER['HTTPS'])) || (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && (strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https') || (!empty($_SERVER['HTTP_X_FORWARDED_SSL']) && $_SERVER['HTTP_X_FORWARDED_SSL'] == 'on'))) { Прежде чем плодить похожие темы с проблемами после переезда на HTTPS на Ukraine, мучайте их саппорт.

Вы читали выше мой комментарий. Если вам надо переехать красиво, оставьте на время оба протокола. Если вам надо только https, пропишите в конфиге и в значение http_host - https:// А потом тираньте хостера, что вам делать с абсолютным редиректом.

По признакам, очень похоже на Ukraine.com.ua + выделенный ip + кеширующий модуль. Начните с вот этого. После этого проверьте еще раз конфиги. Проверьте чтобы в разделе сервер было включено SSL. Учтите, что для корректного переезда, для Яндекс, какое то время, пока будет идти процесс склейки, ваш сайт должен быть доступен одновременно по обеим протоколам. Сразу делать абсолютный редирект не рекомендуется. Если после проверки, у вас ничего не получилось, мучайте поддержку хостинга, пусть они проверяют в чем проблема, и почему у вас отдается некорректно параметр {HTTP_HOST}.

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