В бета-версиях Windows 3.1 был скрытый и зашифрованный код, который при запуске на DR-DOS выдавал непонятное сообщение о вымышленной ошибке.

В релизе решили подобными фокусами не заниматься, но код проверок и само сообщение не убрали: они так и остались внутри WIN.COM, и достаточно изменить один байт, чтобы AARD-код снова выполнялся при каждом запуске.

Зачем его оставили? Неужели Microsoft рассчитывала однажды в будущем разблокировать эти сомнительные проверки?
Конечно же, нет. Даже сообщение в релизе осталось неизменённое: «Please contact Windows 3.1 beta support.» Если бы сообщение действительно предназначалось для показа, после окончания бета-тестирования его бы обновили.

Так зачем оставлять в релизе бессмысленный код, который никогда не выполняется?

Данная статья достаточно подробно показывает, как можно перейти на разработку сайтов Друпал с серьезной стрессоустойчивостью и возможностью обрабатывать большой трафик.

Это мой первый опыт подобной настройки, но как будет далее видно из статистики достаточно удачно справляющийся со своей основной задачей — ускорением работы сайта. Интересно будет услышать и увидеть настройки, дополнительные материалы от всех кто сталкивался с подобными задачами, так как в рунете пока еще мало свободной и качественной информации по этой теме относительно системы Друпал.

Довольно долго для разработки я использовал связку Drupal + Nginx с настройками сервера по умолчанию:

server {
listen 62.xxx.xx.xx:80;
server_name mysite.com www.mysite.com;
rewrite>^(/manager/.*)$>https://$host$1>permanent;
location ~* ^/(webstat/|awstats|webmail/|myadmin/|manimg/) {
proxy_pass 62.xxx.xx.xx:8080;
proxy_redirect mysite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location / {
proxy_pass mysite.com:8080;
proxy_redirect mysite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar)$ {
root /home/pathto/drupal613;
access_log /home/httpd-logs/mysite.com.access.log;
error_page 404 = @fallback;
}
location @fallback {
proxy_pass 62.xxx.xx.xx:8080;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
}

Недавно я столкнулся с тем, что мой сайт на Drupal стал тормозить. Причем, сайт не особо то и посещаемый. В конечном счете, проблема решилась переходом на другой хостинг (shared-хостинг от Руцентра не выдерживал никак), но рассказать я хочу не об этом, а о проблемах ускорения Drupal путем кэширования, с которыми я столкнулся.

Итак, какое инструменты для ускорения существуют на Drupal?

Как известно, Drupal является примером крайне тяжелой CMS/CMF, и нагруженные сайты строить на нем не так просто. Поскольку моя компания использует в своей разработке преимущественно Drupal — нам иногда приходится сталкиваться с оптимизацией производительности, и я бы хотел рассказать о том, как мы справляемся с нагрузкой.

В этой статье я рассмотрю один из самых эффективных методов повышения производительности — кэширование веб-сервером nginx контента для анонимных пользователей. Благодаря этому приему запросы от анонимных пользователей не вызывают обращения к бекэнду(не важно какому — apache или fastcgi). Таким образом, такое кэширование эффективнее любых средств CMS.

На хабре недавно была опубликована статья под названием "Кэширование на Drupal". Хотелось бы добавить несколько соображений по теме.

Ни для кого не секрет, что Drupal голоден до ресурсов, а кэширование это чуть ли не первое что приходит в голову. Расскажу как выстроена общая схема кэширования на нашем сайте.

Первая линия обороны — мы используем CDN (Content Delivery Network), в нашем случае это AKAMAI. AKAMAI настроен на кэширование всего. Картинки, CSS, JavaScript, ответы на все GET запросы, все это кешируется в не зависимости от того аноним пользователь или зарегистрирован. Интервал кэширования от 1 до 5 минут для страниц, 45 минут для CSS и JavaScript, и час для остальных ресурсов. Такое распределение позволяет существенно уменьшить нагрузку на сервера.