> Есть ли более изящные способы?
Один вариант привёл Dimm, а другой - использовать nginx. Он может просто сжимать статику на лету, а может в точности делать то, что вы хотите: отдавать сжатые файлы вместо несжатых. (Эта возможность появилось недавно в 0.6.x ветке)
Возможно, дело в High Security (или Privacy) в IE6+. Для того, что IE6+ принимал куки, сервер должен посылать специальный заголовок P3P, содержащий информация, ЗАЧЕМ сервер пытается установить куки.
Заголовок состоит из 2-х полей: policyref - ссылка на xml-файл с подробным описанием и CP (Compact Policy) - тоже самое, но в виде нескольких условных сокращений. Вот это поле IE6+ прямо-таки желает видеть!
В чём +/- такого способа преобразования адресов по сравнению со встроенным в lighttpd? А по сравнению с nginx и mod_rewrite в Apache?
Думается, подгрузка интерпретатора lua при КАЖДОМ запросе, создаст дополнительные нехилые тормоза.
Посмотрите и уберите все лишние модули из Apache, они могут памяти отъедать.
В mod_php память ест memory_limit (как я понимаю, php выделяет себе всю указанную память, но реально использует далеко не всю).
Ещё потребляют память всякие акселераторы/оптимизаторы: н-р, eaccelerator старается положить все данные в shared memory.
Вот в сумме и набегает столько много.
Думаю, "инклюд с двойными кавычками" граздо меньше потребляет, чтобы волноваться из-за него
Встречный вопрос: а используемые ридеры вообще умеют показывать Original enclosure?
Ещё проверьте правильность ссылки на картинку: если в settings.php не указан $base_url, то адрес может быть не полным.
Разве нельзя Апачу отключить ntlm для определённых типов файлов, в данном случае css/js?
Возможно, ещё поможет включение keepalive.
Ну и кеширование и expires
Может-таки вернуть backend на Apache? Собрав с минимумом модулей и отдав авторизации/реврайты/доступы/и т.п. nginx'у. Этот вариант проверен годами и стабилен как скала.
Глюки, значит, локальные, в пределах одного сайта.....
Ограничения на коннекты к БД есть? Сама БД не валится в это время?
Поделись конфигами nginx, PHP и MySQL (в приват)?
Таймауты в PHP тоже достаточные? Памяти хватает? Ограничение по кол-ву одновременных соединений, процессов?
"Connection reset by peer" - это ведь значит, что backend отвалился, а не только nginx'у надоело ждать от него ответа.
Самый минус модуля в том, что он и юзеров и поисковики редиректит на левую страницу. Грамотнее подгружать контент JS'ом в новый слой поверх сайта с предварительной проверкой куков.
Вы хотите выводить заголовки статей? В каком месте сайта?
Можно сделать блок через views и выводить в нём заголовки в виде списка.
Вообще, с точки зрения логики, меню должно представлять из себя _несколько_ пунктов 1-го или 2-х уровней вложенности, остальное - это уже списки материалов и выводить их правильнее отдельно, не трогая меню.
Что-то мне подсказывает, что при такм объёме данных стОит задуматься о хранении пунктов меню в БД (в виде ноды или терминов таксономии в том или ином виде) и выводе при помощи views в нужном месте.
> Есть ли более изящные способы?
Один вариант привёл Dimm, а другой - использовать nginx. Он может просто сжимать статику на лету, а может в точности делать то, что вы хотите: отдавать сжатые файлы вместо несжатых. (Эта возможность появилось недавно в 0.6.x ветке)
node_expire поищите на drupal.org
Возможно, дело в High Security (или Privacy) в IE6+. Для того, что IE6+ принимал куки, сервер должен посылать специальный заголовок P3P, содержащий информация, ЗАЧЕМ сервер пытается установить куки.
Заголовок состоит из 2-х полей: policyref - ссылка на xml-файл с подробным описанием и CP (Compact Policy) - тоже самое, но в виде нескольких условных сокращений. Вот это поле IE6+ прямо-таки желает видеть!
В чём +/- такого способа преобразования адресов по сравнению со встроенным в lighttpd? А по сравнению с nginx и mod_rewrite в Apache?
Думается, подгрузка интерпретатора lua при КАЖДОМ запросе, создаст дополнительные нехилые тормоза.
Лучше всего, я думаю. цеплять фалы так:
Посмотрите и уберите все лишние модули из Apache, они могут памяти отъедать.
В mod_php память ест memory_limit (как я понимаю, php выделяет себе всю указанную память, но реально использует далеко не всю).
Ещё потребляют память всякие акселераторы/оптимизаторы: н-р, eaccelerator старается положить все данные в shared memory.
Вот в сумме и набегает столько много.
Думаю, "инклюд с двойными кавычками" граздо меньше потребляет, чтобы волноваться из-за него
А что даёт USE="mailwrapper"?
Думаю, дело не в nginx'е. Попробуйте полностью отключить кеширование в самом Drupal'е.
Уберите вначале строки #, т.е. раскомментарьте её и впишите правильный адрес сайта.
Встречный вопрос: а используемые ридеры вообще умеют показывать Original enclosure?
Ещё проверьте правильность ссылки на картинку: если в settings.php не указан $base_url, то адрес может быть не полным.
Разве нельзя Апачу отключить ntlm для определённых типов файлов, в данном случае css/js?
Возможно, ещё поможет включение keepalive.
Ну и кеширование и expires
Через panels можно объединить ноду и вид с заводами на странице. А виду через arguments передать ID ноды или термина таксономии.
Примерно так.
panels
RTFM
http://dev.mysql.com/doc/refman/5.0/en/mathematical-functions.html#funct...
Может-таки вернуть backend на Apache?
Собрав с минимумом модулей и отдав авторизации/реврайты/доступы/и т.п. nginx'у. Этот вариант проверен годами и стабилен как скала.
Почти все параметры можн устанавливать на уровне конкретного server, а не только глобального http.
Может быть, webform(s)?
Я бы попробовал так
nginx.conf
Глюки, значит, локальные, в пределах одного сайта.....
Ограничения на коннекты к БД есть? Сама БД не валится в это время?
Поделись конфигами nginx, PHP и MySQL (в приват)?
А что показывает top и netstat во время проблем?
Таймауты в PHP тоже достаточные? Памяти хватает? Ограничение по кол-ву одновременных соединений, процессов?
"Connection reset by peer" - это ведь значит, что backend отвалился, а не только nginx'у надоело ждать от него ответа.
Самый минус модуля в том, что он и юзеров и поисковики редиректит на левую страницу. Грамотнее подгружать контент JS'ом в новый слой поверх сайта с предварительной проверкой куков.
В нужном view ставите галку "Делать блок" (или как там в переводе), а в списке блоков выбираете подходящее место для появившегося блока.
Вы хотите выводить заголовки статей? В каком месте сайта?
Можно сделать блок через views и выводить в нём заголовки в виде списка.
Вообще, с точки зрения логики, меню должно представлять из себя _несколько_ пунктов 1-го или 2-х уровней вложенности, остальное - это уже списки материалов и выводить их правильнее отдельно, не трогая меню.
Что-то мне подсказывает, что при такм объёме данных стОит задуматься о хранении пунктов меню в БД (в виде ноды или терминов таксономии в том или ином виде) и выводе при помощи views в нужном месте.
http://drupal.org/project/drupal_ftp (непонятно живой проект или нет и что он умеет)
Ещё можете поковырять Media Mover, он поддерживает Amazon s3 хранилище: http://drupal.org/project/media_mover
Возможно, это вам поможет