burunduk, спасибо за идею с якорями, до этого почему-то не рассматривали данный вариант.
burunduk, по-идеи для поисковых систем
http://site.ru/stranica.php
http://site.ru/stranica.php#kanal=direct26
являются одной же страницей?
Можно ли сделать вывод о том, что и ПФ будет
с http://site.ru/stranica.php#kanal=direct26
передаваться на http://site.ru/stranica.php ?
На практике это проверяли?
Согласны и готовы на всё. Может быть есть ещё какие-то альтернативные способы решения обозначенной проблемы, которые мы не видим?
Что Вы имеете ввиду?
В рамках какого стандарта?
skarui, спасибо. ---------- Добавлено 11.10.2016 в 19:21 ---------- Проверили, что при замене урла через js Яндекс.Метрика не фиксирует переход на другую страницу.
Можно ли сделать вывод, что для поисковых систем ПФ (время на странице, процент отказов и тд) для страницы
будут рассчитываться как будто не было изменения
урла на http://site.ru/stranica.php?kanal=direct26?
C Himiko когда-то давно сотрудничал. Качество работ не устроило.
Услуга вроде же востребованная... Неужели такой пустой рынок, что нет нормальных контор, которые работают по договорам...
Меняю второй раз Paxum => WMZ. Всё чётко.
vebmaster321, тоже ищу сервис массовых выплат. Пока у меня такой список:
http://payin-payout.net/massovye-vyplaty/
http://www.roboxchange.com/Environment/Partners/PaymentService.aspx
http://paysto.ru/ru/products/paymentGate
https://www.ooopay.org/
http://simplepayments.ru/rates/
http://masspaymer.ru/
http://www.menyala.ru/external_partner/description.asp
http://plugepay.com/blog/all-service-list/masspayment/
http://www.russianpost.ru/rp/servise/ru/home/finuslug/cybermoney_world
http://www.russianpost.ru/rp/servise/ru/home/usljurpersons/business/finservice
http://payeer.com/ru/
Дорогие форумчане, кто с кем работал? Буду очень благодарен, если поделитесь своим опытом.
Нам нужно пополнение с российского юр.лица(по договору с закрывающими документами), а выплаты на электронные деньги + карточки(или расчётные счета) в украинских банках.
Вы серьёзно? Не знал, что есть премиальные аккаунты. Как можно получить данный статус?
А как kiev.olx.com.ua смог такое сделать? Это видимо adsense для поиска?
MoMM, а комиссионный % тоже обсуждается или фиксированный?
dkameleon, нам тоже это было бы интересно, оборот через терминал будет около 1кк руб в месяц. Маловато?
Ясное дело, тарифы я уже посмотрел, вопрос не в том, чтобы не платить за что-то, а в том, что я не очень понимаю что такое ddos и может ли супер производительный фронтенд помочь с этим справиться.
Да, тут Вы правы на 100%, я не правильно написал, но имел ввиду правильное :)
Выше я приводил правильный расчёт.
У Вас ошибочное понимание того, что uptime и вероятность доступности сайта одно и тоже. Эти два параметра численно равны только при стремлении времени к бесконечности. В условиях нашей задачи год можно считать достаточно большим промежутком времени; неделя или час недостаточно большие.
Т.к падения сайта вызывает финансовые потери, если сайт падает редко, но метко(то есть на часы, но редко, а не постоянно на секунды; что как раз соответствует действительности), то можно считать, что
несколько секунд(ожидание бота ПС) << час << неделя < год
И если бот будет ждать только доли секунды(типо время стремится к нулю), то вероятность к нулю стремиться не будет.
Спасибо, но в принципе я всё уже прикинул. Тема была создана под впечатлением топиков и тем про отказ дисков в серверах и прочей ерунде, которая приводит к часовым простоям, а то и больше, которые приносят ощутимые финансовые потери(потери - не обязательно убыток, но и недополученная прибыль).
Пока считаю, что двойное резервирование достаточно, чтобы гарантировать отсутствие долгих простоев.
Товарищи, давайте не будем углубляться в тервер 3 курса института и пытаться показать свои мегазнания в области подбрасывания монеток, ведь правильный расчёт по серверам уже был приведен(мной :)), а сойдёмся, что все мы учились хорошо и было это полезно, но довольно давно, а поскольку такие знания приходится редко применять, то кто-то что-то мог подзабыть :)
Давайте лучше обсудим облака и возможность их помочь при ddos атаке, хотя бы слабой. Неужели это никому не интересно или для всех ответ на этот вопрос очевиден?
Про математику:
Конечный результат правильный, но когда писал, чуть-чуть описАлся в предыдущем посте, правильно:
(99.5/100)^(52) = 0.995^52 ~ 0.77 - вероятность, что бот за год будет заходить только на доступный сайт => 1 - 0.77= 0.23, то есть 23% - вероятность, что хоть раз за год бот зайдёт на недоступный сайт.
Вероятность что при однократном случайном заходе сайт будет доступен = 0.995
Вероятность что при двух случайных заходах сайт всегда(оба раза) будет доступен = 0.995 * 0.995
и тд
Для примера: вы подкидываете монетку, какая вероятность, что у Вас 10 раз подряд выпадет орёл? Ответ: 0.5^10
А если взять не 10 секунд, а время стремящееся к нулю, то вероятность по вашему тоже будет стремиться к нулю? Но это ведь не так :)
В своих расчётах я пренебрёг временем ожидания бота, посчитав его нулевым(т.к оно составляет менее 3% от среднего недельного времени простоя, а вычисления бы сильно усложнились).
yesRuslik, по идеи чем больше фронтендов тем выше отказоустойчивость(есть 3 "слоя": dns хостинг, фронтенд, основные сервера; и по идеи вероятность отказа всей системы - произведение вероятностей отказа всех "слоёв", дублирование фронтенда улучшает отказоустойчивость "слоя" фронтендов и ведёт к увеличению общей отказоустойчивости).
Спасибо всем за помощь и советы, особенно yesRuslik'у.
Что такое TTL? Это http://ru.wikipedia.org/wiki/Time_to_live? Из википедии:
Про какое кеширование здесь идёт речь?
То есть как получается время меньше минуты?
Я так понимаю это процесс, поправьте, пожалуйста, если заблуждаюсь:
Пользователь набирает домен в браузере, его провайдер берёт и смотрим в кеш и отправляет пользователя по IP, который там указан, то есть пока провайдер не обновит свой кеш, изменений пользователь не увидит, а обновление провайдером кеша может занимать долгое время.
Пока в голове созрел вот такой вот план:
1) DNS переведём на сервис, который позволяет делать "DNS+failover"(если можно получить скорость отключения нерабочего фронтенда порядка минуты).
2) В качестве параллельных фронтендов будут два VPS
3) Фронтенды будут подтягивать сайты с двух серверов(один основной и один дублирующий).
По идеи прокси VPS(фронтенды) потребляют мало ресурсов(место на диске не занимают и тд), может быть их засунуть в облако?
Поможет ли облако для отражения ddos атаки по сравнению со слабыми VPS?
Совершенно правильно, спасибо за исправление, это я и имел ввиду.
Понимание сколько готовы платить и за что есть. Поскольку по большому счёту я ничего не понимаю в администрирование серверов, то хотелось бы понять вообще какие есть варианты решения данной проблемы, с какими издержками и как подготовиться к их решению. Ведь задача типовая.
Реальность не 99,87%, а 99,5%(и это неплохо) на более длинном промежутке времени.
Давайте прикинем убытки от простоя:
1) Клиенты не звонят в первый раз.
2) Клиенты, которые были в процессе выбора и общения с менеджерами, отваливаются.(не могут ничего посмотреть на сайте)
3) Менеджеры не могут пользоваться сайтом и вести клиентов.(не могут без сайта подбирать "товар").
4) Головная боль и суета вокруг серверов и тд
5) Выпад страниц из индекса и потеря SEO трафика.
Вероятность, что поисковый бот зайдет на сайт в момент его недоступности
99,5%. Если на главную страницу бот заходит раз в неделю, а в году 52 недели, то
99,5^52 = 0,77, следовательно с вероятностью 23% за год у Вас должна вылететь главная страница из индекса, что приведет минимум к недельной потери SEO трафика.
Вообще статистика довольна обманчива, всё зависит не только от uptime, но и характере простоя. Например, если каждые 30 мин в рабочее время сервер отрубается на 18 секунд(uptime 99,5%), то звонков от клиентов будет в 3 раза меньше, т.к реальные клиенты сначала довольно долго ищут на сайте сами и если сайт не доступен 18 секунд, то они просто с него уходят.---------- Добавлено 14.06.2012 в 20:51 ----------yesRuslik, огромное спасибо, что прямо по полочкам описали варианты.
Как быстро в данном случае для клиентов будет доступен сайт?
Можете посоветовать какие-нибудь сервисы?
То есть нужно в одном ДЦ имееть 2 сервера, которые будут на одном IP?
Сейчас именно так всё и устроено. Фронтенд иногда падает. Первая мысль была сделать 2 фронтенда, чтобы минимально менять всю систему.