Pavel Denisov: Ох, не надейтесь! )
На самом деле запросов может быть куча, я просто привел пример, что подзапрос может работать быстрее, чем JOIN.
Это же абсолютный пример в вакууме.
Да, просто специфика другая, здесь покупа через интернет, ну и колбаса - это товар, можно провести экспертизу на качетсво и т.п. А услугу никак не докажешь была она оказана или нет, поэтому был интересен вопрос, как это регулируется законодательством.
Sergey Goryachev: Да, просто я до этого имел опыт работы с юр. лицами, там за услуги нужны акты, счета и прочее. Если работаешь с физ. лицом, ИП вроде должен дать ему чек. А здесь ничего этого не будет, поэтому я немного смущен, возможно, я чего-то не понимаю.
Есть подозрение, что у вас там стоит (в боте я имею ввиду) прослушивание сокета, до этого момента приложение работает, после стоит, т.к. ждет соединения по сокету, как только запрос приходит, приложение разблокируется и все идет дальше. Мне кажется, что так. Но я, конечно, совсем не уверен, т.к. нет исходного кода.
Роман: Я, конечно, не понимаю всех деталей. Но почему-то мне, кажется, что можно делать действия (что-то считывать, устанавливать соединение и т.д.), только после полной загрузки страницы, это возможно?
Будете использовать любой фронтенд-фреймворк, убедеитесть, что вы сделаете все хорошо, чтобы магазин индексировался поисковиками - технологии в данном случае дело десятое.
Роман: просто возьмите и протестируйте. Напишите сервер, напишите клиентский скрипт имитирующий сначала 1000 соединений, потом 500 соединение, но с пересоединением, замерьте нагрузку. Напишите статью по этому поводу, может кому-то тоже интересно. ;)
Роман: На самом деле "практически нет накладных расходов" - это неправда. Ну если представить другой вариант, что вы производите какие-нибудь манипуляции на сервере для определения источника, тогда получается следующая картина:
1. Ваш сайт использует 10 000 человек.
2. У каждого человека в серднем открыто 2 вкладки
3. Таким образом у вас открыто 20 000 соединений, т.е. вы искусственно увеличиваете количество соединений.
4. На сервере есть какой-то скрипт, который будет соединяться с базой, например, чтобы определить, кто это: пользователь или вкладка, что тоже создаст накладные расходы.
Так что мое сугубо личное мнение дисконнекты выгоднее в этом плане, ну и опять же это будет не ajax, который каждую секунду будет долбить ваш сервер и спрашивать как дела.
Bjornie: Я так скажу, исходя из своего опыта, парсится все, начиная от всяких соц. сетей, заканчиваю банковскими сайтами и сайтами полностью написанными на ajax. Эмуляция js-движка будет работать в любом случае долго.
Ну если совсем все плохо и вы не знаете, что и как делать, я могу посоветовать
1. Заспускать chrome в консольном режиме (без gui)
2. Использовать несколько потоков\процессов (каждый хром - один поток). Сделали 10 потоков, увеличили скорость в десять раз (если не вдаваться в подробности).
Алексей Сундуков: Я написал, что это ускорит переход по страницам, насчет парсинга DOM ничего не могу сказать, т.к. никогда не стояло такой задачи, возможно, вы правы.
На самом деле запросов может быть куча, я просто привел пример, что подзапрос может работать быстрее, чем JOIN.
Это же абсолютный пример в вакууме.