freedz

freedz
Рейтинг
115
Регистрация
16.04.2007

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 ?

На практике это проверяли?

burunduk:
если ни на что другое ваши специалисты не готовы

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

mendel:

Лично я бы посоветовал добавлять метки не JS а на стороне сервера.

Что Вы имеете ввиду?

mendel:

И да, советую таки оставаться в рамках стандарта а не выдумывать велосипед.

В рамках какого стандарта?

skarui, спасибо.

---------- Добавлено 11.10.2016 в 19:21 ----------

Проверили, что при замене урла через js Яндекс.Метрика не фиксирует переход на другую страницу.

Можно ли сделать вывод, что для поисковых систем ПФ (время на странице, процент отказов и тд) для страницы

http://site.ru/stranica.php

будут рассчитываться как будто не было изменения

урла на 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/

Дорогие форумчане, кто с кем работал? Буду очень благодарен, если поделитесь своим опытом.

Нам нужно пополнение с российского юр.лица(по договору с закрывающими документами), а выплаты на электронные деньги + карточки(или расчётные счета) в украинских банках.

Аргон-17:
у olx премиум акк ☝

Вы серьёзно? Не знал, что есть премиальные аккаунты. Как можно получить данный статус?

А как kiev.olx.com.ua смог такое сделать? Это видимо adsense для поиска?

MoMM, а комиссионный % тоже обсуждается или фиксированный?

dkameleon, нам тоже это было бы интересно, оборот через терминал будет около 1кк руб в месяц. Маловато?

netwind:
для таких умников облачные сервисы тарифицируют трафик.

Ясное дело, тарифы я уже посмотрел, вопрос не в том, чтобы не платить за что-то, а в том, что я не очень понимаю что такое ddos и может ли супер производительный фронтенд помочь с этим справиться.

hvosting:
Опять же правильно "почти".

Вероятность успешной работы системы = произведение вероятностей успешной работы всех систем.
Вероятность сбоя сложной системы = 1 - вероятность успешной работы.

Да, тут Вы правы на 100%, я не правильно написал, но имел ввиду правильное :)

cvss:
Простая иллюстрация вашей ошибки - обратитесь к сайту 52 раза не за год, а за минуту или за час. Вы уверены, что с вероятностью 26% получите отказ? Обратитесь 520 раз за час - по вашей методике подсчета вероятность отказа будет 92%. Повторяйте эту серию обращений каждый час в течение года, у вас все эти разы вероятность отказа должна быть 92%. Все еще считаете, что у вас нет ошибки?

Выше я приводил правильный расчёт.

У Вас ошибочное понимание того, что uptime и вероятность доступности сайта одно и тоже. Эти два параметра численно равны только при стремлении времени к бесконечности. В условиях нашей задачи год можно считать достаточно большим промежутком времени; неделя или час недостаточно большие.

Т.к падения сайта вызывает финансовые потери, если сайт падает редко, но метко(то есть на часы, но редко, а не постоянно на секунды; что как раз соответствует действительности), то можно считать, что

несколько секунд(ожидание бота ПС) << час << неделя < год

И если бот будет ждать только доли секунды(типо время стремится к нулю), то вероятность к нулю стремиться не будет.

hvosting:
З.Ы. У меня второе высшее как раз защита информации. Включает в себя анализ рисков и т.д.
ЕСЛИ ваш проект действительно денежный - могу вам на платной основе помочь действительно корректно посчитать ваши риски и прикинуть оптимальный аптайм с средства борьбы за него.

Спасибо, но в принципе я всё уже прикинул. Тема была создана под впечатлением топиков и тем про отказ дисков в серверах и прочей ерунде, которая приводит к часовым простоям, а то и больше, которые приносят ощутимые финансовые потери(потери - не обязательно убыток, но и недополученная прибыль).

Пока считаю, что двойное резервирование достаточно, чтобы гарантировать отсутствие долгих простоев.

