Эээ... а нафига интернет-магазину БД :) ?

Нету слава богу, я не М-видео, у меня довольно-таки нишевой товар, все эти

заскоки с маркетингом явно не про этот проект. В силу объективных причин

количество возвращающихся клиентов не слишком велико.

Речь не идет о озоне, утконосе, М-видео и техносиле.

Вы лично часто покупаете два раза в одном интернет-магазине ?

Сколько таких магазинов знаете ? Более 10 ?

Я что-то вот нечасто...

Спасибо, но мне не надо генерить страницу после востребования.

Это тупиковое направление. В результате вы будете её генерить, а индексирующий бот,

или пользователь ждать. И не факет еще, что сгенерите...

Зачем ? Сотни-тысячи страниц обновляются в пределах 1-2 минуты.

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

Требуется это только после того, как требуется пересборка.

Пока вы по 0.25-0.5с за страницу генерите по запросу, и ваши юзеры ждут,

я генерирую в момент простоя и по 0.05 за страницу или порядка того,

и мои пользователи и боты приходят на готовое..

Он может работать. Работать ожидаемым образом.

И то, как он работает проверяемо. Он банально очень тонкий.

Ну а прочее - дополнительные ништяки, типа мгновенного ответа ботам и юзерам,

простой модификации итд итп.

Это если штаны есть, и есть 3000 вариаций цен.

Если всего этого нету, то нету и 100500 страниц.

В моём ТЗ пока что значится поиск по названию товара, за пару часов удалось

привинтить вчерне с хранением в локалсторейдже. Вот думаю надо ли при нажатии

кнопки search если ничего не найдено логировать на сервер.

---------- Добавлено 01.02.2017 в 11:59 ----------

Я честно скажу, про нормальный хостинг не слышал, что, бывает ?

Т.е. я имею опыт хостинга на множестве хостеров из топ10 в россии, и мягко говоря нормальным назвать это все нельзя.

Проблемы кончились, когда лет 5 уехал на амазон.

Но это нифига не дешевое решение, по крайней мере не в стиле "сотка и всё готово" .

Это при какой толщине канала пользователя ?

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

Регэкспы... там какой-то отдельный модуль для их обработки.

Т.е. всё обновилось, а он после обновления не захотел работать, помогло

накатать еще более новую версию. В подробности не вникал, на продакшене

слава богу таких глюков нету. В целом система сильно замученная.

Огорчило то, что отвалилось "без объявления войны".

Да нет, с логикой всё нормально как-раз.

Задача решается максимально дешево.

Если на рынке существенная часть лидеров "сбилась с пути", то

дешевле вместо того, чтобы искать в говне бисер наладить собственное решение.

Причем дешевле во всех смыслах.

Да, вы правильно поняли.

А ктож еще кроме меня решит-то :) ?

Ну не те ведь, кто имеют только 100$ на открытие "нового супербизнеса".

Будет надо сложную фильтрацию - так и сделаю.

При небольшом объеме данных это явно разумнее, чем дергать сервер.

В общем согласен, что ничего интересного уже не будет.

Через годик-другой посмотрим как это всё будет тикать.

Планирую, кстати, покрыть на 100% юнит-тестами всё.

Если будет время и желание.

У Вас ведь уже сделано, да ?

Каждая строчка кода и каждая функция проверяется после каждого изменения.

А вам уже сто раз сказали, что для простенькой витрины у которой нет 90% вещей которые есть у большинства, и есть уверенность что проект простеньким и останется - ваше решение допустимо. Но вы ведь свой самокат как икону пытаетесь пропихнуть как универсальное решение (см. название темы).

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

Да, я делаю витрины как у вас. С урезанным функционалом. Часто делаю. Но они у меня лежат рядом с визитками. Эдакая продвинутая визитка. Магазин же как правило проектируется индивидуально его функционал никак в статику не запихнуть.

Вы постоянно несете эту чушь, и всё никак не расплескаете.

Давайте на этом месте остановимся. Обоснуйте свою мысль.

Откуда у вас берутся такие задержки? Ну не у вас, а у сферического движка.

Приведите пример.

Типичные страницы магазина:

а) Главная. SELECT from 'page' как везде, индекс все дела, в общем веса нет. Менюшки различные - из кеша, но из без кеша это один, ну два селекта, т.е. десяток милисекунд в очень редком случае пересчета. Всякие тосейлы и т.п. - по одному запросу на каждый вид промоушена, кеш, индекс. Всякие недавние отзывы, анонсы новостей/статей, недавнопросмотренноедругими и т.п. - индекс, кеш, но да, обновляются часто, на нагрузке так и по несколько раз в минуту, так что десяток милисекунд дать могут. Каталог категорий/подкатегорий - может до десятка селектов потянуть, но жестоко закешированно. Если без превью товаров из категории, то оно и не меняется месяцами, с превью - ну если гоняемся за ачивками, то можем инвалидировать кеш не по изменению товаров (что более кошерно), а по TTL + удалению/скрытию товара. Да, в примерах товаров не будет более подходящих новых, скажем час не будет или два, но зато нанооптимизм :) Вроде всё. Самая тяжелая страница. В экзотическом случае может даже 500мс рендерится, но в реальной жизни такое не случается, и как правило вся страница в кеше целиком.

