How to become an author
Search
Write a publication
Pull to refresh

Comments 35

Time per request: 44.224 [ms]

ab выдает не самые честные цифры. Рекомендую httperf + директиву $upstream_response_time для лога nginx-а. На основании такого теста можно получить более реальную картину влияния нагрузки на движок и сервер.
Total votes 1: ↑1 and ↓0+1
Спасибо большое за подсказку! Обязательно попробую.
Total votes 4: ↑2 and ↓20
Рекомендую такой формат лога:
    log_format main     '$remote_addr:$remote_port - $remote_user [$time_local] $host "$request" '
                        '$status $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" "$http_x_forwarded_for" $request_time-$upstream_response_time';
Total votes 1: ↑1 and ↓0+1
Для каталога товаров актуален такой функционал как поиск. Сколько времени занимает поиск в духе "найти все товары которые произвел Х, стоимость которых не больше Y, а параметр Z равен W" («найти смартофоны Samsung по цене не более 20 круб и диагональю 4'' „)?
Total votes 2: ↑2 and ↓0+2
Хороший вопрос. Большинство большое количество разработчиков думают об оптимизации кода, забывая про оптимизацию базы данных. Я как раз стараюсь разработать такую платформу, которая позволит работать с базой данных максимально быстро. В частности есть возможность переопределить классы и вынести данные в отдельные таблицы без проблем для функционала. Большинство классов — это расширение modResource. Записи содержатся в таблице site_content с другими документами. Связанные расширяющие данные — это modTemplateVar. Но value в modTemplateVar — текстовое поле, со своими вытекающими. Потому для тех же ShopmodxResourceProduct есть связанный класс ShopmodxProduct с своими данными в отдельной таблице и ключем resource_id=id. Описание объекта здесь. А вот в этой таблице уже есть специфические поля, такие как sm_price. В каждом отдельном магазине уже будет докручиваться индивидуальная структура и логика, исходя из бизнес-логики.
Запросы будут довольно сложные, но если правильно все оптимизировать, то проблем не будет.
Вот пример: простая выборка
SELECT c.id, c.pagetitle FROM `modx_site_content` as c
left join modx_shopmodx_products  as p on p.resource_id = p.id
WHERE sm_price 
limit 10
Занимает 0,3 сек. Но это потому что таблицы не связанные. Перевел эти таблицы на innoDB и настроил внешний ключ. Этот же запрос 0,016 сек. Повторный — 0.000 (мускул тоже кеширует результаты).
Вот уже более сложный запрос
SELECT c.id, c.pagetitle, sm_price FROM `modx_site_content` as c
inner join modx_shopmodx_products  as p on p.resource_id = c.id
WHERE sm_price between 500 and 1000
order by  sm_price desc
limit 10

Выполнение 0,000
Total votes 5: ↑2 and ↓3-1
Приведенные sql слишком простые. Выборка по цене это только один критерий запроса. Я же говорю о 2-6 параметров (как показывает мой опыт именно только используют в фильтре при поиске конкретного товара). Сколько для этого варианта получиться? Хотя бы по 4 критериям: 2 являются диапазонами значений (к примеру, цена и диагональ), а 2 — конкретные значения (к примеру, марка производителя и наличие 3G). Кстати, при этом сколько товаров находится в магазине (13 000)?

В каждом отдельном магазине уже будет докручиваться индивидуальная структура и логика, исходя из бизнес-логики.

Правильно ли я понимаю, что если завтра у меня появляется новый товар с новым набором характеристик, то как минимум придется изменить/добавить структуру таблиц (изменить код?)?
Total votes 1: ↑1 and ↓0+1
Приведенные sql слишком простые. Выборка по цене это только один критерий запроса.
Вы еще смотрите, что там сортировка. Одна сортировка может пяти условий стоить.
Давайте я не буду сейчас приводить кучу запросов, а просто скажу, что целый год поддерживал весь биллинг в сотовой компании на Оракле, и вы мне поверите на слово, что проблем с запросами не будет.
Правильно ли я понимаю, что если завтра у меня появляется новый товар с новым набором характеристик, то как минимум придется изменить/добавить структуру таблиц (изменить код?)?
Нет. В большинстве случаев ничего не придется делать. Для этого есть TV-параметры. Но если будет специфическая задача, то многое действий не потребуется — расширили класс, создали для него расширенную таблицу. перенесли все записи туда, а в описании класса указали имя другой таблицы.
Нельзя сделать полностью универсальный магазин. Это — платформа. И она изначально подразумевает, что какие-то манипуляции с объектами потребуются. Так же как мы берем чистый MODX и пишем для него сниппеты, плагины и т.п. Но вам не понадобится лезть в код shopModx.
Total votes 9: ↑1 and ↓8-7
Давайте я не буду сейчас приводить кучу запросов,

