Есть более правильное решение - выполнять долгие процессы не в контексте веб сервера, разделяя интерфейс постановки задачи и её выполнения.
Например, ставить задачи через веб интерфейс, а выполнять в скрипте запускаемом кроном.
Если надо получать обратную связь, можно периодически записывать процесс выполнения в какое-нибудь хранилище (файл, база, key-value), и отображать его на стороне клиента, делая периодические ajax запросы.
Такого решения сколько-нибудь универсального не существует.
Почему вы уверены, что DLE будет производительнее и лучше?
По мне, так и то, и другое далеко от идеала, но DLE (если не рассматривать левые модули джумлы, не понятно как и кем написанные), будет куда печальнее - он просто образец кривости и дырявости.
Куда легче, включить логирование медленных запросов mysql, найти причину, если она вообще там, и её поправить, чем сделать новый сайт фактически.
Как ни странно, файловый кеш выгоднее в вашем случае. За счёт кеширования на стороне файловой системы, запрашиваемые файлы будут читаться не с диска, а из этого кеша, т.е. из памяти, как и в случае memcached.
Для того, чтобы это работало, системе необходимо оставлять свободную память, которую она могла бы использовать на нужды кеширования. Также, если вы где-то раздаёте большие файлы, надо делать это через directio, чтобы они не вымывали ваш файловый кеш.
Кеш в memcached не будет эффективнее - памяти больше не станет, и вам всё равно придётся где-то урезать её выделение, чтобы отдать memcached, и при этом не засвопится, что практически эквиваленно выделению свободной памяти под кеш файловой системы.
Кеш в memcached нужен для распределённой обработки скриптов на нескольких бекэнд серверах, когда обращение к общему кешу идёт по сети. Также, он нужен, если у вас есть отдельный сервер с большим количеством памяти, который вы решили использовать под кеш.
Надо подгружать содержимое модального окна динамически, при его открытии.
Обычно, у скриптов, которые реализуют модальные окна, либо уже есть такая возможность через настройки, либо они генерируют событие, по которому можно выполнить JS функцию, которая ajax запросом, подгрузит содержимое в нужный элемент.
Правильнее выдавать ошибку, если такой аргумент недопустим, или нет страницы с id=" 1", т.к. не будет дублирования страницы по разным URL. Также, если касаться вопросов безопасности а не SEO, то правильно проверять все входные парамерты по типу и допустимым значениям, и использовать prepared statments и биндинг параметров при работе с базой.
"У них так настроено". Также настроить можно и в случае XEN, KVM или OpenVZ, но н практике обычно не делают так, т.к. это неудобно ТП хостера.
Перезагружайте через панель, собственно что в этом проблематичного? Перезагрузка сервера не будничная процедура - не так часто нужна, чтобы с этим заморачиваться.
Не так важно, какие вы предлагаете технологии, важно, как вы общаетесь с клиентом и умеете продавать свои услуги. Именно такие умения позволяют быстро получить заказы.
Время освоения чего-либо очень индивидуально, и также, зависит от тех знаний которые у вас есть на сегодняший момент. Никто вам не спрогнозирует это.
Наиболее простым, наверное, будет освоение создания сайтов WP или Joomla, и потом погружение в PHP, и паралельно изучение JavaScript.
Покупается внешняя карточка(pci, pci-e). И используются порты на ней. Порты на материнке, естественно, остаются usb 2.0 Скорость увеличится только у usb 3.0 устройств, у которых шина является узким местом. Т.е. всякие флешки и картридеры будут работать также, медленные внешние винчеcтеры, cd/dvd тоже обычно не шиной ограничены. А вот внешние шустрые гибридные винчестеры/ssd будут работать быстрее, если узким местом не будет контроллер sata->usb.
Написать свою CMS не имея толком навыков программирования, одна из наиболее неразумных идей, на самом деле. =) Вы не научитесь практически ничему, но ри этом у вас получится даже не велосипед, а велосипед с квадратными колёсами, и на каком языке он будет написан, если у вас вообще хватит терпения довести его до конца, будет совершенно не важно.
Если вам по какой-то причине не хватает WP, посмотрите на другие готовые решения, а если хочется более бурного развития, попробуйте написать хотя бы толковое расширение для того же WP. Это будет неплохим началом.
Чтобы познакомиться с питоном, надо начать его изучать и применять, опять же. И тогда вы сможете сделать осознанный выбор. И опять же, начинайте с основ, не ставя целью, написать свою CMS.
Соглашаться на вышеописанное предложение не стоит - это может аукнуться в будущем, если возникнет необходимость сменить подрядчика.
Если действительно есть необходимость сменить CMS, лучше выбирать из распространённых вариантов, понмая, что дальнейшая поддержка будет куда проще.
Что именно выбрать, зависит от того, что у вас за сайт, какие возможности вам нужны и.т.п.
Выбирать UMI не стоит совсем. Это совсем кошмар.
Можно выбрать Битрикс, если готового функционала какой-либо редакции вам хватает, и если вас не смущает, что он очень нескромен в потреблении ресурсов. Если необходимо будет что-то дорабатывать, то лучше смотреть в другую сторону. Это не тривиально и не дёшево. Если у вас посещаемый сайт, то это тоже будет не очень хороший выбор - требования к хостингу космические. =)
Не зная ваших задач, порекомендовать вам что-то действительно подходящее сложно, но советую посмотреть в сторону того же Drupal - он более чем сравним с вышеперечисленными системати и куда более гибкий. Разработка на начальном этапе возможно будет дороже, даже с учётом цены лицензии битрикса (если получится уложиться в недорогие редакции) зато последующая поддержка и развитие будут дешевле, и исполнителей найти на эти работы будет несложно в случае чего.
А возможно и что-то более простое вам подойдёт.
Если стоит задача сделать что-то рабочее, хорошим выходом будет нанять системного администратора. Или, как советовали выше, взять готовое решение. Что хуже тем, что его тоже надо пилить напильником, чтобы всё было так, как надо.
Если стоит задача разобраться, стоит не искать готовые мануалы, а прибегнуть к прочтению и осмыслению документации всех элементов системы, и использовать мануалы как некую общуу схему, не более.