Tonik

Ищете на гитхабе jwilder/nginx-proxy (почему то не позволяет запостить ссылку)

Используем вот такую штуку github.com/paulasmuth/fnordmetric
Может требовать некоторого допиливания что бы меньше кушало места в базе, но в целом очень довольны.

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

А можете уточнить что за PhpBrowser? В сочетание с codeception ни чего путнего не гуглится

К сожалению ни чего в голову не приходит, что бы из коробки.
Возможно vagrantup.com/ как то поможет, но там конечно телодвижение не мало будет.

Конкретно для mysql есть mysqlsandbox.net/

Было бы интересно. С кармой помог. Хаб — не посоветую к сожалению

У nginx это не очень хорошо реализовано. Советую попробовать схему

nginx->haproxy->бэкенды

haproxy более продвинут в плане честной балансировки

vocaroo.com/
У меня была проблема описанная тут vocaroo.com/?help#helpLocation3 — решилась как там и написано.

Похожая проблема, прошу отпишитесь насколько прижилась схема с голосовыми заметками.

Условия слишком расплывчаты, многое будет зависить от конкретных API. Вот один из вариантов решения подобной задачи для mysql таблиц www.percona.com/doc/percona-toolkit/2.1/pt-table-checksum.html

возможно какие то идеи вам пригодятся.

А почему вас пугает системы контроля версий? Мне кажется git просто идеально подходит для вашей ситуации.

Проблема что сильно будет зависить от специфики данных. Ни какая утилита за вас не решить как решать конфликты, так что это будет основной проблемой

Если вам в целях HA, то есть несколько вариантов. И однозначно хорошего среди них нет — нужно смотреть по обстоятельствам. Опять же много зависит, от того какая нужная надежность.

Если нужно очень очень надежно и малейшая потеря данных недопустима, то придется платить производительностью в любом случае. Обычная, асинхронная репликация вам не подойдет, так как не будет 100% уверенности, что данные успели уйти на слейв.

Можно использовать DRDB + Heartbeat
Надежно, но пенальти на запись. И сеть между серверами должна быть хорошей.
Для FreeBSD можно нечто подобное соорудить при помощи репликации на уровне ZFS.
В 5.5 появилась репликация с подтверждением записи данных, хотя бы на один из слейвов.

Если кратковременный простой и небольшая потеря данных, допустимы (внимание, я не предлагаю плевать на юзерские данные! Но одно дело банк и финансы, другое — потерять два три голоса за авотарочку...), то асинхронная репликация, вполне хорошее решение.
Однако, что то (например nagios) должен мониторить SHOW SLAVE STATUS, что бы вовремя заметить если репликация слетела.

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

А вот использовать запасную БД для балансировки запросов не всегда хорошая идея. Если упадет мастер, то запросы который раньше обрабатывались двумя серверами придется, придется отрабатывать одному слейву. Код должен быть готов, отрубить ряд ф-ций при таком раскладе.

Это все мое имхо…

А собственно почему бы не использовать S3? Судя по всему Paperclip вроде как это умеет

Последние 6 лет руковожу удаленными группами. мое имхо — все упирается в мотивацию людей. Если люди смотивированы на результат, все проблемы удаленки они преодолеют. По скайпу пообщаются, в вики напишут, скриншотов наделают. Если единственный ожидаемые результата от работы ЗП, то удаленка все ухудшает — замучаетесь пинать и контролировать. Все как обычно — главное люди.

Поэтому, чисто тихнически, работать эффективно вполне можно, но только если работать люди хотят.

С другой стороны офис, тоже полезен — в живую общаться все равно продуктивней. Так что идеальный вариант, это 1,2 раза в неделю встречаться в офисе для «синхронизации», а остальное время вполне можно удаленно.

Опыт это великая штука и конечно его нужно учитывать при выборе технологий. С другой стороны и клиента понять можно — JVM должна быть быстрее, особенно если сразу известно что сайт будет под нагрузкой.

А о таком варианте не думали docs.djangoproject.com/en/dev/howto/jython/? Конечно сам по себе он скорость не даст, но в случае проблем будет сильно проще переписать критичные модули на чистой Java. Это и вам даст привычную среду разработки и клиента может успокоить.

duplicity.nongnu.org/index.html может использовать S3 как бэкенд. Лично попробовать руки еще не дошли, но отзывы слышал только хорошие.

Насколько я помню, с использованием IN это не возможно. Сходу в голову приходит, сделать временную таблицу из одной колонки, вставить туда все значения из IN и потом переписать запрос на что типа

SELECT value
FROM table t
JOIN tmp_tabel t2 ON (t.value2 = t2.value)

Я не знаю насколько это подойдет в вашем случае с несколькими репозиториями, но у нас вполне успешно работает следующая схема.

1. Для каждого релиза создается тэг (фактически бранч) вида YYYYMMDD
2. Капистрана допилена так, что по умолчанию ищет и деплоит последний по дате тэг
3. В случае если ошибка нашлась на лайве, правим ее в транке и мерджим изменения в актуальный тэг

Для последнего пункта я накидал небольшой скрипт который принимает на вход номера ревизий для мерджа и дальше все делает сам. Циклы релизов у нас в районе недели, так в 99% проблем при мердже не возникает — код транка не успевает сильно изменится.

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

Есть проект phpdaemon, который может работать как FastCGI server. На хабре о нем не редко пишут. Вот например попытка перевести проект на симфонии на него habrahabr.ru/blogs/php/103875/.

При всем моем уважение к phpdaemon (без сарказма), я бы побоялся выпускать это в продакшен.
1. Сколько людей стоит за этим проектом? Насколько безглючный код? Не надоест ли автору завтра заниматься этим проектом? Лист рассылки не выглядит слишком активным…
2. Если у вас есть уже готовый код, большой шанс что его придется допиливать.

И тд. Мое имхо, что PHP годами был плохо приспособлен к такому использованию. Да стало лучше, но еще пройдет не мало времени, прежде чем вся инфрастуктура PHP будет приспособлена для true FastCGI приложений.

мое мнение — если хотите настоящий FastCGI, то PHP пока не лучший выбор.

Все что описали выше полезно, но я добавлю чем мы пользуемся

Профайлер — mirror.facebook.net/facebook/xhprof/doc.html Реально класная вещь. Это расширение, которе легко управляет из PHP. Конечно результаты смотряться не так красиво, как xdebug + kcachegrind но есть очень нужная фича для вас. Результаты профилирования разных страниц можно агригировать в один усредненный отчет. То есть можно на продакшене профелировать, скажем 0.01% все запросов, и потом смотреть агригированнй отчет. Сразу будет видно какие ф-ция тормозят. С xdebug можно не угадать и профелировать не те урлы.
Сразу отвечу на вопросы, да пробовали его включать под нагрузкой и сильного оверхеда не заметил.

Для SQL люто советую www.maatkit.org/doc/mk-query-digest.html Умет использовать в качестве источника SHOW PROCESSLIST, binlog и даже анализировать сетевой трафик чере tcpdump. Самое полезное — умеет объеденять запросы в логические классы с точностью до параметров.