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

Честно - проблемы тех, у кого толстый бэкэнд (не дай бог еще и написан на php и лежит в сети) меня ммм... не очень беспокоят. Они уже давно на пути к банкротству, думаю в этот кризис их смоет окончательно.

Я понимаю, что вы открыли для себя ООП, полиморфизм и MVC. К слову, я уже лет 15 назад пользовался лично сделанными костылями, реализующими те самые MVC, просто без умных книжек, да и не только я. Что бизнес-логика должна быть отделена от представления - это всё придумали черт знает когда. А аналог смарти у меня был самолично написан еще тогда, когда некоторые пользователи получали www-странички заказывая их запакованными по email :).

Так что в целом вы правы, описанное вами - это всё 10-летней давности всё.

Именно поэтому у меня всё отделено :).

Понимаете ? Нет никакого толстого бэкэнда, есть тонкий бэкэнд и тонкое представление его в интернете в виде "интернет-магазина". MVC в чистом виде в общем-то. Просто на более глобальном уровне. При этом интерфейс бэкэнд - магазин очень и очень узкий.

И чтобы там не делали с магазином, бэкэнду на это пофиг, склад не встанет из-за того,

что какой-нибудь дебил в админке добавит пару неиндексируемых полей в базу на 40гб.

И магазин, кстати тоже, не падает чтоб с бэкэндом не сделали.

И, собственно, этот бэкэнд есть как правило в любой компании.

У всех есть склад, бухгалтерия итп. И им абсолютно не нужны никакие ВАШИ фреймворки, потому как они хотят использовать СВОИ, бухгалтерию вам не написать хоть тресни, склад можно конечно, тикет-системы есть неплохие готовые и как правило требуют только доточки, итд итп.

Идея, что вы построите людям всю инфраструктуру для бизнеса хороша (для вас, ибо больше работы - больше бабла). Но только пока речь идет о салоне по продаже авто, где вся инфраструктура... с гулькин нос её. Если задача среднего или не дай бог крупного размера, то шансов на то, что вы справитесь нету. Интеграторы не зря берут в этом случае миллионы евро.

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

Да это и не нужно. Для создания интернет-магазина всё это не нужно.

Для создания магазина - необходимо, но интернет тут непричем абсолютно.

А кто сказал что бухгалтерия и склад должны быть в магазине?)

Ваш код который генерирует для вас странички (по 5 секунд Карл!) это и есть бекэнд. И нет ни у кого такого бекэнда. Это часть магазина, просто вы ее держите на другом сервере. Всё. Если оно является отдельным ПО, то ок, если оно встроено в вашу ERP, то... тоже ок. Но... это все равно часть магазина.

Если вы ее реализовали на 1С или на С++ или на бейсике - оно не перестает быть частью магазина. Но это скучно. Вы повторяетесь и мне лень вам это объяснять по 100500 раз.

Вы лучше расскажите как вам удалось 5 секунд на страницу выдать?

Откуда такой ужас. Не подумайте что это "переход на личности".

Реально интересно что же может генерироваться по 5 секунд.

Ну и если Вы такой опытный что используете MVC уже 15 лет как, да еще и ООП знаете, то можете сказать сколько в вашем типичном контроллере строк всего, и сколько методов. В общепринятых терминах (т.е. контроллер это класс контроллера у которого может быть 1 и более action которые в академическом MVC и являются контроллером).

А это не я. Вы возьмите из топ 10 коробочных движков и увидите сами что и как работает.

Нет, от них можно "отпилить ножовкой" лишнее, но я уже теперь выкинул всё целиком.

Считаете, что не загнетесь от 5 запросов в секунду ?

Сколько ботов надо, чтобы это было похоже на действия пользователей ?

Скажем бот раз в 30с будет что-нибудь выбирать.... 30*4... 120 штук всего ?

И это правда крутое достижение ?

Да с чего бы она будет одинаковая. Не будет. Что-то вы сможете закешировать,

что-то нет. Да и размер кеша не бесконечен.

Однако, если большинство данных у вас не меняется, то непонятно зачем вы забираете

их из базы и кешируете :). Понимаете :) ? Чем лучше вам помогает кеш, тем менее

