И не надо.
Нет ничего глупее сравнения по скорости работы пачки совершенно разношёрстных систем. С героическими криками "Я работаю на самой быстрой ЦМС Вордпресс!!!" в последствии. Ламерство ппц.
Да, Джумла тяжёлая. Но, простите, а что вы хотели от системы с MVC, компонентной структурой, модульностью, внутренней системой events? Чтобы она работала со скоростью plain html? Или хотя бы как блогодвиг Вордпресс, который на статус полновесной ЦМС никогда и претендовал?
Мерять качество ЦМС по количеству запросов к БД - это ламерство, исходящее от людей, которые ничего не понимают в устройстве ЦМС, но которым крайне хочется поумничать.
Если Вы выбрали под свой проект, исходя из каких-то критериев, Джумлу, то значит надо работать с Джумлой. Знать специфику системы, уметь "выбрасывать лишнее" при заточке системы под конкретный проект, знать узкие места, знать как настроить сервер конкретно под Джумлу. Надо понимать, что кеширование - это неотъемлимая часть любой высоконагруженной системы на любой платформе и соответственно грамотно его использовать исходя из средств, предоставляемых Джумлой. А крики, что под проект с нагрузкой в 20 килохостов надо писать свою двиг - это ламерство.
По теме. Ребята из Webo оптимизируют загрузку Яваскриптов и ЦСС. Это _никак_ не влияет на скорость генерации страницы сервером. В комплексе, конечно, надо решать и вопрос скорости рендеринга страницы браузером. Но конкретно под Вашу задачу в первую очередь надо ускорять серверную часть. Настройка сервера + кеширование + обкусывание лишнего из ядра системы + профилирование кода + оптимизация запросов под конкретный проект. Как? Ищите специалиста по Джумле хотя бы с пятилетним стажем и опытом работы с крупными проектами. Да, это дорого. Но бесплатно можно получить разве что псевдо-программиста, который разговор начнёт с криков "Джумла гавно! Да я твой проект на Вордпресе за два дня подниму!". Тут уж каждый волен выбирать по своим предпочтениям и финансовым возможностям.
Жесть... Наша песня хороша, запевай с начала.
Ещё раз: memcached. Что смущает? Непонимание, как это будет работать в целом? Если у Вас планируется 1 лям хитов в сутки и Вы не знаете как делать сайты - закажите у профессионалов и не морочьте людям головы. Если чисто теоретический интерес, то Вы уже получили достаточно информации, чтобы рыть по заданным направлениям глубже и экспериметировать, экспериметровать, экспериментировать. Удачи.
Проблемы в религиозных различиях :)
А те, у кого с толерантностью всё нормально, берут наиболее подходящий двиг/фрэймвёк под конкретную задачу, затачивают его и зарабатывают вечно зелёных президентов. И в холиварах типа "Джумла - гавно, ДЛЕ - круто" участвуют разве что поржать. :)
Аааа... Понятно.
Можно нескромный вопрос? :)
Что это за бесценная информация такая?
Жесть...
На Пентагон работаете? :)
Кстати, по поводу картинки... Это "заапргредженная версия" простой сессии которую я предлагал. И в принципе, если подобрать хороший алгоритм формирования капчи, то поломать её будет довольно трудоёмким делом. Если ещё и "хороший алгоритм" разбавить чем-то своим, чтобы его не смогли поломать готовые капча-парсеры, то вообще замечательно будет.
Santyago добавил 12.02.2010 в 19:01
Снифер не поможет, если капчу придётся раскалывать.
И исходя из этой архитектуры максимум что можно сделать - это защиту через сессии.
"Защиту от дурака" реализовать и в большинстве случаев этого будет достаточно.
Потому что 100% защиту ты не сделаешь никогда. Поставив перед собой цель, из твоего сайта всё равно можно будет вытянуть что-угодно через Curl + листинг анонимных проксиков.
Лично я недавеча парсил выдачу одного из сервисов Гугли, который, конечно же, очень неплохо защищён от этого. И ничего... Чихнул пару раз от возмущения и всё отдал. )))
Поэтому всегда должен быть разумный компромисс между затратами на защиту и стоимостью защищаемых данных. Это - главное. 100% защитить можно только выдернув из сервака сетевой кабель.
Нету. Мы все умрём.
))))))))))) Пять!
Люди, читавшие RFC1945, взломают что-угодно )))))
Судя по этому
$.ajax({ type: "POST", url: "2.php"+data, dataType: "xml", success: parseXml }); });
Таки вызывается из браузера и задача как раз в том, чтобы запретить прямые вызовы без захода на страницу сайта. Если не прав - тоже поправьте... :)
Гм... А кофе заварить?.. :D
