А если не секрет, сколько человек у вас занимается разработкой этого проекта?
Самописную базу данных в open source не собираетесь выкладывать? или она узко специализирована?
мы используем virtualenv при разработке и развёртывании системы, поэтому для установки всех библиотек нужно всего лишь запустить команду
а не смотрели в сторону buildout?
Про графит — я правильно понимаю, что графит вы используете для реал-тайм статистики? А используется что-то для бизнес-аналитики (для всяких специфических метрик, завязанных на бизнес-логике)? Или такие метрики тоже посылаются в графит?
И ещё один вопрос про логи. Вы писали что используете Sentry для ошибок. А всякие логи уровня info собираете? И если да, то используете syslog и его вариации или что-то другое?
Это ВК и Фейсбуку деваться уже некуда, у них приличная часть всего написана на PHP, но мы то в сами сегодня располагаем более широким инструментарием, чем даже 5 лет назад, верно? Где нужно, применим Node, где оправдано — Erlang или, прости господи, Go, а всякую обвязку — на PHP. И не нужно говорить, что потом это все будет сложно поддерживать, поддерживать конкретную реализацию, заточенную под конкретную задачу куда эффективнее, чем мостырить PHP для всего-всего.
Я думаю, что при большом желании такие монстры как VK и FB могут себе позволить переписать все на Node / Erlang и т.п. И по времени это займет скорее всего меньше, чем писать свой компилятор для PHP. И кстати у VK по-моему довольно много сервисов работает на Node.js (по крайне мере Node.js они точно используют в качестве прослойки для реализации XMPP). Я думаю, что все они используют PHP более чем эффективно и как раз-таки по месту, где и надо. Другое дело что, как вы правильно заметили, с их масштабами все время приходится придумывать что-то новое и выкручиваться.
Плюс выбор PHP как языка (а не какого-нить Erlang-а или там чего-нить ещё) обусловлен ещё тем, что ребята просто хорошо умеют его готовить. А зачем использовать что-то новомодное, если ты хорошо справляешься и со старым?
Вообще не понимаю синтетические тесты производительности фреймворков/языков программирования, когда в реальности в 99,9% все тормоза банально упираются банально в базу (и кривые руки которые пишут кривые запросы).
На самом деле скорость выполнения скриптов вообще 20ое дело. И если она так важна, то следовательно проект высоконагруженный и суперпосещаемый, а следовательно проще добавить дополнительный сервер, и за счет грамотной монетизации (клиентура то есть, иначе откуда взяться нагрузкам), проект быстро отобьет затраченные на сервер деньги.
На самом деле в случае гонки за скоростью обычно стоит выбирать — либо разрабатываем супергибкий движок, и он будет средним по скорости, либо же забиваем на гибкость, и пишем код так, чтобы все работло супер быстро. Вот кстати пример из реальной жизни — например используем мы супер крутяццкий ORM, извлекаем из БД 500 объектов, и в лучших традициях жанра ORM оборачивает каждый извлеченный элемент в объект. При большом количестве извлеченных объектов (200-300) задержка выполнения скрипта может варьироваться от 50 до 150 ms. И тут уже надо выбирать — либо гибкий ORM, либо выигрываем 50 ms в каких-то кейсах, но забивем на гибкость.
Один запрос с JOIN-ом на базе будет быстрее чем 2 запроса и JOIN на стороне питона как минимум из-за того что не надо 2 раза гонять данные.
Вот кстати совершенно не факт. Смотря что за БД используется. Если отталкиваться от MySQL, то есть ситуации когда вместо JOIN лучше сделать два запроса и склеить данные в коде
Вот FB говорит что юзает PHP, но их инженеры по секрету грят что это пиздежь полный и PHP там особой роли не играет
насколько мне известно, они используют hiphop, а это не совсем PHP в его типичном понимании. Да и даже если PHP, то ничего удивительно — такие проекты как Wikipedia или VK тоже крутятся на PHP и нормуль
Ну это как бы unix-way: пусть каждая программа делает что-то одно, но хорошо. leveldb кстати тоже nosql, только менее попсовая чем mongo, cassandra и т.п.
Я сам не фотограф, но друзья пользуются вот этими двумя плагинами для wordpress: Thumbnail Gallery и NextGEN Gallery. Сразу оговорюсь, что про качество этих плагинов ничего сказать не могу, т.к. сам их не пробовал.
Интересное решение… Нашел их репозитории на github-е. Там лежат плагины, но вот кода самого ядра там нет. Вообще складывается впечатление, что авторы движка панически боятся палить исходники своей CMS-ки (на что ещё намекает тот факт, что инсталлятор содержит всего один скрипт, который грузит некий архив с удаленного сервера).
Видимо данное решение ориентировано на профессиональных фотографов (судя по наличию синхронизации с Lightroom), но вот чего я не пойму — чем данное решение отличается от многочисленных плагинов для wordpress-а, которые в принципе-то реализуют аналогичную функциональность для управления фотками из админки? в чем killer-фича-то?
Кстати, а может кто-нибудь вспомнить ещё парочку подобных CMSок, ориентированных на создание юзабельных фотосайтов?
Спасибо за заметку! От себя могу добавить ещё одну особенность — при удалении объектов через ORM когда мы пишем
SomeModel.objects.filter(...).delete()
Django почему-то сначала делает SELECT и выбирает все записи, которые соответствуют условию, указанному в filter, а уже потом только DELETE. То есть как RAW SQL это выглядит примерно как-то так:
SELECT "some_table"."id", ... FROM "some_table" WHERE ...
DELETE FROM "some_table" WHERE "some_table"."id" IN (...)
Причем в результатах выборки первого SELECT присутствуют все поля, а не только поле primary key.
Наверное, создатели движка хотели таким образом предусмотреть какую-то исключительную ситуацию, но вообще говоря в большинстве-то случаев первый SELECT казалось бы лишний.
Затем в футер странички добавляется js-код, который по window.onload перезагружает страницу. Суть теста заключается в подсчете времени загрузок 50 страниц. Перезагрузка происходит 2 вариантами: location.href=’/’ и location.reload(true). Когда выставляем параметр forceGet в true, браузер перезагружает все ресурсы на страничке (картинки, стили, скрипты). Тест через file_get_contents: на ОС-хосте выполняется php-скрипт, который загружает 50 страниц с тестируемой машины посредством функции file_get_contents.
Вот это какой-то жжжутчайший велосипед. Существуют специализированные утилиты, например apache benchmark или же siege, которые используются для подобного рода тестов.
Была взята таблица wp_posts. Операции повторяются 5000 раз.
Зачем лепить сюда Wordpress если в коде скрипта для теста используется простой insert в цикле в отдельно взятую таблицу? Вообще говоря внутри Wordpress-а при создании поста помимо вставки записи в таблицу wp_posts присутствует масса других оверхедов. Почему была выбрана именно эта таблица? почему с таким же успехом не создать какую-то другую таблицу, в имени которой не фигурировал бы Wordpress?
Все же номинальных победителей определим: Запись CentOS, чтение OpenSUSE.
это классика… Сделать 1000 раз select равносильно тому чтобы проверить query cache например. Смысл в таком дико искусственном тесте?
Оказалось что на OpenSUSE и Ubuntu установлена MySQL 5.5.xx, а на всех остальных 5.1.xx.
Иии что? Как это связано с производительностью на отдельно взятом дистрибутиве? а вы пробовали ставить MySQL не из пакетов, а собирать вручную из сорцов? Уверен что в этом случае производительность во всех вышеприведенных тестах будет совершенно другая. И, кстати, что мешает самому на любой unix-like ОСи собрать последнюю версию MySQL из исходников?
все они работают на Debian. Но почему именно он? Не знаю, возможно, эта ось более популярна
Дело не в производительности. В 90% случаев дистрибутив выбирает админ, и выбор этот зависит по большей части от того, в какой ОС он больше всего прошарен. Debian — это в первую очередь стабильность (если ориентироваться на main-репозиторий), CentOS — аля RedHat, а тут уже куча своих плюшек. Зачем сюда лепить мифическую производительность — вообще непонятно.
Отличная статья, но я бы добавил бы ещё один пункт — всё это многообразие NoSQL-решений появилось по большей части на волне массовой истерии крупных highload-стартапов. То тут, то там в блогах читаешь, что вот мол Facebook разработали Cassandra специально под свои нужды, начали использовать, и сразу все стало хорошо! Или же вот Foursquare — активно используют MongoDB, и тоже все у них круто, все масштабируется на 5+, одолели highload и т.п. Ну блин, ребята, вы же не Facebook и не Twitter. 90% проектов в сети прекрасно работают банально на одном сервере с использованием самой банальной РСУБД аля MySQL или PostgreSQL и даже в ус не дуют. Просто РСУБД — это проверенные временем средства, многие из которых активно разрабатываются и используются чуть ли не два десятилетия. В интернетах десятки обмусоленных тем по поводу различных подводных камней, кучи туториалов, миллионы утилит для разного рода диагностики и логирования, патчи от сторонних разработчиков и т.п. Где все это в NoSQL? РСУБД — это своего рода «швейцарский нож», при помощи которого можно сделать что угодно и как угодно. Про NoSQL же ИМХО имеет смысл задумываться, когда проект уже сформирован, прекрасно работает, и встает вопрос об оптимизации, и уж никак не заместо РСУБД, а вкупе с ними.
P.S. MongoDB, кстати, довольно неплохая штука, подводных камней конечно куча, и распиаренный шардинг с репликацией на деле получаются далеко не такими простыми, как в документации. Но, на мой взгляд, через пару лет MongoDB скорее всего займет свою определенную нишу
Это понятно. Я что имел ввиду, вот например я удалил объект из бакета, при помощи версионности я могу его вернуть обратно? просто без версионности объекты удаляются безвозратно.
Самописную базу данных в open source не собираетесь выкладывать? или она узко специализирована?
а не смотрели в сторону buildout?
Про графит — я правильно понимаю, что графит вы используете для реал-тайм статистики? А используется что-то для бизнес-аналитики (для всяких специфических метрик, завязанных на бизнес-логике)? Или такие метрики тоже посылаются в графит?
И ещё один вопрос про логи. Вы писали что используете Sentry для ошибок. А всякие логи уровня info собираете? И если да, то используете syslog и его вариации или что-то другое?
Я думаю, что при большом желании такие монстры как VK и FB могут себе позволить переписать все на Node / Erlang и т.п. И по времени это займет скорее всего меньше, чем писать свой компилятор для PHP. И кстати у VK по-моему довольно много сервисов работает на Node.js (по крайне мере Node.js они точно используют в качестве прослойки для реализации XMPP). Я думаю, что все они используют PHP более чем эффективно и как раз-таки по месту, где и надо. Другое дело что, как вы правильно заметили, с их масштабами все время приходится придумывать что-то новое и выкручиваться.
Плюс выбор PHP как языка (а не какого-нить Erlang-а или там чего-нить ещё) обусловлен ещё тем, что ребята просто хорошо умеют его готовить. А зачем использовать что-то новомодное, если ты хорошо справляешься и со старым?
На самом деле скорость выполнения скриптов вообще 20ое дело. И если она так важна, то следовательно проект высоконагруженный и суперпосещаемый, а следовательно проще добавить дополнительный сервер, и за счет грамотной монетизации (клиентура то есть, иначе откуда взяться нагрузкам), проект быстро отобьет затраченные на сервер деньги.
На самом деле в случае гонки за скоростью обычно стоит выбирать — либо разрабатываем супергибкий движок, и он будет средним по скорости, либо же забиваем на гибкость, и пишем код так, чтобы все работло супер быстро. Вот кстати пример из реальной жизни — например используем мы супер крутяццкий ORM, извлекаем из БД 500 объектов, и в лучших традициях жанра ORM оборачивает каждый извлеченный элемент в объект. При большом количестве извлеченных объектов (200-300) задержка выполнения скрипта может варьироваться от 50 до 150 ms. И тут уже надо выбирать — либо гибкий ORM, либо выигрываем 50 ms в каких-то кейсах, но забивем на гибкость.
Видимо данное решение ориентировано на профессиональных фотографов (судя по наличию синхронизации с Lightroom), но вот чего я не пойму — чем данное решение отличается от многочисленных плагинов для wordpress-а, которые в принципе-то реализуют аналогичную функциональность для управления фотками из админки? в чем killer-фича-то?
Кстати, а может кто-нибудь вспомнить ещё парочку подобных CMSок, ориентированных на создание юзабельных фотосайтов?
Django почему-то сначала делает SELECT и выбирает все записи, которые соответствуют условию, указанному в filter, а уже потом только DELETE. То есть как RAW SQL это выглядит примерно как-то так:
Причем в результатах выборки первого SELECT присутствуют все поля, а не только поле primary key.
Наверное, создатели движка хотели таким образом предусмотреть какую-то исключительную ситуацию, но вообще говоря в большинстве-то случаев первый SELECT казалось бы лишний.
Вот это какой-то жжжутчайший велосипед. Существуют специализированные утилиты, например apache benchmark или же siege, которые используются для подобного рода тестов.
Зачем лепить сюда Wordpress если в коде скрипта для теста используется простой insert в цикле в отдельно взятую таблицу? Вообще говоря внутри Wordpress-а при создании поста помимо вставки записи в таблицу wp_posts присутствует масса других оверхедов. Почему была выбрана именно эта таблица? почему с таким же успехом не создать какую-то другую таблицу, в имени которой не фигурировал бы Wordpress?
это классика… Сделать 1000 раз select равносильно тому чтобы проверить query cache например. Смысл в таком дико искусственном тесте?
Иии что? Как это связано с производительностью на отдельно взятом дистрибутиве? а вы пробовали ставить MySQL не из пакетов, а собирать вручную из сорцов? Уверен что в этом случае производительность во всех вышеприведенных тестах будет совершенно другая. И, кстати, что мешает самому на любой unix-like ОСи собрать последнюю версию MySQL из исходников?
Дело не в производительности. В 90% случаев дистрибутив выбирает админ, и выбор этот зависит по большей части от того, в какой ОС он больше всего прошарен. Debian — это в первую очередь стабильность (если ориентироваться на main-репозиторий), CentOS — аля RedHat, а тут уже куча своих плюшек. Зачем сюда лепить мифическую производительность — вообще непонятно.
P.S. MongoDB, кстати, довольно неплохая штука, подводных камней конечно куча, и распиаренный шардинг с репликацией на деле получаются далеко не такими простыми, как в документации. Но, на мой взгляд, через пару лет MongoDB скорее всего займет свою определенную нишу