Товарищи, давайте не будем углубляться в тервер 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 секунд на выполнение запроса - 0.0000165.

А если взять не 10 секунд, а время стремящееся к нулю, то вероятность по вашему тоже будет стремиться к нулю? Но это ведь не так :)

В своих расчётах я пренебрёг временем ожидания бота, посчитав его нулевым(т.к оно составляет менее 3% от среднего недельного времени простоя, а вычисления бы сильно усложнились).

yesRuslik, по идеи чем больше фронтендов тем выше отказоустойчивость(есть 3 "слоя": dns хостинг, фронтенд, основные сервера; и по идеи вероятность отказа всей системы - произведение вероятностей отказа всех "слоёв", дублирование фронтенда улучшает отказоустойчивость "слоя" фронтендов и ведёт к увеличению общей отказоустойчивости).

Спасибо всем за помощь и советы, особенно yesRuslik'у.

yesRuslik:
При DNS+failover время переключения равно TTL + инертность самого фейловер-механизма.
В цифрах можно добиться от 30 до 60 секунд.

Что такое TTL? Это http://ru.wikipedia.org/wiki/Time_to_live? Из википедии:

Время жизни записей DNS
Для DNS-записей параметр «Time to live» определяет время актуальности данных при кешировании запросов. Задаётся в секундах, типичное значение составляет 86 400 секунд, т.е. 24 часа. Это означает, что при изменении записи DNS, вплоть до 24 часов после изменения DNS-серверы по всему миру могут выдавать старые данные из кеша, пока он не будет обновлён.

Про какое кеширование здесь идёт речь?

То есть как получается время меньше минуты?

Я так понимаю это процесс, поправьте, пожалуйста, если заблуждаюсь:

Пользователь набирает домен в браузере, его провайдер берёт и смотрим в кеш и отправляет пользователя по IP, который там указан, то есть пока провайдер не обновит свой кеш, изменений пользователь не увидит, а обновление провайдером кеша может занимать долгое время.

Пока в голове созрел вот такой вот план:

1) DNS переведём на сервис, который позволяет делать "DNS+failover"(если можно получить скорость отключения нерабочего фронтенда порядка минуты).

2) В качестве параллельных фронтендов будут два VPS

3) Фронтенды будут подтягивать сайты с двух серверов(один основной и один дублирующий).

По идеи прокси VPS(фронтенды) потребляют мало ресурсов(место на диске не занимают и тд), может быть их засунуть в облако?

Поможет ли облако для отражения ddos атаки по сравнению со слабыми VPS?

hvosting:
На самом деле суть - минимизировать убытки от простоя сервиса _в сумме с расходами на поддержку сервиса_.

Совершенно правильно, спасибо за исправление, это я и имел ввиду.

Понимание сколько готовы платить и за что есть. Поскольку по большому счёту я ничего не понимаю в администрирование серверов, то хотелось бы понять вообще какие есть варианты решения данной проблемы, с какими издержками и как подготовиться к их решению. Ведь задача типовая.

Реальность не 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, огромное спасибо, что прямо по полочкам описали варианты.

yesRuslik:
Самые популярные - это failover на базе DNS(когда внешний сервис определяет доступность сервера и меняет А-запись в случае падения на резервный)

Как быстро в данном случае для клиентов будет доступен сайт?

Можете посоветовать какие-нибудь сервисы?

yesRuslik:
HA-кластер, когда переключение происходит не с помощью DNS, а через специализированное ПО типа heartbeat или peacemaker(мы переключали мигрирующий образ виртуальной машины на живую аппаратную ноду)

То есть нужно в одном ДЦ имееть 2 сервера, которые будут на одном IP?

yesRuslik:
простое проксирование запросов на уровне http-протокола на разные бекенды, но тут сложно говорить о HA(high availability), если упадет фронтенд.

Сейчас именно так всё и устроено. Фронтенд иногда падает. Первая мысль была сделать 2 фронтенда, чтобы минимально менять всю систему.

Всего: 722