вам вообще БД нужна. Чем больше она реально нужна, тем меньше пользы от кеша.

Отключать на ходу что-ли будете ?

Да хоть трижды-выделенный сервер. К вам когда-нибудь DDOS приходил ?

Хоть раз ? От школьника с 1000 проксями хотяб. И не такой, который просто льёт флуд.

Вы баните пользователей запрашивающих страницы чаще чем раз в 10 секунд ?

Really ?!?!?!

Или вы на дебилов рассчитываете, которые будут от вас одно и тоже забирать.

К вам никогда не приходил я.бот ? С ним бывает иногда, когда он "бесится" и приходит

сразу штук 50 пауков забирая тысячи страниц в минуту. Очень знаете-ли позволяет

переосмыслить тонкие места...

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

будут насколько хорошо себя чувствовать ? Учитывая, что я долблю ваш "толстый бэкэнд"

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

оказаться без склада потому, что пришел небольшой такой ДДОС. Причем без склада для

оффлайн продаж....

Коробки, особенно бесплатные - кривые. С этим мы определились еще в прошлом году. Да, падают при каждом ДДоС. И что?

0.25с это самые узкие места. Которые кешируются. С инвалидацией не по времени а по более разумным критериям. И по частям. Скажем сайдбар закешировали один раз и всем выдаем его. Топменю закешировали один раз, инвалидируем по легкому условию вроде самой свежей даты изменения страницы у которой стоит галочка "выводить в топменю".

Этот запрос "дешев", но в хайлоаде его тоже можно держать в мемкеше. Что у нас еще? Всякая статика типа меню в футере и прочих текстов? Тоже в кеше. Что еще ? Хлебные крошки? Сео-текст, тайтл, мета-дескрипшн? Хлебные крошки делаются одним простым запросом еще на уровне разбора URL, и кешировать их нет смысла. Мета-данные страницы тоже достается запросом. Запрос списка товаров из категории с соответствующими количествами на страницу, сортировками и т.п.? Ну один легкий запрос. Рендеринг превью самих товаров? Так закешировано. Инвалидируем по изменению связанных данных. Сам товар, его атрибуты и т.п. Если зависимости сложные и их много - редкоменяемые связи могут связанным данным поменять некий параметр последнего изменения кеша, чем инвалидировать всех кто связан.

Итого в реальности выйдет каждая десятая страница доходит до пхп (остальное кешируется еще нгинксом), из них 90% страниц или закешированы более чем на 90%, или ладно уж, генерятся за 50-200мс. У реального проекта может быть несколько узких мест, но сходу приходит в голову ТОЛЬКО сложный поиск. Его да, частенько надо защищать. Но под атакой его можно и деградировать или закрыть капчей. У вас же его в принципе быть не может по определению.

У меня где нужно используется кеш, а где нужно - база. Даже если база используется в 0.1% случаев, то она у меня есть. У вас же есть только кеш. Любое изменение у меня это разовый пересчет страницы когда понадобится, у вас же - жди пока будет пересчет.

fail2ban и другие инструменты работают не хуже рук.

Лет 10 назад было с "1000 проксей". Положили да.

Недавно китайцы парсили в 100 потоков. Там была дюжина AS всего. Ничего не делал. Не успел. Минут за 10 сервак их всех побанил и все вернулось.

Еще было пару раз более интеллектуально, по узким местам и все такое. Но сам не разгребал это было на более-менее толстых проектах где были выделенные админы.

Ну и за клудфларе прятаться приходилось пару раз.

Флуд это задача хостера или магистрала или своего админа если сэкономили на хостинге.

Не всякие страницы а только те которые слабые места.

Вы этим форумом пользоваться пробовали?) Поиск даже для авторизованных - именно так и закрыт, и ничего.

А вы? У вас то как раз "только то что в кеше, остальное - не судьба". Сделайте мне поиск по произвольному атрибуту по 100к товаров без базы. Посмотрю на вас)

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

Но мы ведь не обсуждаем косяки роботс.тхт и экзотические сложные проекты. Crawl-delay никто не отменял. Индексировать служебные страницы и страницы поиска никому не нужно и все такое. В общем - мимо кассы.

