мое решение на коленке за три-четыре дня
естественно не идеал. спасибо за замечания
работаю над кодом
но ини-парсер пока не уберу (гибкий фриендли и мне нравится хоть и на си).
но если подскажешь либу, то буду благодарен (если либа понравится то уберу)
парсер uri буду использовать другой. пока смотрю подходящие либы
ошибка компиляции без него, как впрочем и с dynamic_cast.
это лучше чем приведение в стиле cи (IStorage)
мне надо везде по возможности от него отделаться.
согл, по этому и не стал заморачиваться
а использовал memcachedb
если ко-во переходов очень много, то написать хороший высокопроизводительный стородж, превосходящий по показателям существующие решения будет весьма затруднительно.
магические цифры только в парсере
который использует re2c
возможно надо было использовать другой парсер, но как я указывал где-то в комментариях, мой парсер ищет ошибки конфига.
2) для защиты против этого есть некие стандартные меры,
например по ограничению запросов (в сек) с одного IP
на фронт-сервере
3) маловероятно что ddos будет долбить на какую-то конкретную ссылку проксируемую на этот сервер, обычно ddos валят главную страницу или страницу второго уровня, но ни как ни 4-го или 5-го, тем более даже не страницы, а виртуальные ссылки.
4) непосредственно в биллинге есть ограничения (чтоб клиенты не платизи за ДДОС и роботов):
ведется blacklist IP роботов
нельзя делать более 100 запросов с одного IP (больше не учитывается)
нельзя делать более 3х переходов на один и тот же url в течении суток с одного IP (больше не учитывается). Но эти ограничения стоят на уровне логики обработки данных
можно ввести этот блэклист на уровне логирования. Наверно я так и сделаю.
идея здравая, но
весь смысл в вышеизложенного в переходах
кликаешь на ссылку server/url/key1
и переходишь на сайт site1
кликаешь на ссылку server/url/key2
и переходишь на сайт site2
использую http часть из libevent
первоначально обрабатывается HTTP запрос, потом вызывается кэллбэк (моя обработка ), потом осуществляется пост обработка HTTP, т.е отправка всех заголовков, контента и закрытие соединения.
если делать, как предложили Вы, что вполне логично и немного съэкономило бы ресуров, то пришлось бы изобретать еще один велосипед в виде самописного HTTP сервера, на что ушло бы уйма времени (боюсь оценить сколько).
А так мое решение было разработано за три дня. Правда разработка скрипта на РНР это заняла бы не более дня.
если под это отдать целый сервер, да еще и БД выкинуть на другой сервак, то оно будет так как ты и говоришь. Но, помимо статистики на этом серваке еще крутятся скрипты основного проекта. Нужно было изобрести велосипед эффективное решение, не занимающее много ресурсов.
естественно не идеал. спасибо за замечания
работаю над кодом
но ини-парсер пока не уберу (гибкий фриендли и мне нравится хоть и на си).
но если подскажешь либу, то буду благодарен (если либа понравится то уберу)
парсер uri буду использовать другой. пока смотрю подходящие либы
это лучше чем приведение в стиле cи (IStorage)
мне надо везде по возможности от него отделаться.
но планируется 3-5
спасибо, так и сделаю
каждая цель — это позиция товара,
переход на сайт партнера
позиций от 3 млн
а использовал memcachedb
если ко-во переходов очень много, то написать хороший высокопроизводительный стородж, превосходящий по показателям существующие решения будет весьма затруднительно.
который использует re2c
возможно надо было использовать другой парсер, но как я указывал где-то в комментариях, мой парсер ищет ошибки конфига.
согласен
2) для защиты против этого есть некие стандартные меры,
например по ограничению запросов (в сек) с одного IP
на фронт-сервере
3) маловероятно что ddos будет долбить на какую-то конкретную ссылку проксируемую на этот сервер, обычно ddos валят главную страницу или страницу второго уровня, но ни как ни 4-го или 5-го, тем более даже не страницы, а виртуальные ссылки.
4) непосредственно в биллинге есть ограничения (чтоб клиенты не платизи за ДДОС и роботов):
ведется blacklist IP роботов
нельзя делать более 100 запросов с одного IP (больше не учитывается)
нельзя делать более 3х переходов на один и тот же url в течении суток с одного IP (больше не учитывается). Но эти ограничения стоят на уровне логики обработки данных
можно ввести этот блэклист на уровне логирования. Наверно я так и сделаю.
весь смысл в вышеизложенного в переходах
кликаешь на ссылку server/url/key1
и переходишь на сайт site1
кликаешь на ссылку server/url/key2
и переходишь на сайт site2
первоначально обрабатывается HTTP запрос, потом вызывается кэллбэк (моя обработка ), потом осуществляется пост обработка HTTP, т.е отправка всех заголовков, контента и закрытие соединения.
если делать, как предложили Вы, что вполне логично и немного съэкономило бы ресуров, то пришлось бы изобретать еще один велосипед в виде самописного HTTP сервера, на что ушло бы уйма времени (боюсь оценить сколько).
А так мое решение было разработано за три дня. Правда разработка скрипта на РНР это заняла бы не более дня.
велосипедэффективное решение, не занимающее много ресурсов.у меня предполагается 3-5 млн
по этому не хотелось бы все пихать в мемкеш
меня не устроило
но принципиально согласен, зачем изобретать велосипеды,
если можно заюзать уже испытанные либы.
времени потратишь меньше.