Впс за 600р это ад и израиль - либо ресурсов откровенно мало, либо оверселинг. Практически любой шаред будет лучше.
Нужны VPS прежде всего для нестандартных решений, а ни разу не для того, чтобы перенести на него проект не влезающий на шаред за те же деньги.
Только изменением запросов. Т.к. существует несколько ситуаций, когда временная таблица будет всегда создаваться на диске, вне зависимости от размера и ограничений на размер временной таблицы в памяти в конфиге:
Часто действительно имеет смысл сделать tmpfs для временной папки mysql, и это кстати, может быть папка отличная от /tmp, настраивается в конфиге mysql.
А параметрам max_heap_table_size, tmp_table_size имеет смысл вернуть более разумные значения.
Кстати, не пологайтесь на результат работы скриптов, точнее на рекомендации, они не всегда разумны.
http://drupal.org/project/feeds Умеет парсить csv, rss. С http://drupal.org/project/feeds_xpathparser, умеет парсить html, xml. Можно написать свой процессор под свой формат файлов, если нужно.
Заполняет не только title, body, а все нужные поля.
Вообще говоря вы не правы - вполне возможно, используя mod_gnutls. Вот только SNI поддерживают не все браузеры, не под всеми OS. Поэтому так делать в общем-то действительно не стоит пока.
Как работает и какие ограничения можно почитать например тут: http://en.gentoo-wiki.com/wiki/Apache2/SSL_and_Name_Based_Virtual_Hosts
Судя по "серому" ip сервера БД вы не подключитесь к нему удалённо - он сидит во внутренней сети хостера, и вероятность того, что он имеет ещё и внешний адрес стремится к 0.
С кешированием и не надо предугадывать. Есть в кеше, отдаётся из кеша, нет - запрашивается и кладётся в кеш, а ключём является запрос. Если запрос такой был - страница будет отдаваться куда быстрее из кеша. Если запросов много, просто кеш будет большим, и попадания будут особенно первое время не часто. А вот если в базе часто меняются данные, эта схема работать будет плохо, точнее в ней не будет особого смысла.
Это так у вас сейчас. А надо сделать как раз чтобы страница грузилась безо всяких запросов к базе, а потом, после её загрузки уже запускался AJAX запрос, который и запрашивал данные из базы. И потом выдавал бы их в нужный элемент страницы. Это намного удобнее и понятнее для пользователя.
Насколько велика сама БД? Насколько часто повторяются запросы? Насколко часто меняются данные в БД? Возможно кеширование ответов сильно спасёт ситуацию?
Второй вариант, делать загрузку ответа ajax запросом после загрузки страницы, и показывать анимацию в стели "ваш запрос обрабатывается - ждите".
И как вы потом обновляться-то будете перлопатив код? А обновления своевременные тут очень важны.
Админка Drupal не статична, её можно переделать точно также и теми же методами, что и frontend, и в отличии от той же джумлы не придётся залезать в код ядра или модулей. И насколько удобно она будет реализована для пользователя магазина, на совести разработчика прежде всего.
Хотя если делать именно магазин, и ничего больше, я бы тоже предпочёл более специализированное решение, но прежде всего, из-за производительности и простоты разработки.
Топискстартеру же вообще не надо брать этот заказ - без навыков програмирования хороший магазин не получится ни на чём - пилить что-то явно придётся.
На хостинге у клиентов должны быть максимально изолированные окружения и свои временные папки. Естественно доступа в /tmp(той которая в корне т.к. такая папка может быть доступна в chroot), у них быть не должно.
А вот если не доступна временная папка аккаунта, тут надо смотреть и разбераться, так быть естественно не должно.
Вы не следили за состоянием дисков, не делали бекапы. Именно это основная проблема - ваша некомпетентность, а не вылет диска/дисков...
Диски ломаются, как и всё остальное, от этого вы нигде не будете застрахованы. В итоге вам не повезло, но именно из-за вашей некомпетентности теперь у вас и ваших клиентов такие проблемы, вместо недолгого простоя на время восстановления данных из бекапа.
А случиться это могло в любом ДЦ и на любом сервере. Да, у Hetzner на десктопном железе вероятность выше, чем на брендовом сервере с винтами enterprise класса, но и ценник у Hetzner куда ниже, настолько ниже, что можно держать сервер в запасе, даже возможно не один за те же деньги.