Не пугает, поскольку вы в очередной раз боретесь с выдуманными вами ветряными мельницами. Склад отдельно, бухгалтерия отдельно, магазин отдельно. У вас еще и витрина отдельно от основного магазина. Имеет право на жизнь для части простых магазинов, но в среднем - не катит.

Да а гдеж других кроме коробочных взять.

Самопис от дяди васи еще хуже... самопис под заказ = чумовые убытки.

Особенно если писать толстый бэкэнд, вместо тонкого фронтэнда.

Ммм... всё никак не запущу нагрузочное тестирование именно генерации... подозреваю ждать надо будет 1-2с на каждые 1000 страниц. Да, вы правильно заметили - я сам своим "кешем" управляю. Тогда, когда надо. А когда не надо, тогда не управляю.

А толку-то... сервис при этом работать перестает.

У вас закрыты части магазина для пользователей капчей или таймаутом :) ?

И эээ... получается продавать что-то ?

А у меня всё в кеше.

К счастью, в моей реальности не требуется искать по 100к товарам.

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

Хотя поиск - это одна из очень немногих задач, где с БД можно получить хоть какой-то выхлоп.

И то, если очень аккуратно себя вести.

Угу... я тоже так думал, ровно до момента когда яндекс пришел.

Причем ни до, ни после проблем с Crawl-delay не было, боты из сетей яндекса итп.

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

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

что вы ратуете за единую ИТ-инфраструктуру в рамках которой вы не только интернет-магазин,

но и все остальные задачи пусть убого, но решаете (как это пытаются делать коробочные

варианты).

Да в целом норм.

Мы так же идем. Немного не в таких глобальных масштабах.

А связка html5 странички + битрикс24.

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

Работает на ура, катаем 2ой год уже пошел. Объемы потихоньку переваливают основной сайт.

Так что если ИМ не на 10000 товаров, вы не торгуете болтами. То вполне. У нас есть свой обкатаный кейс. Сейчас заворачиваем подобным образом 1го клиента. Опыт нам понравился очень.

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

Единая инфраструктура это что?) Импорт/экспорт с 1С это уже единая инфраструктура. Я же говорю про единую архитектуру. Тут проще. Никто не требует чтобы ваш бекэнд жил на том же сервере что и шоп. Но когда все части системы написаны на одном фреймворке и т.п. - это упрощает поддержку.

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

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

У вас единая с 1С архитектура ?

У вас ешоп написан на 1с ?

О какой единой архитектуре можно говорить, когда действующий бизнес как правило

УЖЕ имеет свою бухгалтерию и свой склад. И переписывать это всё ради интернет-магазина

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

Я чем дальше, тем меньше понимаю, что у вас делает интернет-магазин, если бухгалтерию

и склад ведет что-то еще.

Для чего кроме выборок по параметрам вы используете базу данных именно в интернет-магазине ?

Что в ней вообще хранится и зачем ?

Это ведь отдельный сервер у вас с отдельной БД ?

Вы эээ... в интернет-магазин через эксель что-ли данные вставляете ?

Зачем ? Я когда пользовался коробкой генерировал просто SQL-скрипт, который вставлял в базу

всё, что нужно, если этого немного то еще и в одну транзакцию.

Ума не приложу, зачем может мальчик с экселем понадобиться.

Далеко не всегда. Мой опыт работы кредитным экспертом в банке говорит что далеко не всегда. Больше половины клиентов получавших у нас кредиты от 20к$ до 100к$ не имели учета даже в экселе, а только в тетрадочке.

Это был другой проект. Не магазин. Там была специфичная статистика для прогнозирования закупок. Боксовые решения не учитывали их специфику.

Ой, всё.

Неоднократно всё было пережевано. Мне лень, я сливаюсь.

Предлагаемый вами подход вполне применим для маленького интернет-магазина с одной продажей в неделю например. Типичным примером такого "магазина" является лэндинг-страница для продажи одной услуги типа строительства домов под ключ и т.п. Для этого можно использовать и безмускульные платформы вроде SimpleCMS.