Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Разное

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: На каких хостингах работают интернет-магазины?
 
 автор: Владимир55   (01.10.2012 в 22:47)   письмо автору
 
 

Интернет-магазин сделан на HOSTCMS, посещаемость нулевая. Когда в него закачивается прайс из 1С, то если в прайсе больше тысячи товаров, то в каталог не попадает вообще ни одного товара!
По логам видно, что система перегружает хостинг и ее отрубают, а техподдержка CMS рекомендует перейти на более мощный хостинг.
Ради любопытства я разместил сайт на ВДС с объемом памяти 4Гб, но реальный прайс на 10 тысяч товаров из 1С закачать не удается! Три тысячи товаров закачивает, а если в прайсе больше, то памяти не хватает!

Тогда на этот же ВДС я установил Битрикс, но результат тот же самый – для закачки прайса из 1С ресурсов не хватает!

Сейчас я в полном недоумении: как же работают реальные интернет-магазины? На каких же хостингах их размещают?
Что, десять тысяч товаров для закачивания из 1С – это очень много, нереально много?

  Ответить  
 
 автор: cheops   (01.10.2012 в 23:31)   письмо автору
 
   для: Владимир55   (01.10.2012 в 22:47)
 

Большие интернет-магазины расположены не на одном и даже не на десятке серверов. Впрочем 10000 товаров - это действительно не много. Просто не нужно их загружать при помощи PHP-скриптов. А если и загружать, то разбивать задачу на части, индексировать не сразу, а после, аналогично работать с кэшами... т.е. процесс загрузки следует организовывать в соответствии с задачей, лучше если это вообще будет готовый SQL-дамп, который будет разворачиваться средствами СУБД.

PS Мы сейчас только и делаем, что пишем модули для готовых CMS и интернет-магазинов, чтобы предоставить владельцам те возможности, которые не входят/не работают по умолчанию. В общем это давняя проблема - программисты нужны и с каждым годом все больше и больше.

  Ответить  
 
 автор: Владимир55   (02.10.2012 в 01:04)   письмо автору
 
   для: cheops   (01.10.2012 в 23:31)
 

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

Правда ли, что популярные ЦМС не способны закачивать большие количества записей в прайсе? Скажем, две-три тысячи товаров на обычном хостинге - это предел.

Примерно так? И бесполезно долбить техподдержку?


"Впрочем 10000 товаров - это действительно не много. Просто не нужно их загружать при помощи PHP-скриптов. А если и загружать, то разбивать задачу на части".

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

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

1. Почему создатели CMS не делают этого сами? Это сверхсложная задача, с которой они не справляются?
2. Вы пишете модули, которые устраняют описанную проблему?

  Ответить  
 
 автор: cheops   (02.10.2012 в 08:33)   письмо автору
 
   для: Владимир55   (02.10.2012 в 01:04)
 

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

Сейчас сложилась такая ситуация, что сайты с нуля не разрабатываются - разрабатываются они отталкиваясь от какой-либо CMS или FrameWork. Любая CMS или FrameWork - это шаг в определенном направлении, как правило, ускоряющем разработку ПО для которого они проектировались. Однако, это может быть и шаг в противоположном вам направлении от требований, что вы и наблюдаете (если бы CMS с самого начала разрабатывалась с учетом скорости загрузки, такая функция была бы, но это редкая единичная операция, которую можно провести вручную, поэтому ей пожертвовали).

>Правда ли, что популярные ЦМС не способны закачивать большие количества записей в
>прайсе? Скажем, две-три тысячи товаров на обычном хостинге - это предел.
Истина такова, что разработчики хотят решать свои проблемы, а не ваши. Их проблема - организация кода, им важно чтобы им было легко, просто и быстро его сопровождать - они так смогут заработать больше денег. Ваш код, который это не учитывает, их категорически не устраивает, они готовы жертвовать ради своих денег и удобства чем угодно. Вы один клиент, если вас ПО не устривает, вы можете заказать себе другое, но зато с оставшимися клиентами им будет удобно.

>Ради любопытства, я сам написал внешний РНР скрипт (на Денвере), который привел в
>порядок файлы обмена, преобразовав их в несколько файлов по 500 товаров, которые потом
>вручную закачались за пару минут.
Если вы уже готовый дамп закачиваете в базу данных средствами базы данных - это делается вообще за секунды. Такова цена PHP и ПО, которое на нем разрабатывается, особенно, если это иерархические объектно-ориентированные системы.

>1. Почему создатели CMS не делают этого сами? Это сверхсложная задача, с которой они не
>справляются?
У них просто не стояло при разработке таких задач. Как правило, ПО пишется и тестируется на базе какого-то конкретного интернет-магазина. Реальная жизнь очень сложная и многообразная - нельзя охватить все, тем более, когда этого нет перед глазами, одно дело продавать программные модули, другое дело - компьютер, состоящий из нескольких компонентов разных производителей - для ведения таких интернет-магазинов нужны разное ПО. Попытка объединить их приводит к усложнению, в том числе и пользовательского интерфейса, и конечно, за это часто приходится расплачиваться скоростью. А теперь представьте, что вы все-таки создали такое ПО и у вас его покупают - внесение даже небольших изменений в него - это целая история.

>2. Вы пишете модули, которые устраняют описанную проблему?
Если такая задача будет поставлена, разумеется. Другое дело, что ваша CMS может быть написана и устроена таким образом, что она 10 000 товаров на отдельном сервере не выдержит... Возможно сразу имеет смысл думать об выносе сервера MySQL на отдельный выделенный сервер. Лучше всего загнать данные в CMS порциями и все-таки посмотреть.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования