 |
|
15/02/2011
Александр Фролов:
Причем тут недостатки разработки??
Дело не в недостатках разработки, а в целях, которые ставили перед собой разработчики.
Причем тут недостатки разработки??
Дело не в недостатках разработки, а в целях, которые ставили перед собой разработчики.
Для Вас, может, самое важное и состоит в целях. А для простого потребителя важны не цели неизвестных ему разработчиков, а результат их работы. И недостатки тут очень даже при чем.
Если прочтете внимательно тему с начала, увидите, что обсуждаемые вопросы начались именно с недостатков и способов их исправления.
 |
Александр Фролов
Генеральный директор, Shop2YOU |
15/02/2011
grig:
Для Вас, может, самое важное и состоит в целях. А для простого потребителя важны не цели неизвестных ему разработчиков, а результат их работы. И недостатки тут очень даже при чем.
Для Вас, может, самое важное и состоит в целях. А для простого потребителя важны не цели неизвестных ему разработчиков, а результат их работы. И недостатки тут очень даже при чем.
Тут ведь как получается - потребитель пробует движок в своих условиях: с каким-то набором настроек, на таком-то хостинге, при таком-то объеме каталогов и такой-то посещаемостью. Движок ему не нравится. Другой потребитель пробует тот же движок в других условиях, и он отлично ему подходит.
Означает ли это, что движок плохой?
Ведь один и тот же инструмент в разных руках будет вести себя по-разному.
Однако моя мысль заключается в том, что любой движок, особенно массового применения, для получения оптимальных результатов нуждается в настройке, подборе хостинга и настроек хостинга.
И делать такую настройку должен специлист, лучше всего если это будет сам разработчик движка.
Бессмысленно сравнивать разные движки с параметрами настройки по умолчанию и безотносительно конкретной ситуации. Как я уже говорил, разработчик "коробочного" движка стремится охватить как можно более широкий круг потребителей, а не ориентируется на каждого потребителя в отдельности.
Знание этого факта позволяет понять, почему нужны именно индвииуальные настройки и доработки, если требуется "выжать" из движка все, на что он способен.
Мы, например, видели движки, генерирующие сотнями запросы к СУБД при показе одной страницы. При этом в них использовались многочисленные запросы с JOIN-нами и нормализованная структура базы данных.
Очевидно, что при небольшом количестве товаров и невысокой посещаемости это будет работать вполне приемлемо, однако добиться нормальной работы на высокой загрузке без кеширования и оптимизации структуры базы данных не получится.
А если нужно еще делать параметрические запросы с морфологией? Тогда нужно подключать Sphinx, а это уже не коробочное решение.
Поэтому если проявляется какой-нибудь недостаток, надо вначале понять причину его появления, а потом искать решение в этом конкретном случае.
Это может быть не недостаток движка, а неправильная его настройка, неправильный выбор хостинга, неправильная настройка хостингового сервера и т.п.
|
|
|
15/02/2011
Александр Фролов:
Бессмысленно сравнивать разные движки с параметрами настройки по умолчанию и безотносительно конкретной ситуации. Как я уже говорил, разработчик "коробочного" движка стремится охватить как можно более широкий круг потребителей, а не ориентируется на каждого потребителя в отдельности.
Бессмысленно сравнивать разные движки с параметрами настройки по умолчанию и безотносительно конкретной ситуации. Как я уже говорил, разработчик "коробочного" движка стремится охватить как можно более широкий круг потребителей, а не ориентируется на каждого потребителя в отдельности.
Бессмысленно в который раз повторять одно и то же о трудностях (и необходимости оплачивать услуги спеца там, где чаще всего и начинающие справляются).
Осмысленно, например, сравнивать два движка в ОДИНАКОВОЙ ситуации. Если один дает в среднем на странице 50 запросов к БД , а другой 500, то можно делать определенные выводы.
Вот хочу увидеть живьем данные по Вашему движку. Например, делаю простейший магазин на 100 товаров. Какая будет статистика по запросам (главная страница, страница товара и т.д)? Потом на 200 товаров и тот же вопрос. Потом 300 товаров и далее...
Можете помочь с получением таких сведений?
|
|
Александр Фролов
Генеральный директор, Shop2YOU |
15/02/2011
grig:
Вот хочу увидеть живьем данные по Вашему движку. Например, делаю простейший магазин на 100 товаров. Какая будет статистика по запросам (главная страница, страница товара и т.д)? Потом на 200 товаров и тот же вопрос. Потом 300 товаров и далее...
Можете помочь с получением таких сведений?
Вот хочу увидеть живьем данные по Вашему движку. Например, делаю простейший магазин на 100 товаров. Какая будет статистика по запросам (главная страница, страница товара и т.д)? Потом на 200 товаров и тот же вопрос. Потом 300 товаров и далее...
Можете помочь с получением таких сведений?
Если речь идет о готовых решениях, то запросов будет 0 (ноль) незваисимо от количества товаров. Это связано с тем, что все страницы товаров и каталога, информационных разделов являются статическим HTML.
При необходимости включения динамических вставок (обычно в решениях Advanced) количество запросов зависит от каждой конкретной ситуации. Загрузка на MySQL сервер снижается за счет кеширования результатов этих запросов в memcached.
 |
