Алеандр

Алеандр
Рейтинг
207
Регистрация
08.12.2010
141c18

Да-да, а потом окажется, что при выборке "wanna on bitch" и "wanna on beatch", при разнице всего в пару букв, фразы имеют слишком разное значение и не могут быть исключены из списка сравнения )) А еще, поскольку мы сравниваем все же ключи и разные комбинации при одинаковой лемме могут быть важны, то как откидывать? Например, при сравнении "смотреть из окна" и "смотреть в окно" - лемма будет идентична, поскольку, обычно, междометия, частицы, местоимения и т.д. откидываются для упрощения. Проверить, кстати, проще простого. Вбиваем в яшу "смотреть в окно" и "смотреть в окна" и получаем разную выдачу, хотя лемма одинакова, да и разница всего в эту самую 1 букву, даже откидывать ничего не нужно. Получается, что ни морфология, ни простой перебор в лоб - не помогут в данной задаче.

timo-71 #:
Слова в нормальную форму, фразу сортируем и ид для ключа готов.

Кому-то и 2x2 сложно. Это уже не regexp, в любом случае потребует минимума знаний программирования, составления алгоритма обхода всех строк, построчных сравнений, принятия решения по точности. Для пыхи дали выше пример, еще проще. Но, это лишь в том случае, если погрешностями в расчетах можно пренебречь и точность исходящих строк не сильно важна, а язык и его особенности не существенны. Тогда да, проще, соглашусь.

iccup #:

да ключи перебираю, встречаются такие строки, например -

Если это все разные фразы, разные ключи и, собственно, разница между ними не известна, то только сложный алгоритм построчного сравнения с просчетом % совпадения и смешения. Тогда можно будет отсортировать те строки, которые похожи друг на друга до определенной степени.

PlainTeXT #:

А как же вот это?

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

PlainTeXT #:

В правилах они пишут: " Издателям не следует использовать макеты сайта, в которых при загрузке объявлений контент оказывается за пределами экрана. На таких страницах пользователям трудно различить содержание и рекламу."

Не следует - это не значит, что запрещено. Почти на любом контентном сайте, одно из самых доходных мест - как раз верхнее, до или сразу после h1. Так что, такое размещение рекламы - много где, странно, что вас это так удивляет.

Обычно делаю так: старый материал перевожу в html версию и фиксирую, чтобы не терять url, позиции, возможный трафик и перелинковку. А к старому добавляю движок с другими путями, чтобы не пересекались и уже на нем спокойно можно публиковать новые материалы. https и адаптив для старых страниц делается несложно, переезд, обычно, проблем не составляет. По итогу: нет потерь линковки, остатков трафика и старых трастовых материалов, при этом есть новый удобный движок для новых материалов и все обновлено. А дальше, при желании, можно переработать старые html-страницы, если есть что поправлять или уникализировать. Применял такой подход несколько раз на практике - самый оптимальный. Но мне проще, я сам себе админ и программер, потому спокойно собираю 2 в 1, а вам придется платить за такое сращение.
WebDataSearch #:
Пошёл в обратную, поставил 3, и всё вернулось к адекватным показателям.

Сделаю предположение, что у вас неверно настроена конфигурация prefork модуля, в частности - серьезно ограничено количество стартовых серверов апача и количество их дочерних процессов, которое, в свою очередь, не соответствует памяти, выделенной сервером.

Грубо говоря, например, если разрешено иметь 10 инстансов апача, то когда вы упираетесь в это значение на сервере, то остальные входящие юзеры ждут, пока предыдущие юзеры отключатся. Уменьшая keepalive вы принудительно быстрее завершаете висящих юзеров и ваш коннект получает свободное окошко в виде разрешенного инстанса апача.

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

В таком случае - простое решение: проверить настройку prefork, увеличить количество стартовых серверов и разрешить большее количество запущенных инстансов апача. Если же количество допустимых инстансов уже на пределе свободной памяти сервера - поднимать оперативку сервера и поднимать разрешенное количество инстансов.

ЗЫ: перечитал тему, Евгений выше все тоже самое и сказал. Копайте в эту сторону, раз изменение keepalive так существенно влияет на работу сайта.

WebDataSearch :

Добрый день.

Спасибо за внимание к теме.

Сайт не попал в задерживание трафика, как недавно было с твиттером? Могло зацепить. Это первое.
И второе, в последнее время довольно часто наблюдаю на сайтах проблемы с резолвингом IP, когда NS сервера крайне долго отдают или вообще не отдают IP адрес сайта. С регистратором имени и его NS-серверами проблем нет? Буквально на днях пришлось клиенту менять NS в силу того, что хостинговые жутко глючили, при этом все шли в отказ, что проблема не их. Поменяли NS и порядок. Может у вас такая же беда, слишком долгий запрос к NS, потом данные падают в кэш и проблем нет. Перестали обращаться - кэш ушел и снова долгий первый запрос. Стоит проверить.

-= Serafim =- #:

Они имеют ввиду, чтобы ты платил налоги и показал им документы, что ты их платишь.

Так даже, если они платятся, например, ТС получает доход от РСЯ и оплачивает потом налог - это коммерческая деятельность? Тогда не важно, платит он с нее налог или нет - правилами она запрещена. Наверное, это все же другое. Даже больше, как раз наоборот, если ТС платит с этого налог, то по сути он этим и подтверждает, что это предпринимательская деятельность, которая их правилами на кошельках запрещена.

В целом даже просто интересно, как так получается, что РСЯ можно вывести на Юмани, но при этом у Юмани возникают вопросы происхождения этих средств, исходя из стартпоста.

Не совсем понятно, что подразумевается под "коммерческой деятельностью". Ну, сам смысл термина известен, но, что под ним подразумевают в Юмани? Мне кажется, что юмани как раз используют для вывода из тех же РСЯ, партнерок и тд, по сути это ведь как раз коммерческая деятельность. Или же они имеют ввиду, чтобы это не было приемом платежей за товары. Т.е. кто-то продает постоянно, ну, не знаю, духи паленые, а деньги получаются на юмани. Тогда да, это левая деятельность, за что атата. Ибо за партнерки, по-моему, уже стольким бы прилетело - мало бы не показалось. Сам принцип электронных денег в получении на них некоторых сумм дохода, с того же РСЯ, которые потом можно использовать на приобретение товаров и услуг. А иначе какой смысл пополнять юмани собственными средствами, чтобы потом с них оплатить хостинг, при том, что хостинг в тех же условиях можно оплатить просто картой или другими вариантами напрямую, минуя дополнительные расходы юмани как посредника.

Скорее всего под подозрения могут попадать кошельки, по которым идут постоянно какие-то фиксированные суммы, похожие на торговлю товарами. Других причин не вижу. Но, тогда достаточно доказать, что эти доходы шли не от левой торговли, а реально это РСЯ или что там еще.

Всего: 1467