open_file_cache всё же проверьте.
Так выбор фреймворка, и есть возможность оставаться в рамках одного из имеющихся стандартов, а не разбераться в лапшекоде очередного велосипеда потом...
Это как присать. Естественно лучше если это будет PDO, или хотя бы mysqli.
mysql_query использовать не стоит хотябы потому, что это depricated, и потому, что наверняка найдутся места, где вам воткнут SQL injection.
Предпочтительно использовать PDO.
Писать свою обёртку, обычно довольно мало смысла. В небольшом проекте это будет лишний код сомнительной в итоге полезности, а в большом лучше использовать готовый фреймворк, где она уже будет.
Вполне умеет.
См. limit_rate, limit_rate_after.
setTimeout(function(){_gaq.push(['_trackEvent', 'Page view', 'time', 15]);}, 15000);
Так?
Скорее всего, это просто перебор в автоматическом режиме по списку уязвимостей для какого-то скрипта. "А вдруг прокатит".
Банить тут лучше не по ip, а например, анализируя логи каким-нить fail2ban.
Через сравнение содержимого пакета накладно, да и получить false-positive легко.
Никаких общих схем, вы не найдёте - развитие проектов весьма индивидуально. Многое зависит от наличия средств/времени/навыков, того, как изначально проектировалось приложения и многих других факторов, которые в сумме учесть и разложить по полочкам не получится.
На мой взгляд, имеет смысл, поискать узкие места скрипта, и по возможности их устранить. Например, оптисизировать запросы и структуру данных, кешировать по возможности данные, которые часто запрашиваются и получение которых накладно по ресурсам.
Если это сложно и дорого на данном этапе(например если не получается решить эти задачи своими силами, и необходимо привлечение квалифицированных специалистов для этого, или необходимые переделки весьма глобальны), то возможно, выгоднее просто переехать на более производительный хостинг, или даже на свой сервер. Нередко, это оказывается дешевле и быстрее.
Если планируется дальнейший рост, то в какой-то момент придётся думать ооптимизации, и о горизонтальном масштабировании, и тут всё равно многое упрётся в разработку, т.к. если это небыло задумано с самого начала, то скорее всего, не получится легко перейти к выполнению приложения на нескольких серверах. И в это время, вероятно, экономия серверных мощностей уже будет выгоднее экономии на разработке/оптимизации.
Лучше сервера, конечно, брать там, где и основная часть пользователей, но в вашем случае, не обязательно в Испании - пинг до Франции, Голландии, Англии или Германии будет вполне разумным, а найти хорошее предложение по серверам в этих странах будет куда проще...
Естественно брать сервер на другом континенте будет не слишком разумно. =) Хотя и не катастрофично, скорее всего. В большинстве случаев, пинг не так и заметен во времени загрузки сайта, и фактор удалённости сервера часто переоценивают.
А вот о CDN имеет смысл подумать, но не из-за близости к пользователям в первую очередь, а из-за разгрузки основного хостинга - часто разумно заплатить за аренду инфраструктуры, чем делать её самому...
Можно и нужно.
Буферы к ограничению скорости не относятся. Так что нет, этого не достаточно.
limit_rate_after имеет смысл указать достаточно большим, чтобы в него влезали метаданные, иначе будет заметная задержка при старте проигрывания.
=) Только от полной безысходности такое можно использовать...
Не стоит - поддерживать в продакшене весьма невыгодно. Gentoo здорово использовать чтобы вникнуть что от чего зависит, и как всё работает на самом деле. =) Ну и в некоторых редких случаях, когда надо сделать что-то либо очень компактное, либо очень нестандартное...
