31/03/2009
Подскажите пожалуйста движек интернет магазина, чтобы выдерживал 200 000 товаров без тормозов.
Сейчас стоит ShopCMS, но жутко тормозит.
Сейчас стоит ShopCMS, но жутко тормозит.
01/04/2009
Какое количество посетителей (сколько на них просмотров)? На каком хостинге? Что говорит хостер? Как реализовано? Что-нить своё дописывалось? (например генерация изображений на лету (без записи в файл)), переносили ли БД, например, с локального компьютера на хостинг? Как?
...
Причин может быть вагон и маленькая тележка. Даже банальная кривая html-верстка. Т.е. сама страница "отдается" быстро, но из-за путаницы в разметке html браузер его, html-код, не может правильно и быстро обсчитать и показать.
Из-за какого-нить вставленного внешнего постороннего JavaScript-a у вас на стороне пользователя всё "глючит".
...
Повторюсь: Причин может быть вагон и маленькая тележка.
...
Причин может быть вагон и маленькая тележка. Даже банальная кривая html-верстка. Т.е. сама страница "отдается" быстро, но из-за путаницы в разметке html браузер его, html-код, не может правильно и быстро обсчитать и показать.
Из-за какого-нить вставленного внешнего постороннего JavaScript-a у вас на стороне пользователя всё "глючит".
...
Повторюсь: Причин может быть вагон и маленькая тележка.
01/04/2009
Так просто без детального исследования архитектуры "движка", SQL-запросов и параметров хостинга сказать ничего нельзя. Ускорить загрузку страниц поможет кэширование (в общем смысле этого слова), оптимизация запросов к базе данных, установка магазина на выделенный сервер.
Обычно во многих движках происходит обращение к базе данных при просмотре страниц товаров и каталогов, что при большой посещаемости вызывает чрезмерную нагрузку на сервер базы данных. В наших решениях мы исключили такое обращение полностью.
Если магазин стоит на обычном провайдерском хостинге вместе с сотнями и тысячами других сайтов, сервер может оказаться перегружен. Если магазин работает на VDS (виртуальном выделенном сервере), возможно заказано слишком мало оперативной памяти.
Наконец, могут быть проблемы с каналами провайдера, что, впрочем, менее вероятно.
Обычно во многих движках происходит обращение к базе данных при просмотре страниц товаров и каталогов, что при большой посещаемости вызывает чрезмерную нагрузку на сервер базы данных. В наших решениях мы исключили такое обращение полностью.
Если магазин стоит на обычном провайдерском хостинге вместе с сотнями и тысячами других сайтов, сервер может оказаться перегружен. Если магазин работает на VDS (виртуальном выделенном сервере), возможно заказано слишком мало оперативной памяти.
Наконец, могут быть проблемы с каналами провайдера, что, впрочем, менее вероятно.
01/04/2009
cjseriy:
Стоит на обычном виртуальном хостинге.
Стоит на обычном виртуальном хостинге.
Обычный виртуальный хостинг мало подходит для размещения интернет-магазинов с таким большим каталогом. На виртуальных хостингах обычно имеются серьезные ограничения по ресурсам, в частности, по загрузке процессора. Кроме того, на сервере виртуального хостинга может находиться большое количество сайтов, которые вызывают перегрузку сервера и, как следствие, медленную работу сайта.
Как вариант можно посоветовать перенести магазин на виртуальный выделенный сервер (VDS) с подходящими ресурсами или на выделенный сервер. При этом, однако, придется платить заметную сумму за хостинг или размещение выделенного сервера. Также потребуется определенный опыт администрирования ОС, или нужно искать специалиста для первоначальной настройки и сопровождения.
Мы размещаем интернет-магазины, которые сдаем в аренду, на собственных выделенных серверах, настроенных оптимальным образом для работы интернет-магазинов, и следим за их загрузкой.
01/04/2009
Шопцмс сам по себе тормозной скрипт, если стоит на неудачном хостинге.Воспользуйтесь хостингом, которое предлагают сами разработчики
02/04/2009
Цитата:
Обычно во многих движках происходит обращение к базе данных при просмотре страниц товаров и каталогов, что при большой посещаемости вызывает чрезмерную нагрузку на сервер базы данных. В наших решениях мы исключили такое обращение полностью.
Обычно во многих движках происходит обращение к базе данных при просмотре страниц товаров и каталогов, что при большой посещаемости вызывает чрезмерную нагрузку на сервер базы данных. В наших решениях мы исключили такое обращение полностью.
А можно по подробнее. Как можно полностью исключить обращение к БД? или вы на изменения забиваете?
03/04/2009
kuzmin:
А можно по подробнее. Как можно полностью исключить обращение к БД? или вы на изменения забиваете?
А можно по подробнее. Как можно полностью исключить обращение к БД? или вы на изменения забиваете?
Нет, конечно. Просто изменения вносятся в html-файлы в процессе публикации каталога товаров на витрине магазина. Это происходит один-два раза в день по необходимости, а просмотр страниц каталога и товаров - постоянно в течение дня. Соответственно, исключая обращение к базе данных в процесе просмотра каталога посетителями, мы серьезно снижаем нагрузку на сервер базы данных.
03/04/2009
Ясно, спасибо.
Я так понял вы везде статику генерите и только ее отдаете.
Вы изначально такой способ снижения брали или в процессе?
Просто нагрузки для меня больная тема (не в рамках ИМ), вот и пристаю ко всем с вопросами:)
Я так понял вы везде статику генерите и только ее отдаете.
Вы изначально такой способ снижения брали или в процессе?
Просто нагрузки для меня больная тема (не в рамках ИМ), вот и пристаю ко всем с вопросами:)
03/04/2009
kuzmin:
Вы изначально такой способ снижения брали или в процессе?
Вы изначально такой способ снижения брали или в процессе?
Мы начинали работу с виртуальных хостингов, поэтому над оптимизацией загрузки сервера думали с самого начала.
В архитектуре нашего ПО и баз данных изначально заложено многое для такой оптимизации. Ничего подобного в платных и бесплатных движках я пока не видел.
Кроме того, так как мы размещаем магазины на наших физических серверах, то можем полностью планировать и контролировать загрузку серверов.
При размещении на виртуальных хостингах и VDS такое недостижимо, потому что там на хостинговых серверах работают и другие сайты. Эти сайты могут перегружать сервер непредсказуемым образом, и на это никак нельзя повлиять.
03/04/2009
Понятно.
Последний вопрос, не могу придумать, как вы сессию при статике держите. Только куки? а если они отключены + выдача кука, ведь точка входа любая может быть.
Последний вопрос, не могу придумать, как вы сессию при статике держите. Только куки? а если они отключены + выдача кука, ведь точка входа любая может быть.
03/04/2009
kuzmin:
Последний вопрос, не могу придумать, как вы сессию при статике держите.
Последний вопрос, не могу придумать, как вы сессию при статике держите.
Здесь у нас по умолчанию нет никаких чудес - работаем через куки. Пока ни от кого жалоб не поступало... Но, разумеется, в статику мы можем включать вставки AJAX, SSI, вызов скриптов PHP и т.п. Иногда это требуется в решениях на заказ. Если это необходимо, мы можем легко заменить статические страницы динамическими, все или только часть.
Собственно, статика - не панацея, а только одна из мер в целом комплексе решений. Одно из основных - планирование использования ресурсов в рамках всего физического сервера.
03/04/2009
Так вот в том то и дело, что получается, те же ssi придется ставить на все страницы, чтобы кук правильно выдать, а это считай статики нет. Понятно, что запросов к БД будет меньше, но у нас как раз проблема генерации.
Идею я понял, спасибо за разъяснения.
Панацея - код писать изначально учитывая нагрузку. У нас на один сайт (не ИМ) с относительно не большой посещаемость 5 серверов еле справляются:)
Идею я понял, спасибо за разъяснения.
Панацея - код писать изначально учитывая нагрузку. У нас на один сайт (не ИМ) с относительно не большой посещаемость 5 серверов еле справляются:)
03/04/2009
kuzmin:
. У нас на один сайт (не ИМ) с относительно не большой посещаемость 5 серверов еле справляются
. У нас на один сайт (не ИМ) с относительно не большой посещаемость 5 серверов еле справляются
Да, возможно надо пересмотреть архитектуру всего приложения в целом, архитектуру базы данных, распараллелить обработку по серверам, добавить памяти в серверы, сменить ОС. Возможно, программисты нормализовали базу данных до 4-й формы, используют запросы с JOIN-ами и созданием временных таблиц или какие-либо "лобовые" универсальные решения... В общем, тут нужен глубокий системный анализ.
03/04/2009
В том то и дело, пересмотреть не возможно уже. На данный момент написано 3-мя группами программистов уже очень много мегабайт кода:( Причем первая рассуждала, тормозит - увеличиваем память, процы, сервера и т.д. Ну когда и это стало не помогать (удивительно!), начали на админа серверов валить (тоже не помогло)... остались только они:)
Что-то, конечно, переписывается, но все переписать на данный момент не возможно. Мы уже 3 года эксперименты ставим, как все это дело ускорить.
Вот любые мелочи борьбе с нагрузкой меня и интересуют.
еще в личку написал:)
Что-то, конечно, переписывается, но все переписать на данный момент не возможно. Мы уже 3 года эксперименты ставим, как все это дело ускорить.
Вот любые мелочи борьбе с нагрузкой меня и интересуют.
еще в личку написал:)
Ответить