А я не это прошу. Я хочу узнать, сколько времени будет отрабатывать запрос при >=13 ктоварах и 4 критериях поиска.

действий не потребуется — расширили класс, создали для него расширенную таблицу.

Т.е. привлечение разработчика под эту задачу обязательно.
Total votes 3: ↑3 and ↓0+3
Я хочу узнать, сколько времени будет отрабатывать запрос при >=13 ктоварах и 4 критериях поиска.
Так же в пределах 0.03 сек, ито пессимистичный прогноз. Сложности с выборкой — это таблиц 10, и как минимум в трех из них несколько сотен тысяч записей.
Т.е. привлечение разработчика под эту задачу обязательно.
Со временем я буду добавлять готовые решение, да может и сообщество подсобит, но пока пишется именно платформа, а она да, потребует для реализации конкретных магазинов программиста. Но это чисто для крупных магазинов. Для небольших (до 1000 товаров) можно обойтись штатными средствами modResource + modTemplate + modTemplateVar + getResource и прочие штатные компоненты. Там 100% MODX-технологии без всяких.
Total votes 5: ↑1 and ↓4-3
да может и сообщество подсобит

Уж не то ли сообщество из которого вашими стараниями ушли практически все толковые разработчики и в котором вы единственный автор статей за последние пару месяцев вам подсобит?
Total votes 5: ↑4 and ↓1+3
Вот в этом весь Николай. Тыкать, переходить на личности и не воспринимать критику со стороны. Никто не собирается троллить ваш топик. И да — я задавал много вопросов и продолжаю задавать вопросы, потому что не считаю себя умнее всех как некоторые, а пока продолжаю учиться. А вот подобный выпады с вашей стороны — обычная низость, не более того.
Total votes 5: ↑5 and ↓0+5
А подобный ВАШ заход сюда — это очередная попытка перевести акцент с полезной информации на уже избитую 4-ехмесячную тему. Забудь уже про меня. Есть что сказать по существу — милости прошу, отвечу на лубой технический вопрос по сабжу. А беспонтовый троллинг — не конструктив.
Уже даже Дмитрий говорит, что нужны технологии, а не повздорившие программисты. Меня не слушаешь, так его хоть послушай.
Total votes 5: ↑0 and ↓5-5
Да не о чем с вами говорить. Если вы следите за жизнью нового сообщества, то там по поводу вашего клипа я вопрос задавал уже, можете зайти и ответить. А разводить тут холивар нет ни желания ни настроения, скоро все изменится и вы прекрасно это знаете. Пока вы делаете ваши «решения для разработчиков (с)» заканчивается работа над решением для всех, в котором все вышеописанное уже реализовано и прекрасно работает с >20к ресурсов. Обратитесь к Диме, он вам даст реальные ссылки.
Total votes 3: ↑2 and ↓1+1
Я к вам на ваш сайт не лезу, у вас там своя жизнь и наверняка я буду там лишним. Потому отвечать там ничего не буду.
А вот про >20к ресурсов хотелось бы статью видеть. Я видел, что Дмитрий с бумкака (вроде) делали магазин. Но это на Эво. Речь не о том, что лучше, а что хуже, но мне надо на Рево.
То, что сейчас реализовано в modxShop — это еще совсем малая часть от планируемого. А то, что в нем сейчас мало файлов и мало кода — это совсем не показатель малой работы. Наоборот. Посмотрите на гитхабе изменения с версии 0.0.1 до текущей, и увидите, что количество файлов и кода только сокращается. И это не регресс, а прогресс, так как применяются самые глубокие познания MODX-а. Покажите другой такой компонент для Ревы.
Total votes 4: ↑1 and ↓3-2
Подоплека вопроса выше была такая: "Какие индексы используются в вашей базе? Т.к. используя TV парметры для хранения значений дополнительных характеристик невозможно сделать быстрые фильтры по базе из 13к товаров." Собственно это и попытался уточнить alekciy
Правильно ли я понимаю, что если завтра у меня появляется новый товар с новым набором характеристик, то как минимум придется изменить/добавить структуру таблиц


Помимо этого был добавлен верный вопрос
Кстати, при этом сколько товаров находится в магазине (13 000)?

Запросы приведеные выше тестировались на базе какого объема?
Total votes 2: ↑2 and ↓0+2
Верно. Я когда-то вел разработки на MODx-а и даже делал модификацию ядра. В том числе работал в TV параметрами. И считаю структуру бд не оптимальной для создания больших каталогов с произвольным набором параметров. Даже для 13 ктоваров.

P.S. Собственно было интересно сравнить с собственным решением. У меня 800 ктоваров (значений атрибутов 8 миллионов) при этом у товара может быть произвольное количество атрибутов, товары так же произвольны. Структура таблиц остается неизменной (что-то близкое к EAV но не оно). Так вот, запросы по 4 параметрам: 2 диапазона и 2 статических значения занимают порядка 0.0002 сек (0.2 мс). И лишь запросы по 10 параметрам начинают «тормозить» требуя 0.3-0.5 мс. Это на уровне СУБД. Сам же движок такие поисковые запросы отрабатывает за 10-150 мс в зависимости от степени попадания в кэш.
This comment wasn’t rated yet0
И считаю структуру бд не оптимальной для создания больших каталогов с произвольным набором параметров

Все верно. Для быстрого создания прототипа сайта MODX идельно подходит. И интерейс админки очень быстро кастомизируется. Но то, как с этими данными приходится работать из фронта — волосы дыбом встают. Поэтому до сих пор еще каждый пишет свои велосипеды и как-то пытается улучшать код. В свое вермя для Evolution версии был плгин который создавал отдельную таблицу для хранения TV праметров. И при добавлении нового TV парметрка в базу отправляется запрос ALTER TABLE в эту таблицу. Но опять таки, даже сейчас еще нет средств позволяющих красиво фильтровать данные по этой таблице.

Таким образом, TV параметры могут помочь программисту быстро накидать интерфейс для редактирования данных. А все данные зерклировать куда-то в другое место. Собственно я подробно эту схему в статье про плагин TagSaver описал.
Total votes 2: ↑1 and ↓10
Так и я не говорю, что база MODX-а идеальная. Потому и делается упор на то, что для индивидуального магазина нужно создавать индивидуальные таблицы и свои индексы настраивать, без этого никак.
Но: в том же битриксе, который в России сами знаете какое положение на рынке eCommerce занимает, по сути такая же система TV-параметров применяется. Это говорит о том, что такая структура TV-шек — максимально гибкая для быстрой настройки через админку. Но наверняка на крупных магазинах так же создаются свои таблицы.
Total votes 1: ↑0 and ↓1-1
У меня 800 ктоваров (значений атрибутов 8 миллионов)

Есть ссылка на ваш проект?
Total votes 3: ↑1 and ↓2-1
Можно, но не в текущий момент. Релиз в паблик с возможность использования будет в течении этого года.
This comment wasn’t rated yet0
ОК. Надеюсь как-нибудь узнаю об этом
This comment wasn’t rated yet0
Подоплека вопроса выше была такая: «Какие индексы используются в вашей базе? Т.к. используя TV парметры для хранения значений дополнительных характеристик невозможно сделать быстрые фильтры по базе из 13к товаров.»
Это еще почему? Чем таблица TV отличается от других таблиц? Ее отличие и ограничение только в том, что колонка value — текстовое поле (о этом говорил выше), и элементарная выборка с сортировкой цен, к примеру, даст глупый результат, и для корректности придется тип данных налету конвертировать, что однозначно скажется на производительности.
Проблемы из-за предполагаемого большого кол-ва JOIN-ов? Так делайте один JOIN, а варианты TV-шек загоняйте в условие IN(), и будет практически тоже самое. А таблица контента и TV-шек так же надо связать вторичными ключами, без этого никак.

