использовать модуль Net::Socket::NonBlock или подобный, который позволит одновременно вести загрузкув 16,32,64 потока
So1: Текстовый файл работает быстрей SQL?
Да, значительно. Только нужно грамотно с ним работать. При объеме до 30-40Мб (Perl 5.10) он значительно быстрее MySQL, при этом мение ресурсозатратен.
Стараюсь нигде SQL не юзать. Медленно, грамоздко и очень много ограничений.
Не забывайте, что Perl, в самом начале, был создан тольок для парсинга/структурирования текста
So1: И все же вопрос остался - есть ли ограничения на длину сессии?
Зачем в этой ситуации сесии вобще.
1. получили рсс, пропарсили и оставили лежать в виде результирующих файлов-файла.
2. Повторно читаем рсс ленту тольок по истечении времени ее актуальности или тупо каждый 10-20-30-60 минут. До это времени отдаем из сохранения.
So1: C++, Perl, Python, TCL?
то, что быстрее работает на серваке и иметт необходимые модули
T.R.O.N добавил 11.11.2008 в 13:12
neolord: Время доступа к текстовому файлу в разы больше чем к БД, поэтому для хранения _уже упорядоченных_ данных (когда не нужно делать сложные отсевы или они делаются простым смещением бегунка чтения), это идеальный вариант.
Вы можете это доказать? Есть хоть какие-то тексты не из учебников?????
нет. Вернее, далеко не всегда. Ведь что такое тег <object> по своей сути. В этом месте создается окно управление которым передается внешнему обработчику (ActiveX). Очень часто, кроме вывода в это окно, еще передается и право на получение любых вводных данных из него. А значит, по сути, любой клик мыши, как событие, будет передано ActiveX, а IE или кто-то другой, получит это событие ТОЛЬКО если первый обрабочки его ретранслирует.
Тем более что поведение встроенных элементов в разных броизерах сильно отличается.
stalker37: Насколько я понял что он должен был либо что-то упереть с сайта, либо что-то добавить. Но что? Интересны Ваши мнения на этот счет.
Если сервер настроен правильно и в Вашем скрипте идет нормальная обработка GET запроса - ничего и никогда не произойдет. Скорее всего это стандартная дыра в како-то кривой CMS
нужно. Это будет быстрее. Но Еще быстрее все будет происходить, если отказаться от PHP. Используйте любой настоящий CGI - Perl/TCL/Phyton.
При этом, еще использовать "ручную" загрузку самих лент. Это позволит вести паралельную обработку. Разделенные процессы очень сильно ускоряют программу.
So1: Хранить всё это дело в БД не выгодно.
Очень выгодно. Просто не нужно использовать SQL. Текстовый файл - это тоже БД.
Евгения Бахвалова: Вопрос номер два. Научите правильно покупать ссылки.
1. не пользоваться помойками(сапой и прочим)
2. покупать ссылки "ручками", желательно у тех кто поддерживает нормальный сайты и которых можно найти по телефонам или фирмы-владельца или фирмы-разработчика.
3. взяв ссылки, 20 раз подумать и только после этого сделать анкор. После, постараться, максимально долго егео не менять.
4. участвуйте во всем, что может быть тематическое для Вас. (обзоры, топы, каталоги и пр.)
Евгения Бахвалова: Как вернуть позиции и нормальную индексацию?
Выше уже все сказано.
PS Я понимаю, Использовать стандатртные магазины, - быстро и дешево. Но сейчас, конечно на мой взгляд, магазин напоминает результат курсой работы 2-3 курса эконом факультета.
Ситуация имеено с этим сайтом тем интересней, что сейчас по москве появилось большое количество щитов именно этой кнторы. Понимаю, со щитами все просто... но. Может яша всетаки как-то прокоментирует такой вариант подсказки.
аналогичные "подсказки" есть при запросе ваз, камаз, бмв, мтс. Интересная подсказка по запросу волга.
По 2-х и далее словным запросам - не заметил подобного
Что за "ручная загрузка самих лент"?
использовать модуль Net::Socket::NonBlock или подобный, который позволит одновременно вести загрузкув 16,32,64 потока
Текстовый файл работает быстрей SQL?
Да, значительно. Только нужно грамотно с ним работать. При объеме до 30-40Мб (Perl 5.10) он значительно быстрее MySQL, при этом мение ресурсозатратен.
Стараюсь нигде SQL не юзать. Медленно, грамоздко и очень много ограничений.
Не забывайте, что Perl, в самом начале, был создан тольок для парсинга/структурирования текста
И все же вопрос остался - есть ли ограничения на длину сессии?
Зачем в этой ситуации сесии вобще.
1. получили рсс, пропарсили и оставили лежать в виде результирующих файлов-файла.
2. Повторно читаем рсс ленту тольок по истечении времени ее актуальности или тупо каждый 10-20-30-60 минут. До это времени отдаем из сохранения.
C++, Perl, Python, TCL?
то, что быстрее работает на серваке и иметт необходимые модули
T.R.O.N добавил 11.11.2008 в 13:12
Время доступа к текстовому файлу в разы больше чем к БД, поэтому для хранения _уже упорядоченных_ данных (когда не нужно делать сложные отсевы или они делаются простым смещением бегунка чтения), это идеальный вариант.
Вы можете это доказать? Есть хоть какие-то тексты не из учебников?????
не катит разве?
нет. Вернее, далеко не всегда. Ведь что такое тег <object> по своей сути. В этом месте создается окно управление которым передается внешнему обработчику (ActiveX). Очень часто, кроме вывода в это окно, еще передается и право на получение любых вводных данных из него. А значит, по сути, любой клик мыши, как событие, будет передано ActiveX, а IE или кто-то другой, получит это событие ТОЛЬКО если первый обрабочки его ретранслирует.
Тем более что поведение встроенных элементов в разных броизерах сильно отличается.
Насколько я понял что он должен был либо что-то упереть с сайта, либо что-то добавить. Но что? Интересны Ваши мнения на этот счет.
Если сервер настроен правильно и в Вашем скрипте идет нормальная обработка GET запроса - ничего и никогда не произойдет. Скорее всего это стандартная дыра в како-то кривой CMS
Может быть парсить "вручную"?
нужно. Это будет быстрее. Но Еще быстрее все будет происходить, если отказаться от PHP. Используйте любой настоящий CGI - Perl/TCL/Phyton.
При этом, еще использовать "ручную" загрузку самих лент. Это позволит вести паралельную обработку. Разделенные процессы очень сильно ускоряют программу.
Хранить всё это дело в БД не выгодно.
Очень выгодно. Просто не нужно использовать SQL. Текстовый файл - это тоже БД.
Televizor,
Что мешает сделать обычным редиректом? Зачем мучать htaccess или подобное?
Просто в провереш переменную окружения REMOTE_ADDR и принимаеш решение о переадресации
типа этого http://www.realmusic.ru/songs/463565
там какраз flash используется
T.R.O.N, а можно совет по юзанью и настройке этого дела?
Объект имеет много настроек и вариантов
На самом деле есть очень много плюсов как для флеша так и для MediaPlayer. Просто нужно на чем-то остановится.
Хотелось бы хранить при этом видео на своем сервере.
Если такое пользовать, то очень бы рекомендовал использовать WMV. Их плагин/activeX установлен дефалтово (особенно если не мкдрить с новыми плеерами)
А Квик-тайм нужно устанавливать (если конечно работете не под MAC)
Вопрос номер два. Научите правильно покупать ссылки.
1. не пользоваться помойками(сапой и прочим)
2. покупать ссылки "ручками", желательно у тех кто поддерживает нормальный сайты и которых можно найти по телефонам или фирмы-владельца или фирмы-разработчика.
3. взяв ссылки, 20 раз подумать и только после этого сделать анкор. После, постараться, максимально долго егео не менять.
4. участвуйте во всем, что может быть тематическое для Вас. (обзоры, топы, каталоги и пр.)
Как вернуть позиции и нормальную индексацию?
Выше уже все сказано.
PS Я понимаю, Использовать стандатртные магазины, - быстро и дешево. Но сейчас, конечно на мой взгляд, магазин напоминает результат курсой работы 2-3 курса эконом факультета.
semenov, Бред написала. Подсказка ведет на сайт а не на поиск.
Ситуация имеено с этим сайтом тем интересней, что сейчас по москве появилось большое количество щитов именно этой кнторы. Понимаю, со щитами все просто... но. Может яша всетаки как-то прокоментирует такой вариант подсказки.
аналогичные "подсказки" есть при запросе ваз, камаз, бмв, мтс. Интересная подсказка по запросу волга.
По 2-х и далее словным запросам - не заметил подобного