б) Метакатегория. Самая тяжелая страница в принципе. Если у нас у категорий верхнего уровня есть превью товаров, то у нас может быть целая пачка запросов. селект на список всех категорий сабкатегории - индекс, кеш, По одному селекту на каждую категорию чтобы получить N товаров для превью из каждой. (сразу вопрос, как это оптимизировать кто-то предложит изящное решение? Лимит отрезает по всем, а значит у кого-то будет 2N у другого ноль, трехэтажные запросы некошер, ради нанооптимизации выползать из активрекорд не хочется, придумал только денормализация с отдельным булевым параметром у товара topInCategory по которому уже можем делать один селект, а обновлять его в модели при апдейтах/инсертах). После этой пачки запросов у нас уже есть все товары, так что даже если у нас атрибуты и т.п. живут в EAV, то where product_id IN (1,2,3,4,5) и индекс - достаточно быстро отработает. В общем если лень нормальную структуру делать, и всё по дефолту в ORM стоит, то без кеша можно и 200мс рендерить. Но это со всей обвеской которую вы вообще выкинуть хотели). В реальности метакатегории меняют контент редко, так что всё будет в кеше.

в) Категория. Банальный селект товаров с индексом и кешем, потом where in(..) по айдишникам для всей обвески, всё индексируемое, кешируемое и т.п. В особо нагруженных и динамичных местах можно превьюхи товаров рендерить при изменениях и брать готовое из кеша (да, можно отдельную таблицу под это дело сделать, но это реально масштаб амазона/маркета). Тяжелые тут только фильтра. Если они по EAV-атрибутам, то полноценно всё не переиндексируешь, составные индексы на все случаи жизни не сделать. Впрочем в простых магазинах атрибуты можно сделать все в одной таблице, несуществующие дать как NULL и работать будет нормально, до 100к товаров с парой сотен категорий будет без проблем. А там уже индексы делаются без проблем, и всё летает. Всякие менюшки, списки фильтров и т.п. собираемые кучей select distinct под категорию - в кеше. Циферки count-ов для сложных поисковых запросов да, тяжеловаты, но - поисковик сюда не зайдет, а пользователь который уже зашел в поиск вполне подождет даже секунду (много) пока ему будут считать. Хотя я бы эти счетчики выкинул. Не особо они помогают ИМХО, а жрут дофига. Поисковая страница если это не SEO-префильтр генерится обычно полсекунды, в особо тяжелом случае секунду. Поскольку она обычно каноникалом на главную категории клеится, то пофиг с точки зрения сео. Префильтры же полюбому пререндерены на половину, и не хуже чистой категории живут.

г) Карточка - основной контент можно пререндерить при редактировании, можно и по месту. Селект на основные поля, селект на описания и т.п. Селект на EAV (и то только в тяжелом случае), селект под всякие комментарии и отзывы, пару селектов под связи типа сопутствующих товаров и "также покупают" и т.п. Индекс. Превью товара или пререндерино или собрано через where in(...). Индекс, всё такое. 100-200мс в плохом случае.

д) поиск по всему сайту. Ну да, тяжеловат. Ищутся по разным страницам и т.п. Но - ну их в баню. Я вот лично деградирую до поиска по одной таблице страниц, в которой лежат и категории и товары и страницы. Полнотекстовый по заголовку и тексту. Тяжеловат, но пофиг. Один тяжелый запрос можно позволить. Паук туда не заходит. Так что пофиг вообще.

е) всякие статические страницы, фидбеки, корзины и т.п. - вообще пофигу, там десятки мс без кеширования.

Реальность такова, что на тяжелом сайте 99% хитов это десятки мс на рендеринг или проверку кеша, и 1% 150-500мс, плюс 0.01% до секунды рендерится. При этом передача трафика занимает больше времени, особенно статики вроде картинок. Рендеринг обычно упирается в плохую верстку где в хеадере слишком много зависимостей которым место в футере.

---------- Добавлено 01.02.2017 в 13:08 ----------

Черт. Не дочитал до этого места и столько написал).

Попробуйте включить логику.

Если вы тысячу страниц рендерите из базы за 60 секунд и тратите на одну страницу 60/1000=60мс, причем с обработкой картинок, то почему другие должны рендерить по 250-500мс причем без картинок? Работа то та же.

Это прям девиз всего топика))))

Естественно. Велосипед имеет право на жизнь. С этим никто не спорит. Спор с тем, что вы свой самокат проталкиваете как ЛУЧШИЙ принцип, хотя автомобили умеют чуть больше чем самокат.

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

Покрытие 0%. Потому что это уже шестая версия АПИ из тех что попали в релиз, и третий десяток из тех что не тегались. Для преАльфы - имею право.)

Стабилизирую АПИ и буду покрывать тестами конечно.

Ну или пару джунов возьму в проект.

Ну да, он лучше своих глюков наляпает :-).

---------- Добавлено 02.02.2017 в 18:58 ----------

Похоже логика так же недоступна для ТС как MySQL, все средства кэширования и т.д. и т.п., что использует подавляющее большинство профессиональных разработчиков. :-)

вот не надо тут про профессиональных разработчиков их единицы и они вообще не занимаются подобным вещами, а тех кого вы считаете профи, на самом деле продвинутые подключатели библиотек, в том числе и все разработчики битриксов/вордпресов/джумл и прочего бреда

anton_kostrov, наделает. Но те кто коробки делал тоже их наделали).

И будут делать. Если бы все боялись наделать глюков, то не было бы не только глюков, но вообще ничего бы не было.

делать они их будут совсем по другой причине - узость мышления и полное непонимание поставленных задач, это в лучшем случае, а в худшем - обычная тупость

есть ещё один вариант - это экономически выгодно :(

Ну там где удалось, там получилось энергию в мирное русло направить, и как следствие от глюков вылечиться. Но в клинических случаях это не работает. :-)

Лет семь назад я тоже был клиническим случаем, и вот прямо на этом серче в точно такой же теме упирался на тему того "зачем людям всякие активФорм и прочие извращения, ведь всё можно сделать простым шаблонизатором на пяток управляющих конструкций". Ну или как-то так. Полгода назад когда вернулся на серч - перечитывал свои старые темы. Умилялся с того какой я был упрямый идиот).