Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Кто что думает по поводу работы на Дельфи? Есть будущее? Стоит ли переходить на веб-интерфейсы — переводить проекты на php, например? И где сейчас найти программистов на Дельфи и пхп уровня хотя бы middle??? И можно ли использовать пхп для серверной части высоконагруженных проектов?
где можно посмотреть статистику кто на чем пишет в мире
Хотя, я бы лучше использовал ASP .NET MVC Framework. Больше возможностей, чёткое отделение бизнес-логики от елементов интерфейсов, работа c AJAX, масштабируемость. Да и, если захочется сделать всё красивенько, html-кодеров можно нанять подешевке ;)))
За некропостинг надо устраивать дефенестрацию!
Спасибо всем — было очень познавательно. Выводы сделаны.
Переходить с Делфи на PHP? Может лучше сразу в грузчики переквалифицироваться. Ну это... что б не плодить армию недо-быдлокодеров.
.NET вытеснила делфи из формошлепского сегмента. Но он по прежнему актуален там, где нужно тесное взаимодействие с системой (вирусы, антивирусы, игры, драйвера), особенно если вы выросли на паскале и не особо дружите с/c++. Правда в нашей стране таких областей немного. Работу найти достаточно трудно.
те кто до сих пор не перешел на Java, .Ner or PHP — тот динозавр и место ему на кладбище динозавров.
5) да, можно
Жесть то какая, делфи мертвее мертвого уже лет 8Переходите на дотнет для виндовс програмирования если нужно всякое системное и на веб если бизнесс приложение
Кстати, есть ещё плюсы и юникс, если системное нужно.
угу, знаю ембедщиков благополучно сьехавших на linux +arm с пк приложений
Да ладно?! Покажите? Только не тот что студент Вася поставил на свой старенький ноутбук на котором даже ХР уже не запускается.
Кто что думает по поводу работы на Дельфи?
Умерло оно лет
Есть будущее?
Нэт.
Стоит ли переходить на веб-интерфейсы
Нэт.
И где сейчас найти программистов на Дельфи и пхп уровня хотя бы middle???
В Гугле по запросу «резюме php».
И можно ли использовать пхп для серверной части высоконагруженных проектов?
Спросите разработчиков facebook, скорей всего ответят, что можно.
Спросите разработчиков facebook, скорей всего ответят, что можно.
Только нужно приделать комплиятор php в c++
не учил, но осуждаю...)))Кто что думает по поводу работы на Дельфи?
может, посмотреть на питон?
какбе делфи и питон это немного разное.какбе да,
Кстати, про веб-интерфейсы: stackparts.com
И можно ли использовать пхп для серверной части высоконагруженных проектов?
Перед любым бекендом можно поставить вменяемое кеширование, которое будет держать довольно большую нагрузку. Вопрос не корректен. Ответ: можно (также не корректен). Главный вопрос: что вы подразумеваете под высоконагруженным?
Не меньше 10000 одновременных запросов (соединений). Причем с доступом к базе, не все запросы можно кешировать.
Всё-таки запросов или соединений?
Если вы подразумеваете веб-проекты (читай сайты), то нагрузка чаще всего измеряется в запросах за секунду, не одновременных. В этом случае, если есть самоцель писать на пхп, то скорее всего, один сервер не потянет. Но выход всё-равно есть: сделать кластер http-серверов, спрятать за лоад-балансерами и кеширующими проксями, а базу всю в памяти держать. Только стоит учесть, что 10к запосов за секунду — величина, которая большинству веб-проектов может только сниться.
Если же вы говорите таки об одновременных соединениях, то, скорее всего, это будет какой-то демон, а не веб-приложение. В таком случае на пхп смотреть не стоит даже.
и кеширующими проксями,
И показывать юзерам неактуальную инфу?
базу всю в памяти держать.
А если не помещается? А если один сервачег не справляется?
купить еще три. Три дня оптимизаций всей командой обойдется дороже
И база сама волшебным способом размажется по серверам?
шардинг уже вроде как давно придумали
И как есть опыт поддержки и решардинга расжардженной рдбмс? Считаешь это простым делом которое займет меньше времени чем «Три дня оптимизаций всей командой»?
Поэтому даёшь планирование объёма данных и обеспечение серверов под шардинг заранее, чтобы не было проблем с решардингом
Документация вот говорит, что решардинг — болезненный процесс
Какая документация? Нету никакой документации, все пишут свои велосипеды, вон фейсбук на каждый шард поднимает отдельную базу, а что бы мувнуть шард дампит ее и поднимает в другом месте, и получается что на одном серваке держат тысячи и десятки тысяч баз, вот такие извраты.
Поэтому даёшь планирование объёма данных и обеспечение серверов под шардинг заранее, чтобы не было проблем с решардингом
основная причина решардинга не увеличение обьема данных а появление hot spots, чего никак не спрогнозируешь
Внутренняя.Какая документация?
hot spots
hot spots — в плане некоторых данных более востребованных, чем другие?
Внутренняя.
Опять же, что делать простым смертным?
hot spots — в плане некоторых данных более востребованных, чем другие?
В любых планах — востребованная, модифицируемая, расстущая.
если востребованная, то есть много чтений — спасают read-only слейвы. если записей намного больше, чем чтений, то есть смысл посмотреть на что-то кроме rdbms. ну а если растущая по объёму то таки шардинг
Опять же, что делать простым смертным?
Разве при 10kqps это всё ещё простой смертный?
ты такой теоретик:если востребованная, то есть много чтений — спасают read-only слейвы.
если репликация асинхронная, то тогда теряется консистенци при чтении со слейва, а если синхронная, то latency записать синхронно в 10 слейвов будет зашкаливать.
если записей намного больше, чем чтений, то есть смысл посмотреть на что-то кроме rdbms
Спасиба кеп, имя в студию!
ну а если растущая по объёму то таки шардинг
Я тебе уже про шардинг все написал
консистенци при чтении со слейва
но на слейвах же данные консистентны, т.к. реплицируются транзакциями? с задержкой только могут быть, да. при асинзронной другая проблема есть — если мастер умрёт между подтверждением комита клиенту и тем, как данные по слейвам расползутся, то тогда консистенция теряется. при 10 слейвах можно подтверждать транзакции после того, как они на
Спасиба кеп, имя в студию!
поиск по ключевым словам append-only storage?
но на слейвах же данные консистентны, т.к. реплицируются транзакциями?
Та проблем полно, например апликуха читает-читает, а потом решила что-то записать, переключилась с слейва на мастер, а там уже все по другому, и никакие локи и транзакции не спасают.
поиск по ключевым словам append-only storage?
И что, что то нашел?
апликуха читает-читает, а потом решила что-то записать
разве транзакции не для этого? Если хотите писать, базируясь на прочитанных данных — читайте сразу в транзакции с мастера
И что, что то нашел?
первые ссылки говорят redis и couchdb
разве транзакции не для этого? Если хотите писать, базируясь на прочитанных данных — читайте сразу в транзакции с мастера
То есть слейвы не спасают, ходим по кругу.
первые ссылки говорят redis и couchdb
redis не масштабируется из коробки, диван тормозной. Есть куча баз с быстрой записью: cassandra, mongo, hbase, но у всех у них есть свои проблемы, в основном из за молодости этой области.
нет конечно, это надо предусматривать за ранее. Случаи когда надо вчера так как попер посетитель и все стало раком- отдельная грусная песня — я думаю вы это знаете
а в базе держать не всё, а только то, что меняется часто, и не закешировано. ну и как ниже написано — шардинг от объема данных, мастер-слейв репликация от количества запросов.
можно кешировать отдельные редко меняющиеся части страницы.
И сколько такого например на этом сайте?
а в базе держать не всё, а только то, что меняется часто, и не закешировано.
А если как на нормальном сайте а не статической хоумпаге школьника меняется все?
шардинг от объема данных, мастер-слейв репликация от количества запросов.
Посоветуешь правильные средства которые все это поддерживают из коробки?
И сколько такого например на этом сайте
На этой странице, думаю кроме блока с баннерами и юзерского профайла можно при желании кешировать всё остальное, обновляя кеш при новых сообщениях. («21 час назад» заделать на клиенте)
А если как на нормальном сайте а не статической хоумпаге школьника меняется все?
несколько уровней кеша, которые кешируют различные данные по различным параметрам. начиная от кешей выборок из бд и до кешей отдельных отрендереных кусков html
Посоветуешь правильные средства которые все это поддерживают из коробки?
Вон, mysql говорят, с 5.1 поддерживает шардинг из коробки. Мастер-слейв тоже, вроде, умеет.
На этой странице, думаю кроме блока с баннерами и юзерского профайла можно при желании кешировать всё остальное, обновляя кеш при новых сообщениях. («21 час назад» заделать на клиенте)
То есть если представить себе что этот сайт вырос до обсуждаемых 10к qps, инвалидировать весь кеш приблизительно каждую 0.1 сек(из оптимистичного расчета что пользователи на 1000 просмотров оставляют 1 коммент), а если учесть что latency всех запросов будет оптимистично 0.5 сек, то половина запросов пройдет мимо кеша, ну если есть желание показывать юзерам свежую информацию конечно.
несколько уровней кеша, которые кешируют различные данные по различным параметрам. начиная от кешей выборок из бд и до кешей отдельных отрендереных кусков html
Бугога, юноша, скажи честно, у тебя есть опыт поддержки трехуровневого распределенного синхронизированного нагруженного кеша? Или так фантазируеш?
Вон, mysql говорят, с 5.1 поддерживает шардинг из коробки. Мастер-слейв тоже, вроде, умеет.
Если имеется в виду ndb то намного раньше чем 5.1., но это уже не привычный мскл а in memory db, типа выключили свет и все пропало, потому его и не юзает никто.
То есть если представить себе что этот сайт вырос до обсуждаемых 10к qps, инвалидировать весь кеш приблизительно каждую 0.1 сек(из оптимистичного расчета что пользователи на 1000 просмотров оставляют 1 коммент).
Совсем не понятны рассуждения. Во-первых комент, даже если оставляется каждые 0.1с, то зачем весь кеш инвалидировать? отрендерили одну страницу, засунули в кеш.
а если учесть что latency всех запросов будет оптимистично 0.5 сек
Это что за запросы? Это latency при обновлении данных? 0.5 сек, кстати, это ж дофига, чтобы записать комент и отрендерить страничку заново.
то половина запросов пройдет мимо кеша, ну если есть желание показывать юзерам свежую информацию конечно
В понимании большинства юзеров информация с задержкой в названные Вами 0.5с будет вполне свежей. В таком случае, если обновлять кеш отрендеренным значением, когда оно будет готово, но не трогать кеш пока новое значение готовится, то мимо кеша не пройдёт вообще ничего.
Бугога, юноша, скажи честно, у тебя есть опыт поддержки трехуровневого распределенного синхронизированного нагруженного кеша? Или так фантазируеш?
Фантазирую, вдохновлённый тем, как раздаётся реклама на некоторых крупнейших площадках интернета.
Если имеется в виду ndb то намного раньше чем 5.1., но это уже не привычный мскл а in memory db, типа выключили свет и все пропало, потому его и не юзает никто.
Не знаю, как работает из коробки. Видел, что если допилить, то работает хорошо.
Совсем не понятны рассуждения. Во-первых комент, даже если оставляется каждые 0.1с, то зачем весь кеш инвалидировать? отрендерили одну страницу, засунули в кеш.
Весь не надо, но будут инвалидироваться хот спотс на который идет большинство трафика. Ну и тебе нужно будет поддерживать логику постраничной инвалидации кеша, что подразумевает еще одну БД с немаленьким трафиком.
Это что за запросы? Это latency при обновлении данных? 0.5 сек, кстати, это ж дофига, чтобы записать комент и отрендерить страничку заново.
Ну как скажешь теоретик.
В понимании большинства юзеров информация с задержкой в названные Вами 0.5с будет вполне свежей. В таком случае, если обновлять кеш отрендеренным значением, когда оно будет готово, но не трогать кеш пока новое значение готовится, то мимо кеша не пройдёт вообще ничего
На форуме может быть, но форумами мир не ограничивается.
Фантазирую, вдохновлённый тем, как раздаётся реклама на некоторых крупнейших площадках интернета.
Думаю что твои фантазии не имеют места быть в реальном мире, а некоторые рекламные площадки для сервинга используют спагетти из Ц++ кода который держит все в памяти в стл контейнерах и никаких баз под низом не видно.
Не знаю, как работает из коробки. Видел, что если допилить, то работает хорошо.
Ну да, корпорация может тратить сотни миллионов долларов что бы десять лет педалить свой велосипед и патчить мскл, а как на счет топик стартера?
Это все «например» в ответ наНа форуме может быть, но форумами мир не ограничивается.
И сколько такого например на этом сайте?
---------
нужно будет поддерживать логику постраничной инвалидации кеша, что подразумевает еще одну БД с немаленьким трафиком.
В моём теоретическом представлении, достаточно бекенда, который постранично рендерит при обновлении контента, и засовывает результаты в memcached (размазанный, например на несколько машин). Где я упускаю необходимость ещё одной БД? (Я только учусь, мне интересно)
Ну да, корпорация может тратить сотни миллионов долларов что бы десять лет педалить свой велосипед и патчить мскл, а как на счет топик стартера?
Судя по тому, что он спрашивает про конкретные языки, а не про инструменты/субд которые сделают всё за него из коробки, то можно предположить, что он и так собирается свой велосипед пилить.
Это все «например» в ответ на: И сколько такого например на этом сайте?
Спасибо, я в курсе, веб теперь стал ограничиваться форумами, которые показывают юзерам устаревшую информацию?
В моём теоретическом представлении, достаточно бекенда, который постранично рендерит при обновлении контента, и засовывает результаты в memcached (размазанный, например на несколько машин). Где я упускаю необходимость ещё одной БД? (Я только учусь, мне интересно)
Очевидно что когда ты достаешь страницу из мемкеша тебе нужно понять актуальна ли она, или данные были изменены, для этого в записи в мемкеше обычно хранят время когда страница была изменена, и дополнительно держат бд с временем последнего изменения данных, и при доставании страницы из мемкеша их сравнивают.
предложенный выше подход редерит страницу не при запросе/чтении её клиентами, а при записи. Таким образом тригером к обновлению кеша и запуску процеса рендеринга будет один написавший юзер, а не 10к вломившихся после нового коментария. В этом случае страница в кеше всегда будет актуальной. (кроме задержки, после содания нового коментария, которую выжидает один пишущий клиент, а потом пушит новые данные в кеш)
Это опять теоретические фантазии. Если один чел сменил ник на этом форуме ты будешь инвалидировать и перезаписывать весь кеш? Или выполнять сложные запросы что бы найти только ветки/посты в которых он успел написать? К тому же обычно все в мемкеш не помещается, и туда складывают только самые горячие страницы, мой подход позволяет это сделать, твой нет.
Опять верно. Я не претендую на достоверность и эта дискуссия мне интересна т.к. надеюсь узнать чего-то новое о реальном мире highloada, с которым пока не приходилось работать непосредственно.Это опять теоретические фантазии.
Если один чел сменил ник на этом форуме ты будешь инвалидировать и перезаписывать весь кеш? Или выполнять сложные запросы что бы найти только ветки/посты в которых он успел написать? К тому же обычно все в мемкеш не помещается
если мне важны тонны qps, то буду по ночам переиндексировать всё. ну поставьте ещё мемкешей. они, насколько я понимаю, хорошо масштабируются.
мой подход позволяет это сделать, твой нет.
очевидно, да. но у него и предельный qps получится ниже. у каждого подхода есть свои «+» и «-», в связи с которыми можно выбирать подходящий исходя из конкретных условий.
то буду по ночам переиндексировать всё
То есть время неактуальности твоего кеша увеличивается с пары секунд уже до пока не проиндексируется?
у каждого подхода есть свои «+» и «-»
Подобные идеи еще имеют смысл на уровне бд, типа денормализации и преагрегации, но генерить туеву хучу мемкешед записей на каждый ивент это по меньшей мере странно.
Ну с MySQL не все так просто — это чудо умеет убегать от мастера даже в случае простой мастер-слейв репликации. Нужно использовать сторонние средства для мониторинга
на нынешнем проекте в пиковое время ~15-20 к selectoв в секунду (те что не кешируются, либо после сброса кеша)
но заслуг чисто php тут нет, продвинутое кеширование можно сделать на любом веб языке
Есть будущее?
Спрашивали лет 10 назад. Сегодня уже очевидно что будущего нет.
Стоит ли переходить на веб-интерфейсы — переводить проекты на php, например?
Смотря какой проект, если это какая-то закрытая система для комании и все работает, то зачем переводить?
И где сейчас найти программистов на Дельфи
Как по мне многиеуже переучились, стоит искать старшее поколение. Думаю недостатка кадров нет
И можно ли использовать пхп для серверной части высоконагруженных проектов?
Вконтакте и фейсбук намекают на то, что можно
Спрашивали лет 10 назад. Сегодня уже очевидно что будущего нет.
Версии Эмбаркадеро новые вроде как выходят, и даже проекты на нем пишут, вот Террасофт, например.
Действительность говорит, что тяжело с кадрами. Писать системное ПО под Win32/64.Думаю недостатка кадров нет
Пхпшники нужны хорошего уровня, не студенты.
Какие задачи хотите решать используя РНР ?
В большей части РНР идет в связке Linux, Apache, mySQL.
Координаты свои оставьте ;)
ТеррасофтНу... вот лично для меня репутация этой компании чуть выше чем у Амвея например.
Я думаю, чтобы не писать комментарий размером в статью, будет достаточно сказать что я бывший делфист а теперь уже почти с год как джавист.
Oleg Guskov
Viacheslav
Oleg Kotok
Bogdan Shyiak
spawn t
Хемуль
fizz buzz
Alex Svetlov
Нестор Иванович
Jenia Varavva
Нестор Иванович
Хемуль
Alexander Fedorov
Gremlin
Busted Gipsy
Gremlin
Jenia Varavva
reality_hacker
proger
Vadym Baranenko
Oleh Lytvynenko
Sergey Ponomarev
59 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів