Сергей Протько

Понять и простить.

Откройте консоль браузера и разбирайтесь с ошибками. Подозреваю что какой-то вызов устаревшей функции идет.

Если хотите использовать две версии jquery на одной странице то читаем документацию для noConflict у jquery.

Оукей. давайте возьмем ваш пример с fl.ru + чаты.

mongodb - хипстерская база данных. Для проекта типа fl.ru я бы пожалуй не использовал оную (не потому что монга отстой а потому что я лично не вижу в использовании оной смысла в контексте проекта типа fl.ru. Нам не нужен шардинг, реплекация реализуется нормально на любой нормальной RDBS, документоориентированность не нужна, хотя при грамотном подходе можно было бы реализовать неплохие агрегированные коллекции и оптипизировать селекты... Для себя не нашел у монги ни одного плюса перед RDBS типа PostgreSQL). В любом случае если вы не оставляете выбор - тут у нас будут храниться все данные. Придется потратить время на то что бы избавиться от желания что-то заджойнить и реализовать map/reduc-ы для обновления связанных коллекций. Но зато это будет так по хипстерски!

То есть если у вас есть куча однотипных запросов с кучей джойнов данные для которых обновляются редко а выборки происходят часто, то тогда можно вооружиться монгой а делать коллекции как агрегации этих выборок. Если вы вставляете референсы и пытаетесь эмитировать джойны в монге то значит вы сделали не правильный выбор основного хранилища данных). Правда денормализовать данные можно и с RDBS....

sphinx - поисковой индекс. То есть если мы должны реализовать вменяемый поиск (например по описанию вакансии) - то стоит его заюзать. Сфинкс не самый дружелюбный зато один из самых быстрых поисковых индексов. Хорошо интегрируется с MySQL и подобными и если сравнивать с ElasticSearch из коробки чуть лучше дружит с русским языком. Но опять же у эластики свои плюшки. Некоторые оной заменяют монгу так как по большинству фич в плане хранилища данных они совпадают.

redis - мы там вроде чатик делали. Помимо того что redis это хорошее key-value in-memory хранилище, которое к тому же может обеспечить нам надежность хранения данных (мэпится на файловую систему еще), оно так же поддерживает pub/sub. То есть чисто теоритически мы можем не добавлять в стэк штуки типа ZeroMQ и прочие *MQ для реализации авторизации и связи приложения чатика и основного приложения (вдруг у нас чатик будет написан на go/node.js/erlang).

memcache - вот тут стоит подумать нужен ли он если у нас есть редиска. Раньше для жирного кеша выбор был очевиден - memcached, так как reddis в те времена не поддерживал кластеризацию. Сейчас же по возможностям редиска далеко впереди. Так что даже то что memcached чуточку быстрее (но жрет больше памяти и не поддерживает авторизацию к примеру из коробки) не должно стать поводом для использования оного. Но я если честно redis в кластерах не использовал и ничего говорить не могу, а memcached испытан годами.

Я правильно понимаю что вы пытаетесь из PHP кода который выпоняется на сервере вызвать JS функцию которая должна отрабатывать на клиенте? Мде.

Загружать файлы по scp с флагом -C (включает сжатие, не путать с -c). В дополнение плюшки вроде авторизация по ключу и шифрованное соединение...

Python может все. Ну или не меньше чем любой другой язык программирования. А за счет огромного количетсва готовых модулей, развитого комьюнити, наличия альтернативных реализаций (PyPy, Cython и т.д.) на нем еще и довольно комфортно можно писать высокопроизводительные системы. Половина убунты на python написана (утилитки) чего уж там.

Я лично применяю Python для ресерчей (DSP, класстеризация)

Ну например применить конртрактное программирование при обработке платежей и заказов. Вообще все писать на АОП сами понимаете смысла нет. Я если честно даже сходу не могу придумать куда еще можно АОП воткнуть что бы это выглядело адекватно.

В одном из вопросов я выкладывал ссылки на библиотеки и реализации ридеров на JS. Защититься полностью возможно не удастся но может на мысль наведут.

Если у вас ассоциативный массив то вам не нужно соблюдать порядок. Иначе у вас уже не ассоциативный массив.

uasort достаточно быстр. Только код можно упростить:

uasort($test, function ($a, $b) {
    // если бы у вас там были именно числа...
    // return $a['date'] - $b['date'];
    return strcmp($a['date'], $b['date']);
}

session_start создает сессию. Что это значит? Это значит что оно создает место куда будет сохраняться инфа (файл по умолчанию) и присваивает этому месту какой-то рандомный идентификатор. Что бы сессия не потерялась пользователь должен отправлять его при каждом запросе. Так сложилось что это дело разруливают через куки.

Куки сетятся заголовком Set-Cookie, так что когда вы вызываете функцию session_start это равносильно отправке заголовка пользователю.

Вообще в HTTP запросах/ответах есть две части - заголовки и тело. Заголовки описывают параметры запроса/ответа, в частности что именно содержится в теле запроса/ответа и в случае запроса, что хочет получить пользователь/клиент.

Думаем дальше. для работы с заголовками ответов SAPI в PHP предоставляет вам функцию header. Упростим для себя жизнь и представим что session_start дергает внутри оную. Все что выходит через другие места в stdout (через echo или print например или просто какой-то символ перед <?php затесался) считается телом ответа. Так как должна соблюдаться последовательность действий при формировании HTTP ответа, то вы не можете менять заголовки как только хоть что-то, даже один байт, попал в буфер вывода.

Частично эту проблему решают функции управления буфером вывода. То есть мы можем сказать пыху что бы тот чуть подожал, а затем сделать flush буфера. Тогда можно в коде спокойно менять местами echo и header.

Вот... Помимо несоблюдения порядка взаимодействия с заголовками и выводом инфы частенько встречается такая штука как заголовки самих исходников (UTF BOM). Их умеет убирать любой нормальный редактор.

Так же рекомендуется не закрывать <?php тег так как после закрытого тега может затесаться лишний перевод строки и при инклудах это сыграет злую шутку.

Не забудьте про rsync как средство деплоя.

Вообще все просто, при деплое через git pull у вас перестает работать текущая версия сайта. И время простоя зависит от сложности деплоя. Например вам нужно установить вендоры - пока будет работать composer install мы ждем. Затем мы чистим кеш - опять простой. Затем миграции. Снова ждем, а миграции могут выполняться долго в зависимости от сложности... хотя они редко выполняются дольше пары минут.

А всякие тулзы типа капифони и т.д. имеют возможность версионизации. То есть пока у вас поднимается новая версия - старая обрабатывает запросы. Как только миграции будут накачены, капифони просто поменяет симлинки и релоаднет nginx (не перезагрузит, а только реалоаднет).

А когда приходится при каждой выкатке на сервер еще и за окружением следить вход пускают еще и ansible/puppet. Так же есть еще и Docker.

reactphp + libev попробуйте за основу демона взять.

Как это не странно но нет, у вас слишком простые запросы. Полагаю что большую часть времени работы скрипта съедает file_get_html. Скажем wget-ом данные выкачивались у меня ~2 секунды.

Браузеры по разному рендрят странички знаете ли, даже разные версии одного и того же браузера.