|
15/02/2011
Ну, вот что. Почитал я этот топик и «Первый пошёл», в которых пишут в основном программисты и другие доблестные IT-работнички, которые почему то решили, что они лучше самих владельцев знают, какой должен быть интернет-магазин и что от него требуется. С такой позицией никак нельзя согласиться, поэтому вставлю свои пять копеек.
1. Большинство магазинов выполняют стандартную задачу – продают товар. Поэтому ничего для них специально изобретать, создавать, настраивать, и пугать умными словами не надо. Просто надо выбрать нормальный движок. Можно выбрать и платный и бесплатный. По движкам у меня мнение сложилось такое. Платные движки предлагают больше фич и лучше проработаны. Но только те, которые дорого стоят. Та же Presta даст сто очков вперёд многим платным движкам. Но не всем понятное дело. Фирме с амбициями, у которой есть деньги лучше действительно купить хороший коммерческий движок.
2. Чем больше фич, тем лучше. Задача разработчика только сделать так чтобы они не мешались, пока не востребованы. То, что ненужно пока магазин маленький и имеет небольшой ассортимент, может понадобиться потом, когда магазин будет развиваться. Могу сказать, что в моём случае так и было, не всеми фичами пользовался в начале работы с магазином, которые имеет движок Webasyst, а потом многие задействовал. Более того могу сказать что многого и не хватает ещё для меня.
3. По поводу хостинга, опять же ничего сверхъестественного для стандартного интернет-магазина не требуется. Нормальный серьёзный хостер предоставит всё что нужно. У меня хостинг в Ru-center – устраивает всё.
4. Если человек вчера торговал турецкими шмотками в Лужниках, а сегодня ещё захотел продавать в интернете, ему нечего и рыпаться пусть идёт к Александру Фролову и арендует у него магазин. А людям знакомым с электронной торговлей, ИМХО надо ставить свой движок, платный или бесплатный в зависимости от средств. С ним они получат больше гибкости. О чем, кстати, не так давно писала на этом форуме Алиса, рассказывая про свой опыт с SAAS-сервисом.
1. Большинство магазинов выполняют стандартную задачу – продают товар. Поэтому ничего для них специально изобретать, создавать, настраивать, и пугать умными словами не надо. Просто надо выбрать нормальный движок. Можно выбрать и платный и бесплатный. По движкам у меня мнение сложилось такое. Платные движки предлагают больше фич и лучше проработаны. Но только те, которые дорого стоят. Та же Presta даст сто очков вперёд многим платным движкам. Но не всем понятное дело. Фирме с амбициями, у которой есть деньги лучше действительно купить хороший коммерческий движок.
2. Чем больше фич, тем лучше. Задача разработчика только сделать так чтобы они не мешались, пока не востребованы. То, что ненужно пока магазин маленький и имеет небольшой ассортимент, может понадобиться потом, когда магазин будет развиваться. Могу сказать, что в моём случае так и было, не всеми фичами пользовался в начале работы с магазином, которые имеет движок Webasyst, а потом многие задействовал. Более того могу сказать что многого и не хватает ещё для меня.
3. По поводу хостинга, опять же ничего сверхъестественного для стандартного интернет-магазина не требуется. Нормальный серьёзный хостер предоставит всё что нужно. У меня хостинг в Ru-center – устраивает всё.
4. Если человек вчера торговал турецкими шмотками в Лужниках, а сегодня ещё захотел продавать в интернете, ему нечего и рыпаться пусть идёт к Александру Фролову и арендует у него магазин. А людям знакомым с электронной торговлей, ИМХО надо ставить свой движок, платный или бесплатный в зависимости от средств. С ним они получат больше гибкости. О чем, кстати, не так давно писала на этом форуме Алиса, рассказывая про свой опыт с SAAS-сервисом.
 |
