Низкие тайминги дают реальное преимущество при одинаковой, или близкой тактовой частоте. DDR3 на 1,6ГГц даже с таймингами 10-10-10 будет минимум втрое быстрее DDR1 на 333МГц с 2-3-2.
Just google it, в сети полно тестов, всякий раз народ разочаровывается. На конференциях много раз говорилось, например тут.
Почему-то люди думают, что раз облачные вычисления, то это панацея от всего, серебряная пуля. Однако от навешивания на то же самое железо дополнительных прослоек и разделения всех ресурсов с другими — производительность точно не возрастает.
С чего вы так решили, что не должен? Клиент принимает всех кто к нему коннектится, иначе бы все «новички» не могли бы вообще скачать ни байта, пока другие не обновят списки с трекера.
Их полно можно найти. Но такой подход плохо работает. А в случае с почтой, можете легко попасть в черный список спамеров, особенно, если не доглядите где-нибудь, оставите возможность использования сервера третьими лицами. С этим лучше не экспериментировать. Борьба со спамом тоже штука не простая, особенно для небольшого сервера. На мой маленький сервер, обслуживающий всего несколько доменов, почту пары маленьких фирм, ежесекундно сыпется десятки писем, в буквальном смысле, и 99,9% из них сразу рубиться на месте еще до попадания в почтовый ящик. При этом важно, не только спам зарубить, но и нужные, не спам, в живых оставить.
Целый сборник рецептов, о которых вы говорите, есть например тут: www.lissyara.su/articles/freebsd/mail/, да, для freeBSD, но если вы разбираетесь в основах *nix, то без проблем примените изложенное к Debian (разница лишь в методе установки пакетов, стартовых скриптах и местах расположения конфигурационных файлов), а если нет, то вообще лучше в админство пока не лезть. =)
Я смотрю в 5.3 таки добавили garbage collector, вот только насколько он хорошо работает, учитывая, что это сравнительно недавнее нововведение, опциональное, посему накоплен весьма малый опыт его использования. Опять же это не исключает утечек в используемых расширениях, которые скорее всего особо и не отлаживались в таком режиме работы.
Эк, видимо вы не сталкивались с утечками памяти в самом интерпретаторе php. Практически все веб-приложения на php работают по одному принципу, как конвейер. Инициализация -> Обработка запроса -> Возврат ответа, и так каждый запрос, php-код при этом не выполняется непрерывно, а завершается. Это позволяет довольно грубо обращаться с памятью и добавляет оверхэд на инициализацию, поэтому любой ruby\python для современных веб-приложений на мощных фреймворках с нетривиальной конфигурацией в сто крат лучше.
Никогда не задумывались, почему практически никто не пытается писать на php десктопные приложения с gui, всякие демоны и прочие? Таких примеров единицы, и применение их 24/7 в продакшене вызывает большие сомнения. PHP течет как дырявое корыто: www.google.com/search?q=php+memory+leak, словить в нем утечку проще простого. Может быть я не в курсе, давно на нем ничего не пишу, и возможно в новых версия с этим гораздо лучше, но никто не гарантирует, что при этом не будут течь различные библиотеки. Thread-safety также вызывает сомнение.
Начнем с того, что многие XMPP-транспорты написаны, как раз, на Python. И если, прежде чем писать «разве что попадётся...» хоть чуточку погуглить, то можно обнаружить полно всего и нередко с хорошей документацией. Первое, что попалось на глаза: xmpppy.sourceforge.net/
— xmpppy is a Python library that is targeted to provide easy scripting with Jabber.
pyxmpp.jajcus.net/
— PyXMPP is a Python XMPP (RFC 3920,3921) and Jabber (http://www.jabber.org/protocol/) implementation.
github.com/ajdiaz/whistler#readme
— Whistler Bot is an XMPP bot written in python using pyxmpp, which is a requirement. The bot is designed to handle some commands, and it's easy to extend.
Итого, автор вопроса, может потратить пару дней на изучение основ пайтона, а затем в кратчайшие сроки легко и просто написать своего бота, взяв за основу одну из штуковин перечисленных выше. Либо писать гораздо больше и гораздо мучительнее все это на php, а потом, преодолевать странности и бороться с утечками php интерпретатора, работающего в нестандартном для него режиме.
ИМХО именно столько нужно, чтобы вдумчиво прочитать tutorial на официальном сайте. Этих знаний + документации по какой-нибудь python-xmpp библиотеке — будет вполне достаточно.
Django для отладки не нужен никакой denwer, как, впрочем, и Pylons, и СherryPy… и, вероятно, большинство современных веб-фреймворков на python уже имеют встроенный веб-сервер. Более того, лучше вообще разрабатывать пользуясь linux.
По-моему автор не адекватен. Начал читать тут, spb-borodin.livejournal.com/596.html и закончил читать на фразе «Очень опытный программист не в состоянии придумать масштабируемую архитектуру сам».
Если вы делаете мастер-слейв репликацию, то слейв потому так и называется, что он может обрабатывать от клиентов запросы только на чтение. И не важно, что у вас за хранилище.
Единственный реальный способ горизонтального масштабирования — это шардинг. Почитайте наконец теорию. А то создается впечатление, что единственное, что вы читали — это как устроены другие крупные сервисы. И попытались извлечь из этого какие-то странные догмы. Учтите, что многие другие крупные сервисы, во-первых решают свои конкретные задачи, а во-вторых часто начинали как «как умеем так и делаем» и вообще не рассчитывали на большие нагрузки. А потому, зачастую, та архитектура, которую они имеют на сегодняшний день, нередко, ужасное чудище на костылях.
