Comments 105
Эх, зря всё это. Подобная тяга к оптимизации не способствует производительности разработчика. Вместо того, чтобы нагружать сервер и клиент аяксом, лучше использовать server-push технологии, а для хранения и быстрого доступа к данным — memcached. Есть множество ситуаций, когда приходится писать на си/си++. Но то, что вы описали — не совсем те задачи.
А приведите, пожалуйста. примеры задач, по Вашему, которые нужно реализовывать используя C++?
Например, есть системы с таким потоком информации, когда невозможно всю поступающую информацию писать в базу данных. Пишется демон на си, который принимает всю эту информацию и выстраивает очередь, а затем уже медленно, но верно пишет из очереди в базу.
А я делал MEMORY таблицу (в памяти) и периодически сбрасывал её в MyISAM таблицу. Поток информации был очень большой, но все работало как часы.
Не совсем понял, к чему этот комментарий. Чем сбрасывали? База в памяти — это хороший вариант, но я ту же картину и описал. В моём случае этим занимался демон.
Какая разница чем? Вы написали «когда невозможно всю поступающую информацию писать в базу данных». А я говорю, что вполне возможно.
Сначала я тоже пробовал использовать демона (писал на чистейших Сях). Да, он работает быстрее, но на другом порту, что в некоторых случаях вызывает определенные трудности по части JS. В результате с моей задачей прекрасно справился PHP скрипт, который писал данные в MEMORY таблицу.
ИМХО так даже лучше. При нужде данными из MEMORY таблицы можно не напрягаясь оперировать в скриптах, демонах, приложениях, etc.
Сначала я тоже пробовал использовать демона (писал на чистейших Сях). Да, он работает быстрее, но на другом порту, что в некоторых случаях вызывает определенные трудности по части JS. В результате с моей задачей прекрасно справился PHP скрипт, который писал данные в MEMORY таблицу.
ИМХО так даже лучше. При нужде данными из MEMORY таблицы можно не напрягаясь оперировать в скриптах, демонах, приложениях, etc.
Нет, я говорил о том же самом. Сходу всю поступающую информацию писать в базу не получится — база загнётся. Приходится её писать в память или на винчестер. А кто принимает её и пишет или кто её потом сбрасывает в бд — уже не так важно и зависит от необходимой пропускной способности всей системы. Я решил, что это демон на сях, а Вы — что скрипт пхп.
stfalcon говорит про In-Memory Database. Это уже готовое и качественное решение, с точки зрения программы ничем не отличающееся от File-Storage Database. Речь о том, что не надо изобретать свой волесипед, можно взять готовый — работающий гарантированно качественнее и быстрее, чем напишете вы (за разумный срок).
А зачем на другом порту? Провесили бы через какой-нибудь nginx по определенному урлу на демон.
это сработает только в случае кратковременных скачков объемов поступающих данных.
а если постоянно данные идут со скоростью большей, чем может записать база, то это не сработает ведь.
а если постоянно данные идут со скоростью большей, чем может записать база, то это не сработает ведь.
Это не про поиски «самого редкого слова в Интернете»? :)
А ваш первый запрос работает быстрее чем DESC LIMIT 10?
«DESC LIMIT 10» сначала отсортирует все строки таблицы (1000, 10000 или сколько их там) и из них возьмет 10; а «id>MAX(id)» возьмет 10 элементов и их отсортирует. По крайней мере обычно так происходит. Ну только там "… WHERE id>(SELECT MAX(id) FROM table)-20 ORDER BY id DESC LIMIT 10" ибо бывают удаленные элементы и если сделать -10 — то их может меньше 10 в конце получиться.
UFO just landed and posted this here
зато у постгресса будет пухнуть таблица от постоянных добавлений/удалений
В любом случае синхриться с основным хранилищем нужно, но делать это можно и периодически, а такая вот штука на cpp реально должна быть на переднем крае.
Между прочим, есть инструменты, которые позволяют генерировать код на cpp из кода на других языках. Это может координально упростить задачу.
Между прочим, есть инструменты, которые позволяют генерировать код на cpp из кода на других языках. Это может координально упростить задачу.
UFO just landed and posted this here
не известно как оно себя поведет при пиковой нагрузке, нужно экспериментировать и настраивать.
UFO just landed and posted this here
Vacuum в что называется конфликтует с нормальными запросами — на таблице может работать или vacuum, или insert/update/delete (про select не уверен). Если идет большой поток обновляющих запросов, то при работе vacuum они будут вставать в очередь, а потом ломиться на исполнение всей пачкой. Так что тут важно точно угадать с периодом запуска vacuum.
Лично у меня от работы с постгрессом сложилось впечатление что для задач с большим потоком INSERT/DELETE он плохо подходит.
Лично у меня от работы с постгрессом сложилось впечатление что для задач с большим потоком INSERT/DELETE он плохо подходит.
UFO just landed and posted this here
Прочтите наконец мануал.
Exclusive lock накладывается *только* при vacuum full.
Про delete/insert. Ну если у вас версионник плохо подходит для задач с большим количеством модифицирующих запросов, тогда даже и не знаю, что вы нам тут еще «откроете» инетресного, ждем :-)
Exclusive lock накладывается *только* при vacuum full.
Про delete/insert. Ну если у вас версионник плохо подходит для задач с большим количеством модифицирующих запросов, тогда даже и не знаю, что вы нам тут еще «откроете» инетресного, ждем :-)
> Exclusive lock накладывается *только* при vacuum full.
Для этого не надо читать мануал — достаточно попробовать на нагруженной базе. Да, обычный vacuum значительно «гуманнее» vacuum full, но он не проходит незаметным.
> Ну если у вас версионник плохо подходит для задач с большим количеством модифицирующих запросов, тогда даже и не знаю, что вы нам тут еще «откроете» инетресного, ждем :-)
Большой поток обновляющих запросов вызывает массу проблем у версионника, особенно при наличии индексов
Для этого не надо читать мануал — достаточно попробовать на нагруженной базе. Да, обычный vacuum значительно «гуманнее» vacuum full, но он не проходит незаметным.
> Ну если у вас версионник плохо подходит для задач с большим количеством модифицирующих запросов, тогда даже и не знаю, что вы нам тут еще «откроете» инетресного, ждем :-)
Большой поток обновляющих запросов вызывает массу проблем у версионника, особенно при наличии индексов
Конечно, манулы для трусов!
У меня есть опыт трех проектов где были таблицы с интенсивными вставками(100-500 insert/sec). Auto vacuum работал. Иногда по крону запускался full(когда нагрузка была минимальной).
Зачем запускать иногда full можно узнать снова в мане.
И про версионник. Может быть как-то обоснуете свою точку зрения? Например, можно начать с обсуждения причем тут индексы, на примере postgres.
И второе. Какая по вашему архитекура бд подходит для таких случаев больше?
p.s. Пробовать надо на кошках. А когда у вас проект запущен и есть высокие нагрузки, нужно знать что делаешь или хотя бы начать с чтения мана.
У меня есть опыт трех проектов где были таблицы с интенсивными вставками(100-500 insert/sec). Auto vacuum работал. Иногда по крону запускался full(когда нагрузка была минимальной).
Зачем запускать иногда full можно узнать снова в мане.
И про версионник. Может быть как-то обоснуете свою точку зрения? Например, можно начать с обсуждения причем тут индексы, на примере postgres.
И второе. Какая по вашему архитекура бд подходит для таких случаев больше?
p.s. Пробовать надо на кошках. А когда у вас проект запущен и есть высокие нагрузки, нужно знать что делаешь или хотя бы начать с чтения мана.
На нагруженных базах full вообще не делают т.к. это вызывает недоступность сервера на значительное время (например на linux.org.ru full работает более 10 минут, а база там маленькая по большому счету). Реальная выгода от него только если от update'ов база пухнет в разы, но это для постгресса в любом случае крайне плохая ситуация.
Insert'ы, ясное дело, не добавляют работы vacuum'у — вопрос в числе UPDATE/DELETE. Кстати в постгрессе update любого поля в строке (кортеже) вызывает создание новой версии всей строки с обновлением индексов по всем полям. Новые постгрессы научились этого не делать если удается найти место в том же блоке на диске, и на том спасибо.
На практике беда мультиверсионности в возможности сильного распухания базы при большом числе обновлений. Индексы растут вместе с данными базы, поскольку они содержит ссылки на все версии пока их не почистит vacuum.
Признак простой — если база сильно вырастает в процессе работы, то или она организована плохо, или задача не для нее. Особенно плохо если база после в процессе роста перестает помещаться в оперативную память, а если индекс перестает — то вообще беда (этого, кстати не так сложно добиться если использовать полнотекстовый поиск с gin-индексами).
Insert'ы, ясное дело, не добавляют работы vacuum'у — вопрос в числе UPDATE/DELETE. Кстати в постгрессе update любого поля в строке (кортеже) вызывает создание новой версии всей строки с обновлением индексов по всем полям. Новые постгрессы научились этого не делать если удается найти место в том же блоке на диске, и на том спасибо.
На практике беда мультиверсионности в возможности сильного распухания базы при большом числе обновлений. Индексы растут вместе с данными базы, поскольку они содержит ссылки на все версии пока их не почистит vacuum.
Признак простой — если база сильно вырастает в процессе работы, то или она организована плохо, или задача не для нее. Особенно плохо если база после в процессе роста перестает помещаться в оперативную память, а если индекс перестает — то вообще беда (этого, кстати не так сложно добиться если использовать полнотекстовый поиск с gin-индексами).
Про базу в памяти и про то как устроены версионники в принципе, все знают.
Много update — это отдельная песня. Часто много update меняется на много insert и агрегат. Но мы же не об этом :-)
Я не увидел в вашем комменте ни ответов на вопросы, ни того, почему же vacuum зло. Full можно делать только, если есть время для него(например, ночью), а если нет, то можно придумать схему просто с созданием новой таблицы и заменой старой на оную.
А главное, где альтернатива-то?
Много update — это отдельная песня. Часто много update меняется на много insert и агрегат. Но мы же не об этом :-)
Я не увидел в вашем комменте ни ответов на вопросы, ни того, почему же vacuum зло. Full можно делать только, если есть время для него(например, ночью), а если нет, то можно придумать схему просто с созданием новой таблицы и заменой старой на оную.
А главное, где альтернатива-то?
А почему 20, а не 30, не 100? :) Какое бы ни было число, может < 10 получиться с таким подходом. Ненадежно.
Потому что я больше инженер, чем математик.
Допустим -20 будет достаточно в 99% случаев, так зачем же в 5 раз увеличивать объем работы сервера для обработки 1% случаев?
Да и -20 это эмпирическая величиная, которую в зависимости от проекта меняю. Если там явно будет большая разреженность данных — она будет больше, а если там удаляться будет 1 из 100 записей — то может и вообще 11 сделаю.
Допустим -20 будет достаточно в 99% случаев, так зачем же в 5 раз увеличивать объем работы сервера для обработки 1% случаев?
Да и -20 это эмпирическая величиная, которую в зависимости от проекта меняю. Если там явно будет большая разреженность данных — она будет больше, а если там удаляться будет 1 из 100 записей — то может и вообще 11 сделаю.
Отсортирует? А индексы? Вот боюсь что ваш МАКС как раз работал печально, но если сделаете BTREE индекс по своему полю (id), то выбирать он будет достаточно быстро.
В общем и целом, с топиком согласен, но это конкретное место вызвало недоверие.
В общем и целом, с топиком согласен, но это конкретное место вызвало недоверие.
И кстате, про мемкеш: сколько, если не секрет, запросов положили это решение и при каких условиях?
Мне видится из опытов/экспериментов, что за два обращения к мемкешу (первый за макс айди, второй мультигет за данными собственно) может выстоять ой как много запросов в секунду (правда, надежность тут соснет – в теории мемкеш может и дропать ключики тоже… Ну это так, мысли вслух)
Мне видится из опытов/экспериментов, что за два обращения к мемкешу (первый за макс айди, второй мультигет за данными собственно) может выстоять ой как много запросов в секунду (правда, надежность тут соснет – в теории мемкеш может и дропать ключики тоже… Ну это так, мысли вслух)
Да с мемкэшем-то все в порядке — лошадь та еще, если б к нему только обращения шли, но ведь они идут к апачу, апач к пхп, пхп к мемкэшу. Вот та часть, что не-мемкэш и клала все.
А пхп под байткод-акселератором? А вместо апача что-нибудь полегче пробовали?
Тут вот предлагалось множество решений, но поставить-настроить-протестировать что-нибудь вместо апача, добавить проксирующие nginx'ы, и всё прочее в том же духе займёт не меньше времени, чем заняло у автора то, что он сделал (2-3 часа), а эффективность решения точно будет ниже (гораздо больше оверхеда).
У нас в проекте данные напрямую не удалялись из базы. Просто в таблицу добавлялось поле activity. Если надо удалить — там выставлялся нолик. Соответственно, не возникало таких проблем. Ну а сделано это было, как говорило начальство, из-за того, что при удалении данных из БД посредством DELETE мы можем получить довольно-таки фрагментированный файл, что отразится на скорости доступа к данным.
Ага, а то что база будет расти это ничего? :-)
man vacuum.
man vacuum.
На самом деле kenga прав(а?) — для больших систем гораздо лучше флаг is_deleted — по очень многим причинам (и фрагментированность файла, и потенциальная возможность восстановления, и последовательность чтения и т.п. т.п. т.п.). Ну и да что-то типа алгоритмов vacuum'а применяется тоже иногда.
Прав ;-)
Как только база перестает помещаться в память, с ней начинаются серьезные проблемы. Поэтому нужно стремиться удалять все данные, которые можно удалить или перемещать в архивные таблицы, которые не учавствуют в OLTP-приложении.
Проблема возникнет не тогда, когда база не будет помещаться в память, а когда индексы перестанут туда помещаться. При грамотном проектировании это не должно случиться.
ЭЭ, в случае с pg это все равно, так как кэшируются и страницы данных и индексы.
p.s. Я немного сбился с ветки обсуждения. Пишу все применительно к pg.
p.s. Я немного сбился с ветки обсуждения. Пишу все применительно к pg.
Я заметил, что вы pg. Я же, к сожалению, с этой бд не работал. Так что у меня не получится вести с вами диалог ;-)
Хотя то, что я точно знаю, что pg поддерживает очень вкусные режими репликации. Так что балансировать нагрузку на этой БД не так уже и сложно, если возникнет в этом потребность из-за разросшейся бд.
Не обязательно делать это при каждом запросе. Лучше асинхронно, а при запросе помечать тем же флажком.
1. Индексы рулят
2. Как только добавляешь вычисления в SELECT, производительность мускля сразу падает, он индексом не будет пользоваться
3. Подзапросы в Мускле сверхмеганеоптимальные, поэтому WHERE id>(SELECT MAX(id) FROM table)-20 — это пипец
© «High Performance MySQL»
2. Как только добавляешь вычисления в SELECT, производительность мускля сразу падает, он индексом не будет пользоваться
3. Подзапросы в Мускле сверхмеганеоптимальные, поэтому WHERE id>(SELECT MAX(id) FROM table)-20 — это пипец
© «High Performance MySQL»
про заморочки:
1. Напишите для демона обертку, которая будет перезагружать его, если потребуется
2.Написать программу на C++ можно и так, что бы не перезагружать ее если возникнет надобность. Так многие демоны в *nix работают
1. Напишите для демона обертку, которая будет перезагружать его, если потребуется
2.Написать программу на C++ можно и так, что бы не перезагружать ее если возникнет надобность. Так многие демоны в *nix работают
1. это называется врапер — простой шел-скрипт в цикле запускающий программу на случай ее падения
2. часто более правильный вариант — написать модуль для nginx, это не очень сложно, но там уже чистый си без ++
2. часто более правильный вариант — написать модуль для nginx, это не очень сложно, но там уже чистый си без ++
ого,10 дней мой коментарий был безответен.
Про первый коментарий не понял — чем Ваше замечание отличается от моего?
Про второе не понял — nginx есть далеко не у всех, да и кажется автор не об этом речь вел совсем
Про первый коментарий не понял — чем Ваше замечание отличается от моего?
Про второе не понял — nginx есть далеко не у всех, да и кажется автор не об этом речь вел совсем
1. просто уточнение, из вашего комментария не совсем ясно как эту обертку следует делать
2. у автора есть задача — переписать критичный кусок кода на С, куда положить вроде неважно, поэтому я упомянул что код можно сделать не только в виде отдельного демона но и в виде модуля/патча к nginx/apache для обоих существуют образцы модулей из которых helloworld делается за 3 минуты, это позволяет использовать уже готовую инфраструктуру (логи, конфиги и т.п.)
2. у автора есть задача — переписать критичный кусок кода на С, куда положить вроде неважно, поэтому я упомянул что код можно сделать не только в виде отдельного демона но и в виде модуля/патча к nginx/apache для обоих существуют образцы модулей из которых helloworld делается за 3 минуты, это позволяет использовать уже готовую инфраструктуру (логи, конфиги и т.п.)
В любом случае, вам будет очень сложно обойтись без БД. Единственное, чем может спасти такой подход — операции чтения будут происходить из памяти вашего приложения на c++. Если вы не будете писать все данные в базу/файл при первом же ребуте настанет что-то нехорошее ((=
Про БД — не спорю. Вопрос в том, что скинуть в базу данные раз в 10 минут — снизит нагрузку в, может быть, и миллионы раз. А вот скрипт, который как только закончил свою работу — так его данные garbage collector сразу и подчистил — такого не сможет. Но, аргумент — верный.
Мне вот интересно еще, из-за чего в вашем случае начал помирать подход с memcached???
А почему именно C++, а не java, D, erlang, ...?
C++ последнее время на хабре стал трендом
Ну про почему не D или не Java — не знаю, а вот против Erlanga мало чего имею. Кроме как… Была у нас тут дискуссия на Hacker News на тему того почему бы сайты на Lisp'е не делать. Аргумент, который лучше всего прозвучал — найти того, кто будет писать на C++ несравнимо проще, чем уберхакера, который хорош знает Lisp, чтобы это поддерживать. А, к сожалению, хороший персонал — главный головняк почти всех фирм (в Москве, по крайней мере, знаю точно).
Сайты на lisp — шиза, но ведь и плюсы — не подарок:) Надо искать того, кто будет не просто писать на C++, а делать это осмысленно и крайне аккуратно. Иначе не просто прострелит себе ногу, а устроит взрыв кишки в стену расчлененку и т.д.
Впрочем, наверняка на hacker news все это тоже уже обсуждалось.
Впрочем, наверняка на hacker news все это тоже уже обсуждалось.
С нуля до комфортного ощущения в Эрланге — 2 недели. Кто-то типа Nokia или Motorolla замеряли
«Если честно, я в C++ разбираюсь как хакер в женских помадах — как и многие, я большей частью использую PHP (и все больше Python, но его редко для веба — больше для OpenGL), но тем не менее это не мешает мне его(C++) использовать.»
вот на этой фразе я окончательно определился с сортом травы автора и не смог больше заставить себя прочитать статью дальше
вот на этой фразе я окончательно определился с сортом травы автора и не смог больше заставить себя прочитать статью дальше
Слушайте, кроме примера с поиском по IP — ведь можно хранить данные в кеше типа Memcached/APC (елси сервер 1), это ж эффективнее базы, но не требует возни с Си, утечками памяти и прочей мутью.
memcached вообще изначально сильно масштабируемое решение. Оно и придумано для того, чтобы данные можно было хранить на целом кластере серверов.
Во-первых, в C++ гораздо сложнее организовать утечки памяти, чем в С. Решение-то было на C++. Мне это утечки чаще удается в Python сделать, чем в C++.
> в кеше типа Memcached/APC
Или уж в настоящей key-value базе типа Tokyo Cabinet (1 миллион запросов в секунду реально дает)
Или уж в настоящей key-value базе типа Tokyo Cabinet (1 миллион запросов в секунду реально дает)
На C/C++ в проекте реализовано несколько частей, например считалка уникальных IP. PHP скрипт пишет в файл binary-лог обращений (id объекта, ip пользователя). А программа на C++ раз в пять минут вызывается и парсит весь лог за текущий день, в памяти строит B* дерево и подсчитывает количество уникальных обращений к каждому объекту за сутки. Сейчас это около 50000 обращений в сумме. Раньше это делалось с помощью MySQL и безбожно тормозило…
Второй пример — простой счетчик хитов. Опять же все данные храняться в памяти в деревьях, а по крону раз в несколько минут сбрасываются в MySQL с помощью PHP скрипта. Написано как FastCGI приложение, работает в связке с Nginx.
По вашей статье — тут можно было бы гораздо проще решить проблему с выводом последних n сообщений, но как пример для статьи — самый раз.
А по поводу упоминаемой вами библиотеки — WebToolKit — абсолютно не понравилась идея прикручивать самописный Web-сервер. С ним могут быть как проблемы с произодительностью, так и с безопасностью. Кто знает, сколько там может быть переполнений буфера или утечек памяти? Лучше уж использовать проверенные вещи, например nginx или lighthttpd. Если вам не нравится FastCGI — можно написать модуль к вебсерверу. Но это у же для реально высокопосещаемых проектов…
Второй пример — простой счетчик хитов. Опять же все данные храняться в памяти в деревьях, а по крону раз в несколько минут сбрасываются в MySQL с помощью PHP скрипта. Написано как FastCGI приложение, работает в связке с Nginx.
По вашей статье — тут можно было бы гораздо проще решить проблему с выводом последних n сообщений, но как пример для статьи — самый раз.
А по поводу упоминаемой вами библиотеки — WebToolKit — абсолютно не понравилась идея прикручивать самописный Web-сервер. С ним могут быть как проблемы с произодительностью, так и с безопасностью. Кто знает, сколько там может быть переполнений буфера или утечек памяти? Лучше уж использовать проверенные вещи, например nginx или lighthttpd. Если вам не нравится FastCGI — можно написать модуль к вебсерверу. Но это у же для реально высокопосещаемых проектов…
Да, отличные мысли. Только у нас по поводу библиотек разные подходы. Я предпочту написать одну-две строки #include <my_webtoolkit.h> и дать этому работать пока оно не начнет доставлять мне проблемы, а когда реальные проблемы начнутся — тогда переселю на реальный «nginx» или что-то подобное. Но я не говорю что мой подход верный — просто другой.
nginx и lighttpd тоже вещи «самописные», не забывайте ;)
nginx и lighttpd тоже вещи «самописные», не забывайте ;)
Зачем дерево? Можно ведь обычной сортировкой посортировать?
Как быть если присланному запросу необходимо проверить подлинность? Например для реализации системы голосования, где нужно разрешить изменять только зарегистрированным пользователям.
Ну как на такой вопрос ответить можно?
Ну е-мое, ну это ж в каждом случае надо решать отдельно. Если у вас пять человек и 10 гигов памяти — ну сохраните всех в память, если у вас 10 гигов человек и две памяти — ну используйте БД или распределенную БД или key-value storage или распределенный key-value.
Прям вопрос в духе: «Как сделать Гугл?»
Ну е-мое, ну это ж в каждом случае надо решать отдельно. Если у вас пять человек и 10 гигов памяти — ну сохраните всех в память, если у вас 10 гигов человек и две памяти — ну используйте БД или распределенную БД или key-value storage или распределенный key-value.
Прям вопрос в духе: «Как сделать Гугл?»
Максимум минуту пролежит скрипт если что не так, потом перезапустится. Реально — меньше пол-минуты.
<nazi type="math">Нет, как раз в среднем пол-минуты он лежать и будет, «меньше» в данном случае не корректно</nazi> :-)
Но, что важно: «Premature optimization is the root of all evil». И это важно. Писать какую-нибудь сложную систему сразу на C++ бессмысленно (я про сайты, конечно). Оптимизировать, как правило, нужно только 3% кода. Вот про эти 3 процента я и расскажу.
PHP — достаточно небыстрый язык. C++ при нагрузке будет гораздо быстрее и экономичнее php, вполне возможно, что без оптимизации си получатся быстрее php с оптимизацией.
PHP — достаточно небыстрый язык. C++ при нагрузке будет гораздо быстрее и экономичнее php, вполне возможно, что без оптимизации си получатся быстрее php с оптимизацией.
Да скорее всего так и будет. Только вот есть другой вопрос: стоимость поддержки такого решения (=
На PHP при высоких нагрузках рано или поздно упремся в ресурсы сервера. На сях это будет позднее.
Экономия на серверах, но затраты на поддержку. Неизвестно, что лучше.
Экономия на серверах, но затраты на поддержку. Неизвестно, что лучше.
PHP с включенным APC, становится узким местом в 0.01% случаях. Обычно проблемы возникают в других местах: БД, Apache, I/O, кривой код.
С C++ нам понадобятся только БД и приложение. Веб-сервер и APC становятся ненужными.
Под C++ тоже есть пара фреймворков.
Используя одно, мы теряем преимущества другого и терпим его недостатки.
Под C++ тоже есть пара фреймворков.
Используя одно, мы теряем преимущества другого и терпим его недостатки.
Вы предлагаете ручками самому написать веб-сервер?! Подумайте, какой штат программистов вам придется держать для поддержки всего этого хозяйства. Какие будут затраты на персонал. Мне кажется, что куда дешевле выйдет написать проект на php/perl/python/ruby, поставив во главе разработки человека с большим опытом, который сможет спроектировать хорошо масштабируемую архитектуру.
Отлично сказано!
Известно — то, что дешевле в плане имеющихся доступных ресурсов.
Есть время но нет денег — надо оптимизировать.
Нет времени, но есть деньги — понятно, что проще купить ещё железа.
В вариант с железом, кроме всего прочего, обычно обычно ещё и меньше возможных сюрпризов.
Есть время но нет денег — надо оптимизировать.
Нет времени, но есть деньги — понятно, что проще купить ещё железа.
В вариант с железом, кроме всего прочего, обычно обычно ещё и меньше возможных сюрпризов.
Да никто не спорит, что C++ с оптимизациями или без выиграет с завязанными глазами у PHP, только вот разрабатывать это будем в 10 раз дольше.
имхо название некорректное — это пример не сайтов на C++, а пример сайтов использующих сервисы написаные на С++.
Знакомо… в основном хватает Memcached.
Например, как раз сделано приложение Perl+Memcached::Fast+JSON::XS+DBIx::Class+Postgres.
Правда, оптимизация по мотивам массового тестирования заняла много времени.
Например, как раз сделано приложение Perl+Memcached::Fast+JSON::XS+DBIx::Class+Postgres.
Правда, оптимизация по мотивам массового тестирования заняла много времени.
В целом с автором я согласен. Но в конкретном случае (с выборкой MAX(id) -10) можно было бы поступить проще:
Делать выборку по крону на php каждые N секунд и формировать xml файл с результатом работы и записывать его например в корень сайта с именем 'somefile.xml'
Вебсервер (любой, nginx и даже apache) отдает статический файл максимально быстро, а файл при этом мгновенно помещается в дисковый кеш.
Более того работают все стороны HTTP протокола: HTTP 206 Partial Content, 304 Not Modified. (Все это для файла размером 1кб не нужно, но это точно не повредит, а если файл будет большим — получится только выигрышь)
Делать выборку по крону на php каждые N секунд и формировать xml файл с результатом работы и записывать его например в корень сайта с именем 'somefile.xml'
Вебсервер (любой, nginx и даже apache) отдает статический файл максимально быстро, а файл при этом мгновенно помещается в дисковый кеш.
Более того работают все стороны HTTP протокола: HTTP 206 Partial Content, 304 Not Modified. (Все это для файла размером 1кб не нужно, но это точно не повредит, а если файл будет большим — получится только выигрышь)
Ой, xml это вообще не самое лучшее решение. Если вы захотите парсить этот файл на стороне клиента, то вы будет излишне нагружать JS, появятся проблемы у пользователей, у которых отключен JS. К тому же, это лишний запрос к веб-серверу, лишний I/O Если вы собираетесь парсить его на стороне сервера, опять же php очень медленно работает с xml. memcached — одно из по-настоящему правильных решений в данном случае.
Вместо xml можно взять json. Яваскрипт в примере тоже используется. Тем более в данном случае вся страница может быть закэширована.
XML, зараза, универсальный, хоть и не без оверхеда.
ЗЫ вместо xml можно ложить уже готовый кусок HTML(XHTML) и сразу вставлять в страничку.
ЗЫ вместо xml можно ложить уже готовый кусок HTML(XHTML) и сразу вставлять в страничку.
Да на самом деле нет никакой разницы в каком формате сохранять этот файл. В чем его выдавал первоначальный скрипт на php (txt, xml, json, html) в том можно и сохранять. Для пользователей все будет прозрачно.
А зачем вы так обожествляете memcached и пытаете воткнуть его везде?
Запрос к nginx-memcached:
1. коннект пользователя к вебсерверу и обработка запроса
2. пересылка запроса по tcp/ip соединению к memcached с целью выборки данных
3. выборка из памяти (в memcached) за мгновение и пересылка результатов обратно через tcp/ip
4. пользователю передается файл
Запрос к nginx (статичный файл):
1. коннект пользователя к вебсерверу и обработка запроса
2. файл за 1 наносекунду берется из дискового кеша без обращения к диску (наверно используется какой-нибудь еще sendfile, а может что-то еще)
3. пользователю передается файл
Вот мне кажется в первом варианте на п.2 и п.3 очень много сжирается ресурсов и очень много раз делается копирование кусков информации из одной части памяти в другую. Сначала данные из памяти на стороне memcaced копируются в пул отправки tcp/ip, потом с ними там что-то делает ядро, позже информация выстраивается в буфере на прием и собирается в единый файл (а это все множество вызовов malloc, memcpy) да и считается, что сам tcp/ip стек грузит систему не слабо, рассылая всякие там ACK.
Я вижу для себя memcached совсем в другом роде. А в приведенном выше примере статический файл выиграет по скорости, и я не говорю о том, что это проще реализовать.
А зачем вы так обожествляете memcached и пытаете воткнуть его везде?
Запрос к nginx-memcached:
1. коннект пользователя к вебсерверу и обработка запроса
2. пересылка запроса по tcp/ip соединению к memcached с целью выборки данных
3. выборка из памяти (в memcached) за мгновение и пересылка результатов обратно через tcp/ip
4. пользователю передается файл
Запрос к nginx (статичный файл):
1. коннект пользователя к вебсерверу и обработка запроса
2. файл за 1 наносекунду берется из дискового кеша без обращения к диску (наверно используется какой-нибудь еще sendfile, а может что-то еще)
3. пользователю передается файл
Вот мне кажется в первом варианте на п.2 и п.3 очень много сжирается ресурсов и очень много раз делается копирование кусков информации из одной части памяти в другую. Сначала данные из памяти на стороне memcaced копируются в пул отправки tcp/ip, потом с ними там что-то делает ядро, позже информация выстраивается в буфере на прием и собирается в единый файл (а это все множество вызовов malloc, memcpy) да и считается, что сам tcp/ip стек грузит систему не слабо, рассылая всякие там ACK.
Я вижу для себя memcached совсем в другом роде. А в приведенном выше примере статический файл выиграет по скорости, и я не говорю о том, что это проще реализовать.
Про файлик — это очень хорошее решение.
Как самый тупой вариант — генерить этот файлик самим же PHP.
Но фишка в том, что генериться он будет один раз и отдаватьяс уже статикой — а на клиенте уже можно использовать тупой iframe или include`ить файлик на промежуточном сервере.
Кароче генерить один раз, а отдавать уже без проблем.
Но фишка в том, что генериться он будет один раз и отдаватьяс уже статикой — а на клиенте уже можно использовать тупой iframe или include`ить файлик на промежуточном сервере.
Кароче генерить один раз, а отдавать уже без проблем.
Всё это очень круто и правильно. Лично встречался с описанным подходом и могу сказать, что использовать надо, но в меру.
Хм. IMHO, такой подход к языкам показывает несколько вещей.
1. Человечество разучилось правильно проектировать сложные системы. Декомпозиция, модульность и всё такое прочее. Если в результате получается нечто монструазное, что сложно писать на Си/Си++. The Art Of UNIX Programming забыто.
2. Человечество по какой-то странной причине считает Python/Ruby/Perl языками гораздо более простыми, чем Си/Си++, что говорит о том, что человечество (в среднем) потеряло знание о том, как устроены языки программирования. Кстати, об этом же и говорит то, что люди серьёзно обсуждали возможность писать на LISP сайты. Мне вот лично интересно спросить у таких людей, с чего это вдруг было принято решение о том, что LISP удобнее и эффективнее в этом деле будет, чем тот же PHP?
3. Человечество (в среднем) вообще теряет способность верно оценивать сложность как алгоритмическую, так и реализационную тех или иных программ. И теряет контакт с реальностью (с CPU и OS), считая неэффективные алгоритмы эффективными.
Что печально.
1. Человечество разучилось правильно проектировать сложные системы. Декомпозиция, модульность и всё такое прочее. Если в результате получается нечто монструазное, что сложно писать на Си/Си++. The Art Of UNIX Programming забыто.
2. Человечество по какой-то странной причине считает Python/Ruby/Perl языками гораздо более простыми, чем Си/Си++, что говорит о том, что человечество (в среднем) потеряло знание о том, как устроены языки программирования. Кстати, об этом же и говорит то, что люди серьёзно обсуждали возможность писать на LISP сайты. Мне вот лично интересно спросить у таких людей, с чего это вдруг было принято решение о том, что LISP удобнее и эффективнее в этом деле будет, чем тот же PHP?
3. Человечество (в среднем) вообще теряет способность верно оценивать сложность как алгоритмическую, так и реализационную тех или иных программ. И теряет контакт с реальностью (с CPU и OS), считая неэффективные алгоритмы эффективными.
Что печально.
Вы всерьёз считаете, что С++ проще, чем Python?
А в чём мерять сложность? Модель исполнения вот у Python заметно сложнее, чем у C++. Работа с какими-нибудь бинарными данными в Python тоже не сахар. От задачи в общем случае всё зависит. Кроме этого, как система Си++ проще Python: и runtime проще, и модель компиляции/исполнения программы. И если потребуется что-то заточить-оптимизировать, то опять же C++ меньше усилий для этого потребует.
Так что вот как-то не очевидно, что Python — штука простая, а C++ — сложная. Хотя, конечно, небольшие программы удобнее писать на Python.
Так что вот как-то не очевидно, что Python — штука простая, а C++ — сложная. Хотя, конечно, небольшие программы удобнее писать на Python.
С бинарными данными в Питоне работать несложно, не знаю, что вас так смущает.
Сложность — количество буковок на единицу функционала, и читаемость кода после этого. А вот про то, что в С++ проще модель компиляции программы это отлично :) Я надеюсь, вы не забыли о существовании шаблонов в С++? Рантайм да, в питоне чутка посложнее.
Сложность — количество буковок на единицу функционала, и читаемость кода после этого. А вот про то, что в С++ проще модель компиляции программы это отлично :) Я надеюсь, вы не забыли о существовании шаблонов в С++? Рантайм да, в питоне чутка посложнее.
Интересная проблема. Тоже сталкивался с таким, и дело решилось написанием демона на С++ под заказ. Который в памяти разгребал что надо. Теперь уже года два, никаких проблем.
И согласен с автором, что перебарщивать с С++ не стоит. Не для веба он предназначен.
И согласен с автором, что перебарщивать с С++ не стоит. Не для веба он предназначен.
«Если честно, я в C++ разбираюсь как хакер в женских помадах — как и многие, я большей частью использую PHP»
ну вобщем PHP Си-подобный язык, и хорошо зная PHP, освоить Си проблем быть не должно.
ну вобщем PHP Си-подобный язык, и хорошо зная PHP, освоить Си проблем быть не должно.
Спасибо, было позновательно :). Но уж очень не вериться, что проще написать на плюсах, чем заюзать некоторые существующие технологии.
По делу:
Если у вас изначально планировался довольно хорошо нагруженный проект, то тогда, скажите мне пожалуйста, зачем использовать апач? Если вы бы поставили nginx то эта проблема всплыла чуть пойзже… Если бы еще начали использовать APC, то она еще пойзже всплывет. Вот мыс обственно отодвинули проблему на другой рубеж количества посещений. В итоге, при таком раскладе, у нас появляется шанс, что таких проблем, связанных с сильной нагрузкой не будет. А если они появятся, а появятся они очень не скоро, то тогда у нас 2 пути: переработка PHP кода, если в нем есть «говнокод», то избавляемся от него; или писать часть на более легковесных, в плане обработки протсых итераций процессором, например на C/C++.
По делу:
Если у вас изначально планировался довольно хорошо нагруженный проект, то тогда, скажите мне пожалуйста, зачем использовать апач? Если вы бы поставили nginx то эта проблема всплыла чуть пойзже… Если бы еще начали использовать APC, то она еще пойзже всплывет. Вот мыс обственно отодвинули проблему на другой рубеж количества посещений. В итоге, при таком раскладе, у нас появляется шанс, что таких проблем, связанных с сильной нагрузкой не будет. А если они появятся, а появятся они очень не скоро, то тогда у нас 2 пути: переработка PHP кода, если в нем есть «говнокод», то избавляемся от него; или писать часть на более легковесных, в плане обработки протсых итераций процессором, например на C/C++.
Sign up to leave a comment.
Ну да, сайты на C++