Таких тестов никогда не будет много — на все модели он один и бегает циклом по моделям. Один потому что все модели стандартны и похожи.
Выборки из 2-3 таблиц у нас не бывают, это запрещено. У нас высоконагруженый проект: Join-ы, Union-ы, subquery и прочее — убивает почти любой сервер БД на нагрузках 2000 хитов в секунду — это не раз проверено, так работаем не только мы, но и, например, Facebook. Так же выборки их N таблиц сходу ломают идею шардинга. Сложные запросы хороши в решениях уровня предприятия или малого проекта, но не в нашем случае.
Идея вобщем то не в том, как я сделал реализацию, а в том, что все части системы имеют стандартный вид и их очень просто проверять (не тестировать!) — один тест покрывает 5 сущьностей подходящих под один стандарт, например модели.
Это как ГОСТ на гайки. Если любая гайка имеет 6 граней — это легко проверить одним автоматом, а вот если бы гайки имели разное количество граней — то на каждый тип граней пришлось бы делать разные проверяющие автоматы.
Идея имено в стандартах на сущьности и в том что это легко проверять, а не в том как мы применили эту идею к нашему проекту.
Это по сути — не тесты! У меня нет желания искать развалившийся код такоим сложным путем. Тесты — юнит, функциональные, интеграционные — проверяют бизнес-логику.
В нашем CI нет задачи проверки бизнес логики — как мы её проверяем — отдельная тема.
Задача этой схемы билда — проверка целостности, проверка того, что ничего не сломалось, то что раньше работало. Вот пример:
Если Вы будете искать ошибки вида «juniur не имплементировал абстракный метод в одном из потомков» функциональными тестами, то цена нахождения такой ошибки слишком велика — N минут разработчика на тест, для поиска ошибки сделанной за 0 минут. В нашем случае 0 минут разработки тестов, на тупую ошибку.
«регулярками вылавливать факапы мерджей» — ревью естественно есть, и пул-реквесты тоже — мы используем gitlab. Просто людям свойственно ошибаться и забывать любой разработчик даже опытный, в определенных условиях менее внимателен и может допустить такую ошибку.
Моя задача не отказаться от тестирования, и не отказаться от код-ревью — задача передать тестировщикам рабочий код, чтобы они не занимались поиском фаталов, а проверяли бизнес логику. Конечная цель — стабильное приложение. Минимум косяков на проде, и не ценой замучанных регрессивными проверками QA :-)
Не уверен, что достаточно. Когда то мы тоже так делали, но вот итоговая эффективность проверки была гораздо ниже (примерно на 70%), т.к. нет явной проверки работы моделей — которую я описал. И курлом не всегда все можно «продергать» — особенно в случае полностью ajax-приложения, где url вызываемые нажатием на кнопку берется не просто из href, а конструируется более сложным способом.
Не узнали, а жаль. Есть понятие производственной стабильности, оно мало применятся к IT, а вот тут реально жаль. В описанным Вами методе он нарушается: «заливание в ветку» — это плюс к нестабильности (т.к. мерж может быть кривым).
Регрессивное тестирование — а у Вас есть 5 человек QA, которым Реально Приятно заниматься регрессивным тестированием? Уверен, что 90% QA такое не любят. А заставлять людей делать то что им неприятно — они делают это менее внимательно — вот еще минус к стабильности.
Про систему контроля версий и хук — а Вы серьезно думаете что я руками запускаю билды? Естественно нет. И точно не по хуку — более умным способом, чтобы не билдить каждый git push. Смысл есть билдить результат закрытого тикета, а не все что пушат. Билд нашего приложения длится 30 минут. Вот представьте, если пушат раз в минуту — за день наберется очередь билдов, которая будет разгребаться еще неделю!
Пожалуйста!
Я тоже так считаю, ибо сломать старый функционал «случайно» — гораздо легче, чем написать новый баг, в новом функционале; ну с учетом того, что новый функционал пишут не левой ногой.
N серверов php-fpm с локальными mysql между ними сделана репликация. Insert, Update делается по tcp в одну базу (master), select делается из локальных баз по unix socket 15k соединений — сумма по всем серверам.
Когда смотришь на эту сумму и суммарную потерю производительности (пока коннект устанавливается — живет процесс php и ждёт зря память безпольно, так же копятся еще не обработанные коннекты на nginx, и прочее) происходит ощущение что что то не так — переводишь на unix socket и «висящих» соединений становиться меньше, php отрабатывает быстрее, nginx меньше копит на себе соединений, да и вся конструкция может обработать больше запросов.
1. У меня росли задержки не только на реквест, а на время соединения с базой — это реально заметно когда у вас много одновременных пользователей, api, кроны и прочее.
2. Кеширование зачастую не позоволяет избавится от всех запросов к базе (хотя и избавляет от 99% запросов с web), поэтому даже ради одного маленького запроса приходится открывать коннект.
Есть части которые не кешируются — api, кроны (их много и они очень активные и тяжелые), фоновые задачи в демонах.
Под достаточной нагрузкой я замечаю даже время потраченное со совершение tcp коннекта к базе. Хотя оно и мало оно создает заметный тормоз при достаточном количестве коннектов, поэтому мы перешли на unix сокет, он имеет меньшие задержки и более высокую производительность.
К сведению на моем проекте, нагрузка не очень велика: между php и mysql около 15000 одновременных соединений в пики нагрузки (говнокода нет, коннекты закрываются нормально).
P.S. оверхед от прослойки вполне может быть ощутим, но его никто не мерял.
P.P.S. если знаете как заметать оверхед на прослойку — подскажите!
старый драйвер(mysql): 7.36 sec — 100 000 запросов — выборка в 10 строк, нагрузка на cpu: 54% от ядра 3.1GHz (процесс php), ram: 10m
новый драйвер(mysqlnd): 13.3 sec — 100 000 запросов — выборка в 10 строк, нагрузка на cpu: 74% от ядра 3.1GHz (процесс php), ram: 13m
в случае pdo стало хуже — медленне, больше ест cpu и памяти. пробовал на:
php5-mysqlnd (5.4.4-7)
debian: wheezy/sid
запускался код:
$t = microtime(true);
$pdo = new PDO('mysql:host=localhost;dbname=koshka', 'root', 'password');
for ($i=0; $i<100000; $i++){
$pdo->query("SELECT * FROM koshka_users LIMIT 10;");
}
$t = microtime(true)-$t;
echo $t;
echo "\n";
Выборки из 2-3 таблиц у нас не бывают, это запрещено. У нас высоконагруженый проект: Join-ы, Union-ы, subquery и прочее — убивает почти любой сервер БД на нагрузках 2000 хитов в секунду — это не раз проверено, так работаем не только мы, но и, например, Facebook. Так же выборки их N таблиц сходу ломают идею шардинга. Сложные запросы хороши в решениях уровня предприятия или малого проекта, но не в нашем случае.
Идея вобщем то не в том, как я сделал реализацию, а в том, что все части системы имеют стандартный вид и их очень просто проверять (не тестировать!) — один тест покрывает 5 сущьностей подходящих под один стандарт, например модели.
Это как ГОСТ на гайки. Если любая гайка имеет 6 граней — это легко проверить одним автоматом, а вот если бы гайки имели разное количество граней — то на каждый тип граней пришлось бы делать разные проверяющие автоматы.
Идея имено в стандартах на сущьности и в том что это легко проверять, а не в том как мы применили эту идею к нашему проекту.
В нашем CI нет задачи проверки бизнес логики — как мы её проверяем — отдельная тема.
Задача этой схемы билда — проверка целостности, проверка того, что ничего не сломалось, то что раньше работало. Вот пример:
Если Вы будете искать ошибки вида «juniur не имплементировал абстракный метод в одном из потомков» функциональными тестами, то цена нахождения такой ошибки слишком велика — N минут разработчика на тест, для поиска ошибки сделанной за 0 минут. В нашем случае 0 минут разработки тестов, на тупую ошибку.
Моя задача не отказаться от тестирования, и не отказаться от код-ревью — задача передать тестировщикам рабочий код, чтобы они не занимались поиском фаталов, а проверяли бизнес логику. Конечная цель — стабильное приложение. Минимум косяков на проде, и не ценой замучанных регрессивными проверками QA :-)
Регрессивное тестирование — а у Вас есть 5 человек QA, которым Реально Приятно заниматься регрессивным тестированием? Уверен, что 90% QA такое не любят. А заставлять людей делать то что им неприятно — они делают это менее внимательно — вот еще минус к стабильности.
Про систему контроля версий и хук — а Вы серьезно думаете что я руками запускаю билды? Естественно нет. И точно не по хуку — более умным способом, чтобы не билдить каждый git push. Смысл есть билдить результат закрытого тикета, а не все что пушат. Билд нашего приложения длится 30 минут. Вот представьте, если пушат раз в минуту — за день наберется очередь билдов, которая будет разгребаться еще неделю!
Я тоже так считаю, ибо сломать старый функционал «случайно» — гораздо легче, чем написать новый баг, в новом функционале; ну с учетом того, что новый функционал пишут не левой ногой.
Жалуются татары в горком партии на фразу «незванный гость — хуже татарина», горком постановил говорить по новому: «Незванный гость — лучше татарина».
P.S. сам я татарин
Когда смотришь на эту сумму и суммарную потерю производительности (пока коннект устанавливается — живет процесс php и ждёт зря память безпольно, так же копятся еще не обработанные коннекты на nginx, и прочее) происходит ощущение что что то не так — переводишь на unix socket и «висящих» соединений становиться меньше, php отрабатывает быстрее, nginx меньше копит на себе соединений, да и вся конструкция может обработать больше запросов.
2. Кеширование зачастую не позоволяет избавится от всех запросов к базе (хотя и избавляет от 99% запросов с web), поэтому даже ради одного маленького запроса приходится открывать коннект.
Есть части которые не кешируются — api, кроны (их много и они очень активные и тяжелые), фоновые задачи в демонах.
К сведению на моем проекте, нагрузка не очень велика: между php и mysql около 15000 одновременных соединений в пики нагрузки (говнокода нет, коннекты закрываются нормально).
P.S. оверхед от прослойки вполне может быть ощутим, но его никто не мерял.
P.P.S. если знаете как заметать оверхед на прослойку — подскажите!
старый драйвер(mysql): 7.36 sec — 100 000 запросов — выборка в 10 строк, нагрузка на cpu: 54% от ядра 3.1GHz (процесс php), ram: 10m
новый драйвер(mysqlnd): 13.3 sec — 100 000 запросов — выборка в 10 строк, нагрузка на cpu: 74% от ядра 3.1GHz (процесс php), ram: 13m
в случае pdo стало хуже — медленне, больше ест cpu и памяти. пробовал на:
php5-mysqlnd (5.4.4-7)
debian: wheezy/sid
запускался код: