Каталог яндекса я вляется некомерчиским рессурсом, предоставляющим бесплатный сревис пользователям сети. Его деятельность(как каталога) не регулируется никакмим действующими законами.
не устраивает, ставьте бан на бота, который простукивает сайта из каталога и сайт исчезнет из него.
Я бы выбрал вариант такой. Если при прочих равных, есть возможность придерживаться тематичности - то это стоит делать. Но как самоцель - не ставить
diverck, claygod,
очень странные рассуждения. если честно
50 000 уников в сутки. Пусть каждый смотрит по 3 страницы. Получается 150 000 стриц в сутки ~ 100 стриц в минуту. Пусть еще столько-же сжирают роботы. Это крошечгая нагрузка, конечно если CMS не пользовать а делать нормальную систему управления сайтом. Вы главное смотрите чтобы канал выдержал.
обсуждалось не раз - правда. Вот тольок доказательств то нет. Вернее так, процент подтверждений соответсвует нормальному распределению.
а для Вас новинка, что из-под него идет выполнеие иначе?
Вы слушаете только то, что хотите услышать. Я утверждал что есть задачи, где монстр типа SQL сервера нужен и оправдан. Решение без него - затруднительны. В приведенном примере, в большинстве веб-приложений и CMS использвать базы не удобно и ведет к очень серьезным "тормозам".
Решения, с использованием mySQL, входят в любой учебник по пхп. При этом, они рассмотрены как примеры, а не как готовые интересные решения. Вот их и юзают все кому не лень.
Любое универсальное/стандатроное решение (тот же SQL) все проигрывает перед ускоспециализированным. Еще раз повторюсь, и для него есть задачи, но обсуждаемые здесь к ним не относятся
поверьте, - это очень просто. Просто стоит вопрос, что вы считаете файлами и что базами. Нагрузка на сервер от SQL сервера становится оправданной, если объем обрабатываемых файлов значительно больше свободного ОЗУ и нет необходимости вести полнотекстовый поиск.
Да тут я с вами и не спорю. Просто Вы пытаетесь сравнить 2 решения, которые в такм виде не сравниваются. Типичный пример, как Вы думаете, за счет чего серверный скрипт исполняется настольок быстро? Надеюсь Вы не думаете что он исполняется обработчиком как интерпритатором.
Там используется, промежуточный, некоторые его называют P-code.
Так почему-же Вы сравниваете подготовленную файловую БД и простой неподготовленный текстовый файл? Кто мешает его подготовить, возможно разбит на фрагменты, в момент импорта данных на сервер?
neolord, внимания Вам не занимать. Без обид.
БАза защищена лишь тем что кней нет доступа по HTTP. Зачем же файлы выкладывать так, чтобы их из HTTP можно было достать?
очень ошибаетесь. Очень! Хотябы из-за того что пхп работает по технологии ASP, правда у него чуть удобней реализованы библиотеки.
я же говорил, что не стоит пользоваться "решением в лоб"
если говорить о веб-скриптах - да, я считаю, что более удоного чем перл пока не появилось. Возможно - появится.
Вы сами в это верите? Вы считаете что база спрятанная за mySQL/MSSQL пленочкой - безопасно. Боже. Полный смех.
приезжайте, на самом деле. Покажу. И не только инет магазин. И еще много другого.
да, здесь этот сайт уже показывал, могу показать и еще раз. http://redday.ru
И еще, если вопрос поиска в не БД вариантах для вас сводится к стандартным пхп функциям - безусловно. Очень геморно и прочее.
Засекал и не разю Именно это и указал. Пока файл небольшой.. по идее до 64М - файло быстрее. Естествеено если используется Perl CGI и перед работой "влоб" была сделана минимальная удобная разметка.
Если стоит вопрос о многопараметровом поиске - да, скорее всего SQL быстрее. Если же простое чтнеи, а при этом, если используются дампы памяти - обычный файл быстрее.
Ну а если говорить об использовании БД в CMS - так это классический пример нежелания людьми пользоваться головой или "жгучее" желание пользовать рекомендации PHP.
штука суперская. И комода - тоже. Обратите внимание на такую славную штуку MLDBM 'DB_File'. Более быстрых способов доступа к небольшим массивам данных, на мой вгляд, просто нет. Прямой дамп памяти с переменными.
Ну самоучки у нас почти все, но и там бывают очень интересные штуки. Так вот. Еще одно замечание. Погоняйте свой метод при 10-100-1000 запросов в секунду. Почствуете разницу.
http://activestate.com/index.mhtml именно его и пользую, как софт.
http://webscript.ru/stories.php3?topic=5
поверьте, в гугле, как и яше - все достатчно просто. Все алгоритмы, как правло, - линейные. А значит имеют максимальную скорость исполнения. Все что может быть расчитано зарание - расчитано, и сохранено в виде дампов памяти переменных (кажется это называется бадзами Баркли/Барклая). Это самый быстрый способ хранения данных, но требует большие объемы памяти. Пердварительные данные готовятся другими серверами.
So1, У вас сейчас скрипт делает все последовательно, поэтому время складывается. А можно попытаться разделить все процессы.
Возможно даже построение псевдо клиент-сервер.
Т.е. бинарник(ведь он всегда быстрее работает, да и запушен не под web-сервером, что еще увеличивает скорость), на том-же си или делфе запущен и постоянно анализирует запрос к себе(появление файла или пайпа или еще чегонить). Получает этот сигнал, выполняет запрос к ленте и складывает результат.
А у серверного скрипта задача очень простая - дал запрос бинарнику - получил ответ - объединил начало страницы результат и конец.
T.R.O.N добавил 11.11.2008 в 14:31
а Вы понимаете, почему именно он этого не делает? Или Вы считаете что это связано только со скоростью обработки?