И напомню: объекты расширяемые. Специально для своего магазина можете создать отдельную таблицу со специфическими колонками и фигачить данные туда.
Total votes 3: ↑1 and ↓2-1
Запросы приведеные выше тестировались на базе какого объема?
Заявленного. 13000 товаров + 43000 TV-шек. Или вас в мегабайтах интересует?
Total votes 1: ↑0 and ↓1-1
Или вас в мегабайтах интересует?

Если хотите конструктива, то можете еще и в байтах написать. А вообще, не нужно ерничать. Есть конкретный вопрос:
Запросы приведеные выше тестировались на базе какого объема?

И конкретный ответ:
13000 товаров + 43000 TV-шек

Дальнейшие выводы каждый сделает сам для себя.
This comment wasn’t rated yet0
А вообще, не нужно ерничать
Я ни в коем случае не ерничаю, а просто уточняю, так как объем и количество — разные вещи. Тем более я про количество строк говорил не раз, вот и подумал, что интересует именно объем базы.
Пока что база не большая — 24Мб.
Total votes 2: ↑1 and ↓10
По моему, проблема базы сильно преувеличена. Я тоже раньше переживал, что при 7 килотоваров с кучей ТВ и посещаемостью 10килоюзеров/сутки все будет тормозить. Да, оно подтормаживало, но после переезда на VPS ничего не тормозило, а уж при переезде на выделенный сервак (за 50 евро у хетцнера) вообще все летает. Замечу, речь идет о ево, но у него тоже постоянно все любят говорить про «оптимизацию» базы.
А выделять товары в отдельную таблицу стоит лишь из-за того, что в основном дереве их не удобно редактировать.
This comment wasn’t rated yet0
А выделять товары в отдельную таблицу стоит лишь из-за того, что в основном дереве их не удобно редактировать.
Ставьте для своих товаров show_in_tree=0, устанавливайте groupEdit, и заявленная проблема перестанет быть проблемой (само собой речь о Рево).
По моему, проблема базы сильно преувеличена.
А по-моему вообще не преувеличена. Если одна выборка выполняется даже 0,3 сек., то вся страница никак не сможет быть отдана менее чем за это 0,3 сек. Оптимизировав базу можно сократить нагрузку в десятки раз. У меня один закрытый проект есть (система пропусков), там поиск выполняется после каждой добавленной буквы в поисковую строку. Записей очень много и запросы сложные, из нескольких таблиц. Так вот когда с ростом базы нагрузка возрастала, просто оптимизация базы (без изменения запросов), позволяла сократить время выполнения запроса с нескольких секунд до нескольких тысячных секунды.
Total votes 2: ↑0 and ↓2-2
Тут опять же надо уточнять о каком железе идет речь.

А большинство «оптимизаций» ведут к тому, что при очередном обновлении системы надо будет заново все «оптимизировать» (к базе это конечно в меньшей степени относится), что добавит проблем и повышает вероятность добавления багов.

ПС. Самая правильная оптимизация — убеждать разработчиков modx в тех или иных «оптимизациях».
This comment wasn’t rated yet0
А большинство «оптимизаций» ведут к тому, что при очередном обновлении системы надо будет заново все «оптимизировать»
Сорри, с чего это вдруг оптимизация в виде правильной настройки ключей у связанных таблиц должна как-то пострадать при очередном обновлении системы?
ПС. Самая правильная оптимизация — убеждать разработчиков modx в тех или иных «оптимизациях».
Нельзя под все оптимизироваться. Вот судя по вашему нику — вы админ. У вас есть на вооружении Ось, которую поставил, и только пиво попиваешь?
Total votes 3: ↑0 and ↓3-3
Ну пострадать может легко, изменили формат таблицы и все. И не понятно, почему «правильная настройка ключей» не может быть сделана разработчиками?
This comment wasn’t rated yet0
При обновлении ПО формат таблиц не меняется.
Сорри, вообще не хочется обсуждать такие абстрактные темы. На всякий случай перефразируюсь: у меня формат таблиц просто так не меняется.
This comment wasn’t rated yet0
Простите за оффтопик, но почему Ваши комментарии практически всегда заминусованы во множестве тем?
This comment wasn’t rated yet0
Потому что у меня есть много недоброжелателей, которые не технически оценивают, а по стадному эффекту :-)
Им сказали меня не уважать и минусовать, что они и делают. Хотя и 10-ти процентов не понимают из того, что я пишу)))
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr