- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Также две рассылки по 20к писем в месяц узкое место, почти гарантированые проблемы.
Ни каких проблем если будут соблюдены некоторые нюансы.
ptr
dkim
unsubscribe
relay
я не представляю как с 1 ГБ на диске, даже пусть это только база, 7 ГБ трафика в месяц и грамотным кодом можно сильно нагружать.
очень просто: представьте себе магазин в котором динамический учет товара и ведение склада и остатков, весь финансовый учет, скидки по группам клиентов и личные, партнерка на несколько уровней, собственная баннерка, весь биллинг, собственные счетчики посещений, CRM встроена, шлюзы с 15 системами оплаты и 5 системами доставки, личными кабинетами пользователей и огромным бэкофисом с системой публикации новостей, статей, анализом продаж по товарам, поставщикам, клиентам и в котором одновременно работают несколько менеджеров... постоянной нагрузки с учетом кэширования нет, но запросы к БД сыпятся постоянно: по баннеру партнера перешел посетитель на товар - и сразу и партнерка и баннерка и склад и цены и статистика пришли в движение...
MoMM, за вычетом баннерки и многоуровневой партнерски все это очень напоминает стандартный биллинг, например тот же whmcs, и никакой нагрузки.
Многоуровневая партнера нагрузку не создаст. А баннерка должна быть с учетом кэширующих элементов.
Какой-то пессимистично настроенный калькулятор, он считает, что все соединения будут постоянно одновременно выполнять запросы, заполняющие все их буферы
это у ТС спрашивайте - зачем ему столько много одновременных соединений и чтобы они все работали :)
---------- Добавлено 09.10.2015 в 09:13 ----------
а прикиньте, сделали такой сервак на пятерых клиентов по 50 баксов шаредом, получили в плюс 168 баксов
найдите ещё четверых, возьмите с них денег и заезжайте на такой сервер :)
мы себе возьмём по прайсу - все остальное Ваш профит
---------- Добавлено 09.10.2015 в 09:17 ----------
Это же космос, буфера надо экономичней подбирать :)
К примеру godaddy разрешает 200 :)
такой большой, а в сказки веришь :)
Запусти у них битрикс или проект с большой посещаемостью и посмотрим сколько тредов php одновременно тебе дадут запустить, чтобы хотя бы 100 коннектов заюзать....
Unlimited Websites
Unlimited Storage
Unlimited Bandwidth
Всё достаточно просто, считается на калькуляторе, тоже самое, что и про семь шапок
http://www.mysqlcalculator.com/
памяти мускулю надо
Max_Memory = query_cache_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + key_buffer_size + innodb_log_buffer_size
+ max_connections * (max_allowed_packet + sort_buffer_size + net_buffer_length + thread_stack + read_rnd_buffer_size + read_buffer_size + join_buffer_size)
Не калькулятор, а ужасы какие то! 😂
Из mysqltuner:
+
( read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size ) * max_connections
max_connections * max_allowed_packet - это даже не песиместично, слишком мягкое слово =)
ТС старается получить услугу соответсвенно оплате (если нет тут подводных камней).
Нет таких цен на такие услуги.
Баксов 200$ минимум за такие гарантии и условия.
найдите ещё четверых, возьмите с них денег и заезжайте на такой сервер
мы себе возьмём по прайсу - все остальное Ваш профит
kpv, вы не помните? Я же от вас в 2010 ушел, после того, как вы делали мне бэкапы из которых ничего невозможно восстановить. Мы их честно скачивали, но когда грохнулась база, выяснилось, что в бэкапах одни заголовки таблиц.
за вычетом баннерки и многоуровневой партнерски все это очень напоминает стандартный биллинг, например тот же whmcs, и никакой нагрузки.
Многоуровневая партнера нагрузку не создаст. А баннерка должна быть с учетом кэширующих элементов.
Господа, пожалуйста, не надо меня лечить. Магазину уже скоро 10 лет, он стоял на 3-х хостингах. Там нужно 100 коннектов, иначе тормоза, зависания и открывание страниц по 10 секунд. Я ж не с потолка эти цифры беру.
очень просто: представьте себе магазин в котором динамический учет товара и ведение склада и остатков, весь финансовый учет, скидки по группам клиентов и личные, партнерка на несколько уровней, собственная баннерка, весь биллинг, собственные счетчики посещений, CRM встроена, шлюзы с 15 системами оплаты и 5 системами доставки, личными кабинетами пользователей и огромным бэкофисом с системой публикации новостей, статей, анализом продаж по товарам, поставщикам, клиентам и в котором одновременно работают несколько менеджеров... постоянной нагрузки с учетом кэширования нет, но запросы к БД сыпятся постоянно: по баннеру партнера перешел посетитель на товар - и сразу и партнерка и баннерка и склад и цены и статистика пришли в движение...
если у вас все в одной базе то можно попробовать разделить ее на части т.е скажем выносите таблицы относящиеся к CRM в отдельную базу затем таблицы относящиеся к партнерке в другую базу, то что осталось в третью. Разделили значит на 3 базы. Затем покупаете 3 разных аккаунта виртуального хостинга и вешаете эти 3 базы на разные аккаунты, на одном аккаунте у вас лежит магазин со всем необходимым а на двух других только базы, теперь вам уже надо не 100 коннектов к базе а ~33.33 коннекта, самое трудное конечно это сделать такое разделение и все настроить
если у вас все в одной базе то можно попробовать разделить ее на части т.е скажем выносите таблицы относящиеся к CRM в отдельную базу затем таблицы относящиеся к партнерке в другую базу, то что осталось в третью. Разделили значит на 3 базы. Затем покупаете 3 разных аккаунта виртуального хостинга и вешаете эти 3 базы на разные аккаунты, на одном аккаунте у вас лежит магазин со всем необходимым а на двух других только базы, теперь вам уже надо не 100 коннектов к базе а ~33.33 коннекта, самое трудное конечно это сделать такое разделение и все настроить
зачем плодить сущности, управлять сложнее да и по цене так же.
нет никакой проблемы с количеством подключений, важно то что в них происходит.
зачем плодить сущности, управлять сложнее да и по цене так же.
нет никакой проблемы с количеством подключений, важно то что в них происходит.
я конечно не проводил анализ виртуальных VIP хостингов, но обычных шаредов которые разрешают 100 коннектов к базе практически нет