|
15/02/2011
С этим престашопом у моего знакомого вышел казус.
Он его поставил, опробовал, затем долго делал дизайн, наполнял товаром.
Потом, за серьёзные деньги запустил рекламу.
И, когда к нему пошли посетители, хостер его отрубил по причине большого потребления ресурсов.
В общем, потраченное время и деньги рекламы вылетели в трубу, посетители вместо магазина, наблюдали гордую надпись хостера, что аккаунт отключен
Не помню сколько времени он бодался c хостером, но в итоге, перешел на движок мелбис, говорит что хостер пока терпит.
Он его поставил, опробовал, затем долго делал дизайн, наполнял товаром.
Потом, за серьёзные деньги запустил рекламу.
И, когда к нему пошли посетители, хостер его отрубил по причине большого потребления ресурсов.
В общем, потраченное время и деньги рекламы вылетели в трубу, посетители вместо магазина, наблюдали гордую надпись хостера, что аккаунт отключен
Не помню сколько времени он бодался c хостером, но в итоге, перешел на движок мелбис, говорит что хостер пока терпит.
|
|
|
15/02/2011
Александр Фролов:
Если речь идет о готовых решениях, то запросов будет 0 (ноль) незваисимо от количества товаров. Это связано с тем, что все страницы товаров и каталога, информационных разделов являются статическим HTML.
Если речь идет о готовых решениях, то запросов будет 0 (ноль) незваисимо от количества товаров. Это связано с тем, что все страницы товаров и каталога, информационных разделов являются статическим HTML.
В готовых решениях запросов всегда 0. Это, конечно, для быстродействия очень хорошо. А если в готовом решении покупатель кладет товар в корзину, оформляет заказ? Неужели тоже запросов 0 ?
|
|
Александр Фролов
Генеральный директор, Shop2YOU |
15/02/2011
grig:
А если в готовом решении покупатель кладет товар в корзину, оформляет заказ? Неужели тоже запросов 0 ?
А если в готовом решении покупатель кладет товар в корзину, оформляет заказ? Неужели тоже запросов 0 ?
В этом случае запросы есть, например, нужно записать идентификатор товара в таблицу корзины. Однако такие запросы не создают существенной нагрузки на сервер СУБД, так как их очень мало (сотни или тысячи в день или около того).
В то же время многие движки созданы на PHP таким образом, что страницы каталога, товаров и других разделов сайта формируются динамически. При формировании каждой страницы скрипты PHP обращаются к базе данных, извлекая из них информацию о товарах, разделах каталогов и т.п.
Если сайт высокопосещаемый, то к базе данных идет лавина запросов. С этой лавиной можно справиться, например, с помощью кеширования.
Мы пошли дальше и вообще исключили запросы при просмотре страниц сайта, а если такие запросы все же необходимы, то мы их кешируем при помощи memcaсhed. Это позволяет очень существенно снизить нагрузку на сервер и увеличить скорость загрузки страниц.
Фактически при просмотре страниц у нас дело не доходит даже до Апача, статика отдается через nginx, не говоря уже о том что мы не трогаем сервер базы данных.
При этом мы размещаем сайты на наших собственных серверах довольно мощной конфигурации, что позволяет нам добиться хорошей скорости работы магазинов.
|
|
Александр Фролов
Генеральный директор, Shop2YOU |
15/02/2011
qualified:
А людям знакомым с электронной торговлей, ИМХО надо ставить свой движок, платный или бесплатный в зависимости от средств. С ним они получат больше гибкости. О чем, кстати, не так давно писала на этом форуме Алиса, рассказывая про свой опыт с SAAS-сервисом.
А людям знакомым с электронной торговлей, ИМХО надо ставить свой движок, платный или бесплатный в зависимости от средств. С ним они получат больше гибкости. О чем, кстати, не так давно писала на этом форуме Алиса, рассказывая про свой опыт с SAAS-сервисом.
С какой стати они получат больше гибкости??
Они получат головную боль с развитием ПО, с наемом программистов и сопровождением процесса разработки.
У нас развитием магазина занимаются его непосредственные разработчики, и помимо простых решений, у нас есть очень продвинутые магазины с поддержкой сложных бизнес-процессов.
Поэтому начинающие предприниматели могут взять у нас для начала недорогое готовое решение, а потом совершенствовать его любым необходимым образом.
|
|
|
15/02/2011
Александр Фролов:
Если речь идет о готовых решениях, то запросов будет 0 (ноль)
Если речь идет о готовых решениях, то запросов будет 0 (ноль)
А как же без запросов, будет отображиться раздел, где например покупатель выставит диапазон цен для отображения ?
Как без запросов делается поиск товара по каким-то критериям или например параметрический поиск ?
Этож сколько страниц нужно нагенерировать ?
|
|
Александр Фролов
Генеральный директор, Shop2YOU |
15/02/2011
Цитата:
А как же без запросов, будет отображиться раздел, где например покупатель выставит диапазон цен для отображения ?
Как без запросов делается поиск товара по каким-то критериям или например параметрический поиск ?
Этож сколько страниц нужно нагенерировать ?
А как же без запросов, будет отображиться раздел, где например покупатель выставит диапазон цен для отображения ?
Как без запросов делается поиск товара по каким-то критериям или например параметрический поиск ?
Этож сколько страниц нужно нагенерировать ?
Поиск и отбор по ценам, разумеется, делается через запросы. Когда мы делали один проект с каталогом 700000 товаров, то подключали для морфологического поиска Sphinx, работает довольно быстро.
Но результаты поиска очень хорошо кешируются. Объем кеша такой, что каждый запрос фактически можно делать только один раз, а потом просто выбирать его из кеша.
Ну а обычные страницы или заготовки для них можно и нагенерировать. Не то чтобы это был простой и прямолинейный процесс, но реально мы генерим каталоги на десятки и сотни тысяч товаров на наших серверах за приемлемое для заказчика время.
|
|
|
15/02/2011
Александр Фролов:
В этом случае запросы есть, например, нужно записать идентификатор товара в таблицу корзины. Однако такие запросы не создают существенной нагрузки на сервер СУБД, так как их очень мало (сотни или тысячи в день или около того).
В этом случае запросы есть, например, нужно записать идентификатор товара в таблицу корзины. Однако такие запросы не создают существенной нагрузки на сервер СУБД, так как их очень мало (сотни или тысячи в день или около того).
Тогда не похоже, что у Вас много покупателей, если учесть то, что у Вас работают много магазинов.
Можете дать хоть какую-то статистику :
Сколько сайтов ?
Сколько товаров всего на всех сайтах?
Покупок в день на всех сайтах?
Запросов к БД в день?
|
|
Александр Фролов
Генеральный директор, Shop2YOU |
15/02/2011
grig:
Тогда не похоже, что у Вас много покупателей, если учесть то, что у Вас работают много магазинов.
Тогда не похоже, что у Вас много покупателей, если учесть то, что у Вас работают много магазинов.
Здесь имеется в виду, что в день редко в одном магазине совершают более 1000 покупок, соответственно, нагрузка на сервер со стороны одного магазина при добавлении товара в корзину пренебрежимо мала.
grig:
Можете дать хоть какую-то статистику :
Сколько сайтов ?
Сколько товаров всего на всех сайтах?
Покупок в день на всех сайтах?
Запросов к БД в день?
Можете дать хоть какую-то статистику :
Сколько сайтов ?
Сколько товаров всего на всех сайтах?
Покупок в день на всех сайтах?
Запросов к БД в день?
Всего у нас на нескольких серверах несколько сотен магазинов.
Могу сказать, что размер каталога порядка 10000 товаров является для нас обычным, и есть магазины, содержащие десякти и сотни тысяч товаров. Общий объем ежедневного бекапа на всех серверах составляет несколько десятков Гбайт.
С количеством запросов к базе данных ситуация разная на разных серверах. На одном из высокопосещаемых сайтов кеш обрабатывает примерно несколько десятков тысяч запросов в минуту, при этом непосредственно к базе данных пропускается только малая их часть.
У нас нет необходимости отслеживать общее количество товаров, покупок и запросов. Мы просто следим за общей загрузкой наших серверов с помощью централизованной системы мониторинга, и если на каком-то из серверов возрастает нагрузка, определяем причину и тогда уже проводим конкретные исследования.
Мы также знаем наши высокопосещаемые сайты и постоянно работаем над их оптимизацией. Это нужно нам для более экономного расходования ресурсов наших серверов.
|
|
|
16/02/2011
Я конечно не специалист, но вот интересно.
А почему Вы так категорично устраняете запросы в базу ? Ведь, ведь база, это не нечто мифическое, а по по сути теже самые файлы. И, всё равно, все операции с базой, сводится к файловым операциям.
Многие таблицы бызы, даже полностью находятся в ОЗУ, и во многих случаях, будет быстрее взять данные из ОЗУ, чем дёргать файл с жесткого диска.
Собственно, на сколько мне ихвестно, базу и делали для того, что-бы не хранить данные в разбросанных файлах, а Вы делаете обратное действие.
А почему Вы так категорично устраняете запросы в базу ? Ведь, ведь база, это не нечто мифическое, а по по сути теже самые файлы. И, всё равно, все операции с базой, сводится к файловым операциям.
Многие таблицы бызы, даже полностью находятся в ОЗУ, и во многих случаях, будет быстрее взять данные из ОЗУ, чем дёргать файл с жесткого диска.
Собственно, на сколько мне ихвестно, базу и делали для того, что-бы не хранить данные в разбросанных файлах, а Вы делаете обратное действие.
|
|
Александр Фролов
Генеральный директор, Shop2YOU |
16/02/2011
Цитата:
почему Вы так категорично устраняете запросы в базу ? Ведь, ведь база, это не нечто мифическое, а по по сути теже самые файлы. И, всё равно, все операции с базой, сводится к файловым операциям.
Многие таблицы бызы, даже полностью находятся в ОЗУ, и во многих случаях, будет быстрее взять данные из ОЗУ, чем дёргать файл с жесткого диска.
Собственно, на сколько мне ихвестно, базу и делали для того, что-бы не хранить данные в разбросанных файлах, а Вы делаете обратное действие.
почему Вы так категорично устраняете запросы в базу ? Ведь, ведь база, это не нечто мифическое, а по по сути теже самые файлы. И, всё равно, все операции с базой, сводится к файловым операциям.
Многие таблицы бызы, даже полностью находятся в ОЗУ, и во многих случаях, будет быстрее взять данные из ОЗУ, чем дёргать файл с жесткого диска.
Собственно, на сколько мне ихвестно, базу и делали для того, что-бы не хранить данные в разбросанных файлах, а Вы делаете обратное действие.
На самом деле мы используем такое кеширование, при котором нам вообще не нужно обращаться к СУБД за данными, а мы берем их непосредственно из оперативной памяти. Это дает максимальную скорость выборки.
Что же касается обращений к базе данных, то даже если таблицы уже лежат в памяти, на разбор, анализ и оптимизацию SQL-запроса СУБД тратит ресурсы сервера, тратит коннекшены, количество которых ограничено, выполняет системные запросы и т.д.
Т.е. без обращений к базе по любому будет быстрее.
Ответить
