23/08/2011
qwertyuiop:
А что делать если организация которая прекращает свою деятельность вообще как юр. лицо, арендаторам движка?
А что делать если организация которая прекращает свою деятельность вообще как юр. лицо, арендаторам движка?
Арендодатель может передать исходники и клиентов другой ИТ-компании, которая продолжит сопровождение клиентов, а если это невозможно по каким либо причинам - отдать исходники клиентам, чтобы они сопровождали магазин своими силами.
Кроме того, у нас, например, в любое время можно получить содержимое базы данных, добавленное в магазин посетителями сайта и менеджерами магазина, а также файлы дизайна, разработанные для магазина. Домен и так принадлежит заказчику. Все это можно передать другой ИТ-компании, чтобы она открыла магазин на своих программных и аппаратных средствах.
Вообще здесь все зависит от причины, по которой организация арендодателя прекращает свою деятельность. Вариант с передачей базы данных доступен всегда.
Что же касается других вариантов, то компании обычно не уходят вдруг с рынка, на котором они уже много лет. Компания может быть, например, реорганизована или продана, в этих случаях клиенты вообще могут не заметить никаких изменений.
Вообще, по моему мнению, ИТ-компании очень трудно завоевать репутацию, и очень легко ее потерять. Поэтому любой разумный арендодатель должен быть не заинтересован в такой ситуации, когда его клиенты оказываются брошены на произвол судьбы.
23/08/2011
qwertyuiop:
Какой движок лучше брать с точки зрения коробочной версии, что бы он уже был лично моим а не находился в собственности разработчика?
Какой движок лучше брать с точки зрения коробочной версии, что бы он уже был лично моим а не находился в собственности разработчика?
На мой взгляд, лучше всего брать тот движок, который Вы сможете полностью изучить и дорабатывать как программист. Либо лучше такой, который сможет дорабатывать по Вашим заявкам его непосредственный разработчик, т.к. только автор программы знает ее достаточно хорошо.
А доработки обычно требуются всегда, если магазин развивается.
Еще я бы посоветовал поинтересоваться, как использовать движок в условиях высокой нагрузки. Даже установив движок на выделенный физический сервер, еще нельзя быть уверенным, что он будет нормально работать при высокой нагрузке. А если об этом не подумать заранее, то после раскрутки магазина, когда будет много товаров, посетителей и заказов, могут начаться неприятности.
Конкретный движок не посоветую, т.к. мы пользуемся только своей разработкой.
09/09/2011
Александр Фролов:
На мой взгляд, лучше всего брать тот движок, который Вы сможете полностью изучить и дорабатывать как программист. Либо лучше такой, который сможет дорабатывать по Вашим заявкам его непосредственный разработчик
На мой взгляд, лучше всего брать тот движок, который Вы сможете полностью изучить и дорабатывать как программист. Либо лучше такой, который сможет дорабатывать по Вашим заявкам его непосредственный разработчик
Не факт. Всё зависит от критериев выбора.
Например, для меня, так лучший - тот, что меньше кушает ресурсов сервера.
Сервер у меня слабенький, тянет три сайта, один из которых инет магазин. Интернет магазин приносит порядка 10 - 20% прибыли от всего бизнеса, поэтому соответствующие расходы.
09/09/2011
Если у Вас свой сервер, имеет смысл оптимизировать системное ПО, а также ПО магазина и структуру базы данных. Проверьте, что используется Nginx, memcached, что правильно созданы индексы к полям таблиц, отключите логи апача и Nginx. Проверьте загрузку процессора, нагрузку на диски, использование памяти на сервере.
Рассмотрите возможность использования mongodb и sphinx.
Эти меры могут снизить нагрузку в разы и в десятки раз. Привлеките к работе опытного администратора и программиста, и результаты не заставят себя ждать. Если же всего этого не делать, любой движок может перегрузить сервер на ровном месте.
Рассмотрите возможность использования mongodb и sphinx.
Эти меры могут снизить нагрузку в разы и в десятки раз. Привлеките к работе опытного администратора и программиста, и результаты не заставят себя ждать. Если же всего этого не делать, любой движок может перегрузить сервер на ровном месте.
10/09/2011
Строго говоря, один физический сервер может содержать десятки сайтов со средней нагрузкой, сотни с относительно небольшой нагрузкой и тысячи малонагруженных сайтов.
Если три сайта тормозят, то скорее всего это либо из-за неправильной конфигурации системных средств, либо из-за неоптимального использования запросов SQL, либо из-за сильно ограниченных ресурсов сервера.
У нас, например, около десяти физических серверов, которые мы используем для хостинга наших интернет-магазинов. Большинство используется для хостинга проектов со средней нагрузкой, и один сервер в состоянии держать сотни таких проектов, либо несколько проектов повышенной нагрузки. И только для некоторых крупнооптовых магазинов приходится использовать выделенные серверы, главным образом из-за сложности бизнес-процессов по обработке заказов, складского учета, статистики, журналирования и т.п.
Но, во-первых, мы уже много лет работаем над архитектурой применяемых системных и прикладных программных средств в плане снижения нагрузки на сервер, и продолжаем работать сейчас. Это позволяет нам реже приобретать новые серверы, хотя парк серверов приходится пополнять каждый год.
Во-вторых, мы сами разрабатываем ПО наших магазинов, и можем вносить в них изменения, необходимые для снижения нагрузки.
В-тертьих, мы используем достаточно производительные серверы: два не самых слабых процессора Xeon, 48 Гбайт оперативной памяти, дисковый кеш-контроллер с батарейкой, SAS-диски со скроростью вращения 15К в минуту.
При всем при этом применяется многоуровневое кеширование и различные технологии ускорения.
Если у Вас сервер тормозит уже на трех сайтах, прежде всего необходимо провести анализ причин и найти узкие места.
Интересно следующее:
1. Конфигурация Вашего сервера (объем оперативной памяти, тип дисковой системы, например, используется ли программный RAID или аппаратный), кол-во и тип процессоров.
2. Кол-во активных процессов по сайтам и общий объем памяти, который они занимают.
3. Используется ли своп памяти.
4. Какие длинные запросы SQL выполняются, много ли запросов с JOIN-ами, создающих временные таблицы.
Еще один момент - серверы часто атакуют. Наши, во всяком случае)
При неправильной конфигурации системного и прикладного ПО даже простейший флуд, при котором в цикле вызывается какой-нибудь скрипт магазина, может "положить" сайт, а то и весь сервер. Необходимо анализировать входящий трафик и фильтровать паразитов.
Если три сайта тормозят, то скорее всего это либо из-за неправильной конфигурации системных средств, либо из-за неоптимального использования запросов SQL, либо из-за сильно ограниченных ресурсов сервера.
У нас, например, около десяти физических серверов, которые мы используем для хостинга наших интернет-магазинов. Большинство используется для хостинга проектов со средней нагрузкой, и один сервер в состоянии держать сотни таких проектов, либо несколько проектов повышенной нагрузки. И только для некоторых крупнооптовых магазинов приходится использовать выделенные серверы, главным образом из-за сложности бизнес-процессов по обработке заказов, складского учета, статистики, журналирования и т.п.
Но, во-первых, мы уже много лет работаем над архитектурой применяемых системных и прикладных программных средств в плане снижения нагрузки на сервер, и продолжаем работать сейчас. Это позволяет нам реже приобретать новые серверы, хотя парк серверов приходится пополнять каждый год.
Во-вторых, мы сами разрабатываем ПО наших магазинов, и можем вносить в них изменения, необходимые для снижения нагрузки.
В-тертьих, мы используем достаточно производительные серверы: два не самых слабых процессора Xeon, 48 Гбайт оперативной памяти, дисковый кеш-контроллер с батарейкой, SAS-диски со скроростью вращения 15К в минуту.
При всем при этом применяется многоуровневое кеширование и различные технологии ускорения.
Если у Вас сервер тормозит уже на трех сайтах, прежде всего необходимо провести анализ причин и найти узкие места.
Интересно следующее:
1. Конфигурация Вашего сервера (объем оперативной памяти, тип дисковой системы, например, используется ли программный RAID или аппаратный), кол-во и тип процессоров.
2. Кол-во активных процессов по сайтам и общий объем памяти, который они занимают.
3. Используется ли своп памяти.
4. Какие длинные запросы SQL выполняются, много ли запросов с JOIN-ами, создающих временные таблицы.
Еще один момент - серверы часто атакуют. Наши, во всяком случае)
При неправильной конфигурации системного и прикладного ПО даже простейший флуд, при котором в цикле вызывается какой-нибудь скрипт магазина, может "положить" сайт, а то и весь сервер. Необходимо анализировать входящий трафик и фильтровать паразитов.
18/09/2011
kuzmin:
А какая общая посещаемость в униках?
А какая общая посещаемость в униках?
Если в сумме, то наверно порядка 200 - 300k.
Все ресурсы сжирает неоптимизированный phpBB, но перейти на другой движок, по ряду причин, не могу.
Точных данных по нагрузке нет, у меня этим занимается специалист, я туду не лезу.
18/09/2011
300k в месяц, как я понимаю? Для дня, форума и mysql и одного "слабенького" сервера выглядит как-то фантастично:)
Для 10k в день это нормально, что затыкаеться. Mysql на отдельный сервак и можно забыть о нагрузке.
Все равно при этих значениях и в сети должны начаться затыки.
Мы так сначала всю статику выводили на отельный сервак, потом БД, а потом балансировку динамики.
Цель была минимум изменений в существующих сайтах. Грубо говоря выносили все, что можно вынести. В результате остался самый "нагруженный" участок, но его размер уже позволил начать его балансировку.
Для 10k в день это нормально, что затыкаеться. Mysql на отдельный сервак и можно забыть о нагрузке.
Все равно при этих значениях и в сети должны начаться затыки.
Мы так сначала всю статику выводили на отельный сервак, потом БД, а потом балансировку динамики.
Цель была минимум изменений в существующих сайтах. Грубо говоря выносили все, что можно вынести. В результате остался самый "нагруженный" участок, но его размер уже позволил начать его балансировку.
18/09/2011
Цитата:
Точных данных по нагрузке нет, у меня этим занимается специалист, я туду не лезу.
Точных данных по нагрузке нет, у меня этим занимается специалист, я туду не лезу.
А почему Ваш специалист не разберется с проблемой загрузки сервера? Ему нужна помощь?
19/09/2011
В этой теме вопросов больше чем ответов. Как лучше стартовать? Приходите 20 сентября на вебинар "Интернет магазин: экспресс-старт", может быть, проясните для себя основные вопросы. Подробнее здесь
19/09/2011
kuzmin:
300k в месяц, как я понимаю?
300k в месяц, как я понимаю?
В сутки, со всех сайтов.
Александр Фролов:
А почему Ваш специалист не разберется с проблемой загрузки сервера? Ему нужна помощь?
А почему Ваш специалист не разберется с проблемой загрузки сервера? Ему нужна помощь?
Специалист занимается только вопросами сервера а не программированием. Как он сообщил, проблема в кривом движке. Вернее, "тяжелом".
19/09/2011
krivin:
В этой теме вопросов больше чем ответов.
В этой теме вопросов больше чем ответов.
Чтобы появились ответы, ТС необходимо сначала ответить на вопросы)
Т.к. вряд-ли можно давать советы на все случаи жизни, нужно разбираться с каждой ситуацией отдельно. Особенно это относится к анализу причин медленной работы сайтов на выделенном сервере - здесь работа для специалистов.
19/09/2011
Цитата:
Специалист занимается только вопросами сервера а не программированием. Как он сообщил, проблема в кривом движке. Вернее, "тяжелом".
Специалист занимается только вопросами сервера а не программированием. Как он сообщил, проблема в кривом движке. Вернее, "тяжелом".
Такой подход не практичен, когда нет единого лица или компании, отвечающих за конечный результат. Постоянно будет возникать ситуация типа "К пуговицам претензии есть?"
Конечно, без программиста, который очень хорошо разбирается в Вашем движке, а также обладает очень большим опытом системного администрирования Unix-подобных ОС, проблему не решить.
На мой взгляд, если не менять движок, то нужно искать специалиста адекватного уровня, способного проанализировать и программное обеспечение, и настройки системных средств на сервере.
Либо надо искать компанию, которая имеет опыт создания сложных и высоконагруженных систем, чтобы она отвечала за конечный результат, а именно за надежную работу Вашей системы с нормальной производительностью.
300К посетителей в сутки - это уже заметная нагрузка, и тут действительно требуется комплексный анализ причин перегрузки сервера.
19/09/2011
Цитата:
В сутки, со всех сайтов
В сутки, со всех сайтов
Да ладно. Один "слабенький" сервак и 300к уников + форум. Не верю!:)
Я когда чистые сервера (без внешней нагрузки тестил, но динамические страницы) у меня максимум 10-15к получалось. Правда там памяти не очень много.
UPD: Чего то я протупил:) Сутки с секундами перепутал. 10-15к в секунду, конечно:) Все вопрос снимается.
Ответить