Да, очень маленький, всего 200 в сутки был. Потом кажется до 1000 подняли. Суть в том, что при таких условиях программы для определения позиций технически можно писать (без регистрации ИП, чтобы любой пользователь мог ставить без дополнительных ударов в бубен) только путем разбора HTML кода страниц. Что достаточного невыгодно самому же яндексу, т.к. как мне кажется грамотное приложение с умным алгоритмом поиска позиции создало бы на сервера меньше нагрузки чем тупая эмуляция действий пользователя. Хотя, при таком количестве запросов эта разница в нагрузке что слону дробина.
Я имел в виду site-auditor. Судя по снифферу он работает не по XML шлюзу (если я спросонья ничего не путаю). Точно помню, что я удивился что они даже gzip при получении данных для ускорения работы не используют, простая линейная реализация.
В зависимости от реализации. На том уровне о котором мы говорим (вывод страницы средствами веб-сервера, генерация данных - веб приложением) таким образом Вы буфер отправки не переполните. Напишите такой скрипт, покажите что буфер переполняется и скрипт тормозится отправкой данных, тогда будем спорить дальше.
Исходя из ваших утверждений получается что медленный клиент (например на модеме 1200 бод - у меня есть такой в коллекции) может очень нехило притормозить серверную процедуру? Тогда это была бы вешалка для любого хостинга.
На кластере, само собой. Что никак не умаляет сложности задачи, решаемой группой разработки в то время, думаю Вы понимаете.
RFC то не ограничивает, но ограничивают браузеры и сервера, которые запросы отрабатывают. Эксплорер и IIS ограничиваются 250-260 символами (подробно тут: https://www.microsoft.com/rus/technet/columns/iisdecspec.mspx). Поэтому если URL длинный - добавлять его в Гугл бессмысленно, браузеры могут не понять в большинстве своем.
По логике вещей длинные параметры нужно через POST передавать, а не через GET. Есть ли возможность перейти на POST? Если нет - нужно искать другие способы уменьшить размер URL.
А что у вас там, если не секрет?
Да, это то понятно, я просто имел в виду что "отсюда логично предположить, что..."
Вообще, мне идея бана целого хостинга таким путем изначально понравилась новизной :).
Немного по теме, но не совсем - я тут спрашивал у саппорта Я считаются ли приложения по определению позиций в поисковиках нарушителями лицензии? Говорят "да, если не зарегистрирован IP пользователя". Причем я уточнял - это только для тех кто XML выдачу юзает, или для парсеров страниц тоже? Говорят для всех вообще.
Так что Ашмановский определитель и другие программы подобного плана вне закона, вообще-то :).
maxlength=N в форме всего лишь указание браузеру не давать вбить более N символов в поле ввода, обойти его посылкой данных напрямую можно. А вот получится ли искомый результат - это зависит от логики работы скрипта на серверной стороне. Если в скрипте программист при получении данных сделал ограничение, то нет.
Думаю, такое ограничение должно там быть с высокой вероятностью.
EMBED это тэг для вставки объектов ActiveX, он сам ничего не проигрывает. Поэтому параметры, о которых Вы спрашиваете - это параметры конкретного проигрывателя, который Вы подключаете. Для того чтобы знать как им управлять - нужно знать что за проигрыватель, поэтому приведите используемый код полностью.
Точных данных нет, но вообще архитектурно и логически это должны быть совершенно разные сервисы и база их IP-банов не должна никак пересекаться совершенно. Ведь запросы к сервисам Я не обязательно с сайтов, даже скорее наоборот идут. Иначе как мне кажется все хостинги виртуальные давно бы в такой "бан" попали со своими сайтами.
Да, роботы то все равно на IP ходят даже если сайт в бане, насколько я понимаю из общения тут на форуме. А бан наступает не по IP а по имени домена. Так что я на 99% уверен, что опасаться нечего.
Мишган, Вы забываете, что буфер между приложением и сокетом есть всегда что при буферизированном что при небуферизированном выводе.
Попробуйте хотя бы себе объяснить, каким же интересно образом приложение будет медленнее генерировать код, если канал занят? С помощью какого интересно механизма будет медленнее или быстрее работать PHP (или любой другой язык взять) код, или код хранимой процедуры или SQL запроса в зависимости от занятости канала? Что, есть какие-то специальные каналы для посылки от стека TCP/IP в программу команд типа "а ну ка помедленнее, братишка, я печатать в сокет не успеваю"?
Короче, возьмите напишите себе программу и посмотрите как она работает, чего вы меня убедить пытаетесь в своих заблуждениях? Я все это 7 лет назад на практике прошел когда мы делали баннерную крутилку с производительностью на 6 миллионов показов в час.
В общем думайте что хотите, это ваше дело. Мне что ли страдать от применения подобных "знаний"...
Вы объясните что Вы делаете людям, а потом совет спрашивайте. Вы код привели? Я вам дал ссылку на профайлер, если Вы им пользовались - что он Вам показал? Где план Вашего тестирования, то есть что именно Вы исследуете и какой результат хотите получить? Извините меня, конечно, но мне кажется что Вы подходите к серьезному вопросу бессистемно, а все приведенные в топике советы попросту игнорируете.
Читая обрывочные сведения в этом топике я могу предположить, что Вы добавляете в страницу не HTML код, как Вы говорите, а Вы пробуете выводить разное количество каких блоков на странице которые берутся вероятно из базы. Естественно СЛЕДСТВИЕМ этого является увеличение количества HTML кода. Естественно и то, что при выводе 3 блоков и 5 блоков с данными из базы на странице у вас могут увеличиваться затраты на выборку данных из базы или затраты на обработку данных (в слове бизнес-логики). Это зависит уже от архитектуры приложения. Если это так, что удивляться, что приложение дольше работает при выводе 5 блоков в отличие от 3 нет смысла - это естественно. Нужно брать каждый блок вывода и смотреть - сколько времени он работает и почему.
Если я в предположениях ошибаюсь - извините, сами ничего толком не пишете.
