Перейти к содержанию

Yoda

Пользователи
  • Публикаций

    1 419
  • Зарегистрирован

  • Посещение

Репутация

664 Очень хороший

Информация о Yoda

  • Звание
    Pro
  • День рождения 31 января

Контакты

  • Сайт
    http://ocshop.info/
  • Skype
    ocshop.support

Информация

  • Пол
    Не определился
  • Интересы
    Тюнинг и оптимизация больших магазинов.
    Долго дорого ... ну дальше вы сами знаете...

Посетители профиля

15 525 просмотров профиля
  1. Постучался несколько дней назад один уважаемый форумчанин, с просьбой посмотреть на его подопечного, которого взломали и удалили целиком весь магазин. Устали они восстанавливать все из бекапа. При этом человек, который обратился, достаточно грамотный, для того чтобы закрыть все известные публичные уязвимости, и настроить безопасность окружения. Все равно сносят магазин подчистую. Начали смотреть и обнаружили в корне вот такой интересный, и казалось бы безобидный код: <?php if (isset($_GET['name']) || isset($_POST['name'])) { header('Content-Type: image/jpeg'); header('Content-Disposition: attachment; filename="'.htmlspecialchars($_GET['name']).'"'); header('Cache-Control: no-cache'); header('Content-Transfer-Encoding: chunked'); readfile($_GET['name']); } else { echo 'Access Denied!'; } ?> Причем этот код - это часть функционала сайта, который в карточке товара с подстановкой урла изображения товара, позволял его скачать по клику на ссылку. как то типа... https://site.com/?name=https://site.com/image/some_pic.jpg Ничего казалось бы страшного, если не присмотреться ближе. Вместо some_pic.jpg достаточно было вставить ./config.php и привет пароли к базе. Реально и смех и грех. Этот код был написан лет наверное шесть назад, когда мой товарищ только-только начал заниматься сайтостроением и у него не было ни единой мысли, о том что такое уязвимости или "а что так можно было?"... Но времена меняются, хакеры не спят, и реально я наблюдаю в последнее время просто эпидемию заражений и взломов. Будьте аккуратны при написании подобных скриптов, фильтруйте данные! Всегда фильтруйте данные!
  2. Так. Все равно непонятно. Какое отношение пейсатель сайтов имеет к продажнику, и зачем ему стресс тест по программированию, если он должен продавать?
  3. Я наверное ничего не понимаю. Но предположим, взяли вы на работу @chukcha, а он возьми и окажись и программистом не с помойки и продажником неплохим, но продажником лучше чем программистом, вы я так понимаю собираетесь делать сайты. А сайты у вас делает @n3bo, который волочет но не очень. Вот взял продажник, напродавал так напродавал. А реализовать вы не можете... Я все к чему, зачем вам продажник со скиллом, если у вас нет прогаммиста судя по всему, который не может сформулировать требования к знаниям сейла?
  4. Вы меня извините. Но дружища, у вас в подьезде... В таком тоне - говорите с ними. А если вы не понимаете, что у вас не быстрый магазин, а мифическое решение, которое можно реализовать бесплатно с помощью вот этого модуля: https://github.com/budgetneon/v2pagecache, то мне откровенно вас жалко. К сожалению вот из-за таких фанатов сказок как вы, которые некомпетентно хвалят бесполезные решения, многие и многие владельцы магазинов гробят свой бизнес. И если вы не профи, к чему эти "советы", это как гемморой огурцом лечить посоветовать. Тоже ведь кому-то помогает. И все таки я просил показать хотя бы 20 000 товаров в категории с фильтром - не увидел. На данный момент у нас есть проект в котором 570 000 товаров в одной категории с фильтром с 20 параметрами, с временем генерации без кеша менее полутора секунд. Как вы считаете, я тоже не профи?
  5. Вооот. А я говорил. Сейчас будет рекламная акция волшебной мази. Как обычно сплошное введение в заблуждение. Попробую на пальцах открыть фокусы фокуснкиков: 2-3-4к товаров в категории - это не нагрузка, так как все запросы в таблицы товаров сегментированы по id категории и представляют из себя небольшой набор. Тем более у @SooR для версии 2.3 отличный фильтр который отлично переваривает за счет использования сводных таблиц подобные задачи. Это же так просто тыкнуть носом пользователя. С текстом - делай разделение. Почему то все упускают из виду, что каждый дополнительный уровень вложенности катастрофически уменьшает конверсию и ухудшает навигацию. Но как я выше писал, даже 20к товаров в категории никто не показывает, на общем количестве товаров хотя бы овер 100 к, при том что в таких сегментах, как плитка, обои, сантхеника, люстры нормальная навигация - мастхев. Что касается ддоса. Что же это за такой супер-быстрый магазин, оптимизированный, который ложится просто от нажатия f5 в браузере. Как он может держать како-то разумное минимальное количество посетителей. И самое потрясающее передергивание - это рассказывать про то что летает на "шареде". Как известно у beget под базы данных как раз на шареде стоят отдельные оооооочень мощные сервера, судя по всему с огромным количеством памяти. Это позволяет показывать одномоментные очень быстрые результаты. Но шаред он и в африке шаред. И балансировщики ресурсов не спят. Поэтому ни на одном шареде невозможно построить стабильную быструю нагруженную систему. Вобщем друзья мои, не все то золото, что блестит.
  6. На самом деле, судя по всему, вас так же как и многих ввели в заблуждение волшебными способностями чудо-модулей. Вы показываете не реальную работу магазина, а скорость отдачи сервером готовых html-страниц. Если у вас дай бог, когда нибудь появится 20-30 посетитилей онлайн, у вас все ляжет, так как скорость генерации страниц без кеша у вас далеко не фонтан. Сколько ресурсов вы тратите на прогрев, и есть ли у вас возможность оперативно актуализировать каталог - это тоже открытый вопрос, о котором вы умалчиваете. И к этому ко всему у вас только на четвертом уровне появляются где-то там, очень узенько сегментированные товары. Вместо того чтобы дать возможность покупателям иметь нормальную навигацию в общих категориях (плитка, ламинат), вы заставляете его делать несколько лишних действий и теряете до половины посетителей. Ну и с такой мелкой сегментацией, ваш магазин ни чем не отличается от магазина на 3000 товаров.
  7. Загляну. 1. От 100к товаров по хорошему нужен дедик. Так как ВПСы не справляются ни с io операциями диска, ни с быстрой обработкой mysql-запросов, которая упирается и в io и в скорость ядер. А тут даже не ВПС а опять же облако с непонятной системой виртуализации, с диким оверселингом с HyperThreadingом и так далее. Вобщем это первая печаль. И не говорите мне, что нет трафика. БОТЫ ВЕЗДЕСУЩИ. 2. 2 гб памяти... Ну ок. Скорее всего там стоит 512мб а то и гиг на поток-php (ведь товары откуда то взялись, их парсили, а парсеры прожорливые до памяти). Даже если 512мб, куда то надо еще деть системные ресурсы. В итоге у нас есть ресурсов на 3 паралельных http-потока для клиентов. А от ботов запросов я думаю больше (см п.1) 3. Ладно, допустим, нет проблем с io, есть ресурс процессора, и есть в достатке память. Скорее всего есть большие категории, овер 10к товаров, в которых getProducts и getProductTotal выполняются 2-3-5 сек каждый. А если еще открыта пагинация для индексирования, то на крайних лимитах, на порядок дольше, так как чем больше лимит с сортировкой, тем больше базе приходится сканить данных из таблицы. И у нас уже даже не 3 потока в секунду может отработать система, а 1. Когда на web-сервер приходит очередь запросов, они в нее стали и выели все реусрсы процессора. А еще у нас же есть всякие update в таблицу product. Продолжать могу бесконечно... Хочется конечно поглумиться, и посоветовать поставить один супер-пупер "авторский" "уникальный" кеширующий модуль, либо же обратиться к специалистам оптимизаторам. В какую нить очень честную студию. Но чет я ни у кого из этих специалистов не видел живого магазина с фильтром, который тащит от 100 к товаров в принципе, не то что в одной категории. Так что если вдруг никто не поможет, стучите, полечим беду.
  8. А что там разбираться то... Посмотрите в htaccess, что происходит здесь? RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA] По моему ясно же, что весь "хвост" запроса уходит в обработчик php с ключом _route_. Т.е. это внешний набор данных, который пришел "из мира" в котором содержится полная информация о запрашиваемых данных, который потом разбирается на части сео-классом: // Decode URL if (isset($this->request->get['_route_'])) { $parts = explode('/', $this->request->get['_route_']); а "route" - это системный указатель, который определяет какой контроллер системы должен обрабатывать ваш запрос. // Router if (isset($request->get['route'])) { $action = new Action($request->get['route']); } else { $action = new Action('common/home'); } В случае использования ЧПУ, у нас в строке запроса нет явно указанных параметров, какой контоллер должен обрабатывать ту или иную ссылку, а есть только что-то вида site.com/product_url. Для того чтобы движок понял, чему этот product_url соответствует ему надо из _route_ разобрать данные, постучаться в базу получить соответствия, типа product_id = 234234, определить по типу сущности, что это товар, выставить соответствующий системный route = product/poduct и отработать при помощи нужного контроллера ваши данные. Ничего военного и тайного в этом нет. Но все таки я поддержу чукчу, если данный механизм непонятен "как есть", а он достаточно логичен и интуитивен, лучше не лезть, потому что можно нахомутать.
  9. Хм, а чего ж вы самого автора не спросите?
  10. Я сделаю тесты. Покажу. Как раз есть набор данных подходящий.
  11. Это плохое решение для нашей ситуации. Во первых у меня уже получилось быстрее ну и сфинкс по сути своего механизма формирует такой же бинарный индекс и реализация внутренней механики очень похожа. Во вторых - самое главное, то, что у меня целиком и полностью весь каталог крутится в индексе сфинкса. Цены, порядок сортировки, бренды, категории, абсолютно вся выборка на страницы каталога идет из того же самого индекса, в котором хранятся и атрибуты. Кроме этого, не нужно мудрить велосипед, и писать сложную логику для преобразования-извлечения данных. Все на sql, единственное стоит сервер 8 версии, там очень пригодилась поддержка JSON. Опять же не нужно было делать какие то прокладки, я прямо из базы новыми операторами mysql забираю готовую json-коллекцию. И в третьих. Я не знаю есть ли возможность в redis распаралелить индексы и делать обработку в несколько потоков. В нашем случае, при использовании сфинкса, можно полноценно использовать из коробки сразу любое количество ядер процессора а также разные части индекса разместить на любом количестве серверов, и в какой-то момент возможно физическое горизонтальное масштабирование станет единственным оставшимся методом оптимизации. Пока что после всех консультаций, если говорить о программных способах дать пинка этому монстру, я вижу два метода. Это хеширование значений атрибутов и отказ от json-коллекций в пользу mva-аттрибутов. Это потребует формированя дополнительных справочников, но сократит размер обрабатываемых данных раз в 50.
  12. Какие коллизии? На наборе уникальных значений атрибутов в 300 штук, Вы ща серьезно? Опять какой то текст, я не совсем понял к чему. Но уточню суть проблемы. В структуре базы Opencart, самое узкое место - это таблица с атрибутами и поле типа text на значениях. Так как mysql плохо приспособлен для поиска-обработки-группировки по текстовым данным, и это все-таки реляционная база, которая по своей природе предполагает первичную типизацию, реализовать в лоб, какой либо вменяемый механизм невозможно. Есть несколько вариантов решения, но они все требуют денормализации таблиц и влекут за собой проблемы с совместимостью остального функционала. И в любом случае это будет костыль. Даже если использовать выборки match against и full-text индексы, мы все равно упремся в ограничении длины минимального слова в четыре символа, а все остальное заигнорится. Самый трезвый способ использовать для обработки больших текстовых массивов инструменты для этого предназначенные Solr, Elastic, Manticore либо Сфинкс. Так как изначально эти платформы разрабатывались для обработки больших текстовых массивов. Эластик и Солр - мне не нравятся, в силу тех или иных причин - это тема для отдельного поста, мантикора - это сфинкс 2.6 от тех кто убежал от Аксенова. А Sphinx 3.1 показывает прирост по скорости по сравнению с 2.6 и даже 3.0.3 процентов на 30. Очень имеет! MD5-хеш содержит 128 бит, а crc 32 - в четыре раза меньше. Для большого набора, который надо отсортировать в нашем случае, те самые 10M решает.
  13. Я немного повангую. Модуль мультивалюта стоит? В каком режиме работает сервер? Apache, или php-fpm ? Судя по симптомам у вас проблема не в заказах.
×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.