Программист.
инфраструктурные потери в сотни (или даже тысячи?!!) милисекунд это ППЦ. Что-то там не такЛюбой веб-сайт с любой базой данных.
Про пул я там же и написал, а что, пхп уже научился с ним работать?
По поводу всего остального - запустите профайлер да посмотрите, сколько чего там занимает. "Подключение к базе" - достаточно сложная штука, там всякие нехорошие "контексты" и "сессии" создаются, да еще и "инициализации" дурацкие норовят запуститься.
По поводу всего остального - запустите профайлер да посмотрите, сколько чего там занимает. "Подключение к базе" - достаточно сложная штука, там всякие нехорошие "контексты" и "сессии" создаются, да еще и "инициализации" дурацкие норовят запуститься.
Как раз пишут что нельзя, а mysql_pconnect и пул - две разные вещи.
There is no connection pooling in php.
mysql_pconnect and connection pooling are two different things. There are many problems connected with mysql_pconnect and first you should read the manual and carefully use it, but this is not connection pooling.
Ну и так, положа грязную руку на потные яйца - сколько пхп-программистов вообще знают, что такое "connection pool"? А сколько из них дергают mysql_connect перед КАЖДЫМ запросом?
There is no connection pooling in php.
mysql_pconnect and connection pooling are two different things. There are many problems connected with mysql_pconnect and first you should read the manual and carefully use it, but this is not connection pooling.
Ну и так, положа грязную руку на потные яйца - сколько пхп-программистов вообще знают, что такое "connection pool"? А сколько из них дергают mysql_connect перед КАЖДЫМ запросом?
ну хотя бы некая эмуляция пула. Коннектиться к базе каждый раз это жестоко. Без понятия насчет среднего уровня пхп программистов, но что такое конекшн пул программист знать должен, а вот кто такой Касьянов нет
Пока утро...
1. Нету у ПХП (5.1) connection пула... по крайней мере я не нашел хде. Соединение (и много чего другого) создается каждый раз на каждый запрос... это действительно трабл... ну, скажем так, по мере изучения ПХП в связке с Мускулем постепенно узнаю, что "много чего нет", начиная с синтасксических диаграмм языка...
2. Потери на организацию старта обработки запроса, в т.ч. и по факту БД - конечно же не 30-50мс... поболе будут. Но! В этом, как раз и кроется острая необходимость оптимизации исходного кода! Упрощенно:
В стартовый код входит процесс аутентификации юзверя... было: 150кб (или около) только создаваемых структур и данных (рекорд - подкласс, дублированный 8 раз) и по профайлеру около 75мс только обработки и создания этого колхоза данных... зато ООП. Убрали... стало 5мс и 1.5кб данных.
Ещё раз, типовое рассуждение "нафига тут экономить... а! это свойство есть у этого класса... " приводит именно к такой структуре результата. Как пример стартовая инициализация Zend Framework по профайлеру отжирает около 10-15 МЕГАБАЙТ. Плюс время.
Это и есть причина потерь на соединение с БД... это и есть способ деградации отрасли... Копрокодерство уже настолько стало обычным делом, что его вонь уже никем по-просту незаметна...а кому-то даже приятна...
Скока, скока ресурсов требует Жаба-машинка тока для себя любимой? Скока-скока оперативки требует седьмая винда? А почто, практически то же самое у мене под OS/2 ходило в 4 мегах, а в 12 так даже летало?
На соединение с базой Mumps скока ресурсов треба? А времени уходит?
Так вот про ЭТО НЕЗНАНИЕ и нежелание узнать, я и пишу всю тему!!!
1. Нету у ПХП (5.1) connection пула... по крайней мере я не нашел хде. Соединение (и много чего другого) создается каждый раз на каждый запрос... это действительно трабл... ну, скажем так, по мере изучения ПХП в связке с Мускулем постепенно узнаю, что "много чего нет", начиная с синтасксических диаграмм языка...
2. Потери на организацию старта обработки запроса, в т.ч. и по факту БД - конечно же не 30-50мс... поболе будут. Но! В этом, как раз и кроется острая необходимость оптимизации исходного кода! Упрощенно:
В стартовый код входит процесс аутентификации юзверя... было: 150кб (или около) только создаваемых структур и данных (рекорд - подкласс, дублированный 8 раз) и по профайлеру около 75мс только обработки и создания этого колхоза данных... зато ООП. Убрали... стало 5мс и 1.5кб данных.
Ещё раз, типовое рассуждение "нафига тут экономить... а! это свойство есть у этого класса... " приводит именно к такой структуре результата. Как пример стартовая инициализация Zend Framework по профайлеру отжирает около 10-15 МЕГАБАЙТ. Плюс время.
Это и есть причина потерь на соединение с БД... это и есть способ деградации отрасли... Копрокодерство уже настолько стало обычным делом, что его вонь уже никем по-просту незаметна...а кому-то даже приятна...
Скока, скока ресурсов требует Жаба-машинка тока для себя любимой? Скока-скока оперативки требует седьмая винда? А почто, практически то же самое у мене под OS/2 ходило в 4 мегах, а в 12 так даже летало?
На соединение с базой Mumps скока ресурсов треба? А времени уходит?
Так вот про ЭТО НЕЗНАНИЕ и нежелание узнать, я и пишу всю тему!!!
Да, были времена ... Когда Zend Framework на 12 мегабайтах под OS/2 летал 
Ноныча оно не то что давеча ...
Ноныча оно не то что давеча ...
Моё мнение по статье - любую идею всегда можно довести до абсурда. Как хорошую, так и плохую. Любую. Даже эту.
или по-другому: "всё хорошо в меру". На практике (уже могу сравнивать): код писанный "как попало" главное запуск продакшн - "бабки наше фсё" приводит к тому, что из задуманного реализуется 2%... остальные силы уходят на патчинг багов вместо развития. Разумная (!) оптимизация кода и постоянный полезный (по мере развития) рефакторинг снижает потери времени на тестирование, сопровождение и высвобождает ресурсы на развитие. За последние 2 месяца по нашей команде сделано больше нового кода, чем таким же составом (даже чуть больше) 2 года назад примерно в 2 раза. При этом, попутно(!), улучшено качество того кода, который писался ранее. Это мнение руководства, ежели вчё. А оно, как понятно сильно влияет на з/п...
Проблема для таких "перфекционистов" в том, что не надо увлекаться в ущерб результату (правило 80/20 и здесь полезно), но и нельзя поддаваться давлению начальства "сделай залипуху, потом поправим"... не бывает этого "потом"! Потом - будет просто стыдно. И никакой опыт не покрывает вонь копрокодирования.
или по-другому: "всё хорошо в меру". На практике (уже могу сравнивать): код писанный "как попало" главное запуск продакшн - "бабки наше фсё" приводит к тому, что из задуманного реализуется 2%... остальные силы уходят на патчинг багов вместо развития. Разумная (!) оптимизация кода и постоянный полезный (по мере развития) рефакторинг снижает потери времени на тестирование, сопровождение и высвобождает ресурсы на развитие. За последние 2 месяца по нашей команде сделано больше нового кода, чем таким же составом (даже чуть больше) 2 года назад примерно в 2 раза. При этом, попутно(!), улучшено качество того кода, который писался ранее. Это мнение руководства, ежели вчё. А оно, как понятно сильно влияет на з/п...
Проблема для таких "перфекционистов" в том, что не надо увлекаться в ущерб результату (правило 80/20 и здесь полезно), но и нельзя поддаваться давлению начальства "сделай залипуху, потом поправим"... не бывает этого "потом"! Потом - будет просто стыдно. И никакой опыт не покрывает вонь копрокодирования.
Глупая шутка. Особенно, если внятно НЕ сможете объяснить чего такого ядро семерки делает, чего не делала Os/2... то бишь на что потрачены мегабайты и гигагерцы...
Ну это надо смотреть, откуда ноги растут у этого колхоза. А то бывает, что заказчик (или программист, зависит) хочет всего и сразу, и наворачивает такую развесистую клюкву на аутентификацию/авторизацию, что аж диву даешься. И роли тут, и категории, и группы, и раздельный доступ до каждой кнопки... Потом из этого зоопарка максимум 10-15% используется.
На сегодняшний день, когда в среднестатистическом десктопе стоит два гигабайта памяти - копейки. Зато сразу - кроссплатформенность, отсутствие "тупых" проблем с утечками памяти и кривыми указателями (в плюсах сплошь и рядом - "вчера работало, сегодня упало, завтра опять работает", ах ты ж, память освободили а указатель не занулили), устойчивость к атакам на переполнение буфера. Ну и скорость разработки в разы выше, конечно.
А сколько ресурсов треба, чтобы в иерархической БД написать простенький запрос табличек на десять, с сортировками, группировками и агрегатными функциями? Ну так, отчетик пользователи просят.
Дык работает же? И программисты стоят по десять баксов за пучок. А то пойдёшь, бывалоча, к ЗНАЮЩИМ, получишь от них счёт миллиона на полтора-два, и ищешь где бы верёвку украсть и мыло подешевле купить.
Всё нормально, законы рынка: "как заплачено - так и за%%%ячено".
На сегодняшний день, когда в среднестатистическом десктопе стоит два гигабайта памяти - копейки. Зато сразу - кроссплатформенность, отсутствие "тупых" проблем с утечками памяти и кривыми указателями (в плюсах сплошь и рядом - "вчера работало, сегодня упало, завтра опять работает", ах ты ж, память освободили а указатель не занулили), устойчивость к атакам на переполнение буфера. Ну и скорость разработки в разы выше, конечно.
А сколько ресурсов треба, чтобы в иерархической БД написать простенький запрос табличек на десять, с сортировками, группировками и агрегатными функциями? Ну так, отчетик пользователи просят.
Дык работает же? И программисты стоят по десять баксов за пучок. А то пойдёшь, бывалоча, к ЗНАЮЩИМ, получишь от них счёт миллиона на полтора-два, и ищешь где бы верёвку украсть и мыло подешевле купить.
Всё нормально, законы рынка: "как заплачено - так и за%%%ячено".
Да!
Приятно встретить знающего человека
Приятно встретить знающего человека
Модненький и новенький он у тех, кто не имеет своего мнения.
Эти базы всегда были, есть и будут. Ровно как и RDBMS никуда не пропадут. 10-100 табличек можно сделать на чём угодно. Мозг приходит, когда дело к 500-1000 подбирается. Опять же не говорю, что на таком объёме нужно выбирать обязательно NoSQL. Всё задачей диктуется.
И, кстати, Вам ли не знать, что Oracle-таки выпустил свой крючок на эту тему
Эти базы всегда были, есть и будут. Ровно как и RDBMS никуда не пропадут. 10-100 табличек можно сделать на чём угодно. Мозг приходит, когда дело к 500-1000 подбирается. Опять же не говорю, что на таком объёме нужно выбирать обязательно NoSQL. Всё задачей диктуется.
И, кстати, Вам ли не знать, что Oracle-таки выпустил свой крючок на эту тему
Глупая шутка. Особенно, если внятно НЕ сможете объяснить чего такого ядро семерки делает, чего не делала Os/2... то бишь на что потрачены мегабайты и гигагерцы...ядро 7-ки оч. шустрое, само ядро, но вот графические финтифлюшки в user mode написаны бездарно, криво, присунуты сбоку, причем начиная с ХП. Кроме того модель/парадигма винды позволяет в ядро запихивать целые приложения, что всяко не способствует производительности.
Я, перед тем, как выложить свой отрывочек, прогнал его и увидел прирост производительности.речь была, что оптимизация и читабельность не часто коррелируют, сам так же предпочитаю писать, пусть оптимизят процы, делают компиляторы с интерпретаторами более умными, но я голову ломать не хочу читая код, пусть мой код будет читабельным. Нужно же было мне на какой-то пример сослаться, а тут вы.
Приведите свой пример с учётом Ваших знаний очередей команд в процессоре, потрохов php и компилирующих интерпретаторов.
зы. отдельная, вне всей системы, прогонка в профайлере сейчас стала не всегда осмысленной, слишком все сайчас слишком умное, да и учесть все входные условия сложно, например сложно при разработке учесть что дизайнер вместо того чтобы просто выключить анимацию, установит такие параметры задержек, что ее не будет видно, но ресурсы на нее все равно будут тратиться, причем именно ради оптимизации.
Согласен
Когда начинаешь выбирать среди этих NoSQL, то становится понятно, что не всё так радужно и годятся они только для продвинутых форумов - соц.сетей.
Монго уж точно. Гляньте CouchDB. Там есть view для отчётов
Когда начинаешь выбирать среди этих NoSQL, то становится понятно, что не всё так радужно и годятся они только для продвинутых форумов - соц.сетей.
Монго уж точно. Гляньте CouchDB. Там есть view для отчётов
Посмотрел. Не совсем, больше даже совсем не... и в конце-концов... начиналось оно без меня совсем...
То, что у нас есть - не есть типовой интернет магазин. То что из этого делается - пока умолчу, можна?
Вот взял бы архитектор за основу NoSQL (хоть тот же Mumps) - было бы намного легше жить... а так приходится из реляционных таблиц городить запросы на 5-15 таблиц, да по нескольку, да потом ещё и в иерархический формат в циклах переколбашивать... благо таблички ещё не самые большие... так записей на 300 тысяч...
Фсё. перекур...
То, что у нас есть - не есть типовой интернет магазин. То что из этого делается - пока умолчу, можна?
Вот взял бы архитектор за основу NoSQL (хоть тот же Mumps) - было бы намного легше жить... а так приходится из реляционных таблиц городить запросы на 5-15 таблиц, да по нескольку, да потом ещё и в иерархический формат в циклах переколбашивать... благо таблички ещё не самые большие... так записей на 300 тысяч...
Фсё. перекур...
У этой (и люболй другой аналогично, в том числе и известных продакшн типа виндовс) ноги растут из того же самого места ...
...это "копрокодер" - типа прогер, которому на результат своего труда начхать лишь бы платили, а не то что подумалось.
"Это" == работает?!? и где Вы программистов по 10 баксов за пучок берете? О том и тема, что им реальная цена именно такова и есть...
...
это "копрокодер" - типа прогер, которому на результат своего труда начхать лишь бы платили, а не то что подумалось."Это" == работает?!? и где Вы программистов по 10 баксов за пучок берете? О том и тема, что им реальная цена именно такова и есть...
постойте, постойте... эт-та! А как же "прогресс"? Может все-таки нормальная такая "копродеградация"?
Посмотрел. Не совсем, больше даже совсем не... и в конце-концов... начиналось оно без меня совсем...Milo - это, скорее, поисковый движок, а не магазин. "Сижу на площади ленина, ищу где бы поблизости купить (в обычном магазине, не онлайновом) славянский шкаф". Т.е. та самая загрузка прайсов со всех продавцов, парсинг и каталогизация. А в потрохах у него - Lucene, Hadoop и Map/Reduce. Тут можно с блогом разработчика ознакомиться, интересное чтиво.
У этой (и люболй другой аналогично, в том числе и известных продакшн типа виндовс) ноги растут из того же самого места ...По-разному бывает.
Конечно работает. Сайты вон строятся, дела идут, конторы пишуть. А "реальная цена" - понятие очень расплывчатое. Я вот считаю, что в Новосибирске двухкомнатной квартире в панельном доме "реальная цена" не более 15000 долларов - с учетом качества постройки, звукоизоляции (точнее - ее отсутствия), экологической ситуации и отвратительного климата. Ну да кто ж меня послушает?
говорюже ядро нормальное, но вот на user interface-е они оторвались
говорюже ядро нормальное, но вот на user interface-е они оторвалисьХмм...
А как Вы тестировали ядро без UI ?
Глупая шутка. Особенно, если внятно НЕ сможете объяснить чего такого ядро семерки делает, чего не делала Os/2... то бишь на что потрачены мегабайты и гигагерцы...Само собой на проверки входных параметров
*продолжает глупо шутить*Вот с этим я бы совсем согласился, если "99%" заменить на "90%". А лучше даже на "80%".
Интересный вопрос. А чем сферический новосибирский тимлид или менеджер отличается от западного?
Мне казалось, что это должен быть просто продвинутый разработчик с коммуникативными навыками, с большей (моральной) ответственностью за общее дело, ну и способный организовать процесс той самой разработки с участием разноквалифицированных ребят.
Если в Новосибирске присутствуют организации с поставленным процессом (а такие, вроде бы, есть - взять хотя бы Большие Компании или нескольких относительно крупных аутсорсеров), то под влиянием этого процесса неизбежно часть разработчиков со временем будет превращаться в тимлидов и менеджеров.
То есть на смену уехавшим будет приходить новое поколение, разве нет?
Кстати, а Вы на какую позицию уехали (почему-то мне кажется, что на менеджерские позиции поначалу попасть трудно)?
Хм. А что можно приобрести на западе за деньги? Кусок свободы и демократии?
(Ваши слова про нормальную жизнь мне очень даже понятны.)
Интересный вопрос. А чем сферический новосибирский тимлид или менеджер отличается от западного?
Мне казалось, что это должен быть просто продвинутый разработчик с коммуникативными навыками, с большей (моральной) ответственностью за общее дело, ну и способный организовать процесс той самой разработки с участием разноквалифицированных ребят.
Если в Новосибирске присутствуют организации с поставленным процессом (а такие, вроде бы, есть - взять хотя бы Большие Компании или нескольких относительно крупных аутсорсеров), то под влиянием этого процесса неизбежно часть разработчиков со временем будет превращаться в тимлидов и менеджеров.
То есть на смену уехавшим будет приходить новое поколение, разве нет?
Кстати, а Вы на какую позицию уехали (почему-то мне кажется, что на менеджерские позиции поначалу попасть трудно)?
Хм. А что можно приобрести на западе за деньги? Кусок свободы и демократии
?(Ваши слова про нормальную жизнь мне очень даже понятны.)
Ага, давайте итерационно. С расчетами по Москве в целом согласен. Продолжу с Европой и США.
1. Европа.
Имеет смысл рассчитывать на 3-3.5 тыс. евро в месяц чистыми на руки.
Минус 1 тыс. евро на съем квартиры, минус неработающая жена. Формально остается 2-2.5 тыс. евро или 80-100 тр. Но учитывая покупательную способность евро, я бы сопоставил эту сумму с новосибирскими 50-60 тр.
То есть реально те же самые 80 тр.
2. США/Канада.
Если оценивать по паритету покупательной способности на уровне 20 рублей за доллар, то $100K превращаются в 2 млн. рублей. Или примерно 150 тр в месяц.
Черт возьми, думаю, здесь на форуме действительно сплошные неудачники
1. Европа.
Имеет смысл рассчитывать на 3-3.5 тыс. евро в месяц чистыми на руки.
Минус 1 тыс. евро на съем квартиры, минус неработающая жена. Формально остается 2-2.5 тыс. евро или 80-100 тр. Но учитывая покупательную способность евро, я бы сопоставил эту сумму с новосибирскими 50-60 тр.
То есть реально те же самые 80 тр.
2. США/Канада.
Если оценивать по паритету покупательной способности на уровне 20 рублей за доллар, то $100K превращаются в 2 млн. рублей. Или примерно 150 тр в месяц.
Черт возьми, думаю, здесь на форуме действительно сплошные неудачники