Sphinx can complement a MySQL-based application in many ways, bolstering performance
where MySQL is not a good solution and adding functionality MySQL
can’t provide. Typical usage scenarios include:
• Fast, efficient, scalable, relevant full-text searches
• Optimizing WHERE conditions on low-selectivity indexes or columns without
indexes
• Optimizing ORDER BY… LIMIT N queries and GROUP BY queries
• Generating result sets in parallel
• Scaling up and scaling out
• Aggregating partitioned data
избави меня бог от таких админов…
Вы сначала разберитесь в отличиях ОС, потом постарайтесь разобраться как устроены разные fs, научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск (кстати этим страдает стандартная конфигерация Gutsy).
В общем вопрос надо не изучать — а проводить стресс тесты и манипулируя параметрами базы, апача, нгинкса и ядра системы учиться на практике.
сессии в мемкеше отличное решение до тех пор, пока количество серверов под мемкеш не больше 1 и он не падает. на удивление, memcache достаточно не стабильная штука под нагрузкой.
файловая система ext3 даже близко, даже на каплюшку, даже чуть-чуть не реляционно-ориентированная. Она больше напоминает стакан с водой, который на глаз на 60% наполнен или на 40% пуст.
По моему опыту количество объектов (файлов, директорий, симлинков) в каждой директории не должно привышать 5к. Тем не менее я лично не храню более 1к в директории. И вообще стараюсь избегать от хранении чего-либо в файловой системе. Сессии — в базу, возможно в мемкеш, если нагрузка не высока. Но, соответственно, картинки в базу пока класть накладно, кладем на диск, но в поддиректории обязательно.
php же при работе с сессиями, читает директорию сессий каждый раз при удалении, соответственно, если там дохрена объектов, он начинает жестко тормозить.
Не зря в php ветвление директории для save_path предусмотрено, цитирую:
There is an optional N argument to this directive that determines the number of directory levels your session files will be spread around in. For example, setting to '5;/tmp' may end up creating a session file and location like /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If . In order to use N you must create all of these directories before use. A small shell script exists in ext/session to do this, it's called mod_files.sh, with a Windows version called mod_files.bat. Also note that if N is used and greater than 0 then automatic garbage collection will not be performed, see a copy of php.ini for further information. Also, if you use N, be sure to surround session.save_path in "quotes" because the separator (;) is also used for comments in php.ini.
Имеется опыт РНР сайта с кол-вом хитов в сутки (только PHP, а ещё статика — js, css, картинки: ещё каких 10 лямов в сутки т.к. image хостинг присуствовал тоже) порядка 10 миллионов — один сервер, загрузка порядка 30% по вечерам (Dual Quad Core Xeon 2.4 GHz, 8 GB RAM, 3 x 76 SCSI 15k rmp HDD без райда). Lighttpd + PHP (fastcgi) + xcache + memcache + MySQL с хорошо оптимизированными запросами и кешированием в memcached (как SQL запросы, так и куски HTML — по ситуации).
Вообщем общую статистику за 24 часа lighttpd показывал на уровне 23-25 миллионов запросов, более точное распределение я вам не скажу.
скажите пожалуйста, чем отличается мой предложенный «в лоб» способ от вашего? Я же не написал реализации sql запрос, я сказал что инфу можно хранить в базе и это не совсем верно с моей точки зрения. Вы же говорите что я начинающий разработчик и делаете то же самое, о чем говорил я.
Так же, хранить аватары приходится все равно в сжатом виде, терпеть не могу сервисы, которые просят залить 100x100 аватары и не шагу вправо-влево. При «пережиме» аватара его сохранять все равно в jpg, ибо жатая картинка в gif или png весит значительно больше, а значит хранить тип файла ни к чему. Как и наличие или отсутствие аватара.
Мой способ самодостаточен. Он не требует изменений в БД и не зависит от неё, id или login у пользователей в таблице будет как не крути.
статья неправильно учит тому, что давно известно. её нужно немножко сжечь,
а то скоро на хабре появятся мануалы «как с помощью css задать размер шрифта и интерлиньяж» и «как с помощью проприентарного css-свойства zoom задать hasLayout».
зачем div#main? у вас есть body.
зачем position: relative для каждого блока?
зачем #rightbar и и #sidebar2 в нём, одного блока хватит.
что за глупость с height: 0?
Давайте местами не будем переставлять. GMail шел ОТ plainHTML. Просто постоянно поддерживают его.
Сейчас, если задача решается просто с JavaScript, никто и никогда не будет делать HTML-версию. Пример с Хаброй — да, тут вроде без JavaScript можно ответить (судя по ссылкам ?reply_to=), НО вы представьте на что натолкнется поисковик? КУЧА ссылок на одной странице, которые ведут на ее же саму.
Мне оно надо? Чтобы индекс упал. Нет, я лучше вышвырну с сайта тех, кто не хочет включать JavaScript.
Другой пример. Форма заказа в интернет-магазине. Я руководил группой разработчиков, которые постоянно развивали один магазин. Работы было невпроволок. По 50+ записей в ToDo. и 40% из них касаемо удобства пользователей, всяких фишек и прочего. Так вот, возвращаясь к форме, которая автоматически подгружала, считала и все красиво делала. Клиент попросту не оплатит функционал без JavaScript, а на его реализацию уйдет чуть ли не столько же времени. Оно мне надо? Клиенту оно надо? Нет и нет.
Другое дело, что когда вся работа будет сделана, когда все будет отлажено, можно улучшать существующее. Но что-то по 7-милетнему опыту своему ни разу такого просвета не было.
PS: Рядом с формой оформления заказа была ссылка «Проблема с оформлением?». Никакого JavaScript, тупой POST. За год работы магазина НИ ОДНОГО тикета в техподдержку по этому поводу. Магазин был довольно посещаем, чтобы не было недоразумений.
Sphinx can complement a MySQL-based application in many ways, bolstering performance
where MySQL is not a good solution and adding functionality MySQL
can’t provide. Typical usage scenarios include:
• Fast, efficient, scalable, relevant full-text searches
• Optimizing WHERE conditions on low-selectivity indexes or columns without
indexes
• Optimizing ORDER BY… LIMIT N queries and GROUP BY queries
• Generating result sets in parallel
• Scaling up and scaling out
• Aggregating partitioned data
а есть для nautilus скрипты для закачки картинок на сайт?
цены бы ваще сервису небыло:)
Вы сначала разберитесь в отличиях ОС, потом постарайтесь разобраться как устроены разные fs, научитесь настраивать, к примеру, кеши дисковой подсистемы линуха их тайминги объемы (вы наверное не видели как система захлебывается от слишком большоко количества свободной памяти — которую она радостно забирает под write cache и при снижении нагрузки — все занятые 10-16 гигов начинает таки писать на диск (кстати этим страдает стандартная конфигерация Gutsy).
В общем вопрос надо не изучать — а проводить стресс тесты и манипулируя параметрами базы, апача, нгинкса и ядра системы учиться на практике.
По моему опыту количество объектов (файлов, директорий, симлинков) в каждой директории не должно привышать 5к. Тем не менее я лично не храню более 1к в директории. И вообще стараюсь избегать от хранении чего-либо в файловой системе. Сессии — в базу, возможно в мемкеш, если нагрузка не высока. Но, соответственно, картинки в базу пока класть накладно, кладем на диск, но в поддиректории обязательно.
php же при работе с сессиями, читает директорию сессий каждый раз при удалении, соответственно, если там дохрена объектов, он начинает жестко тормозить.
Не зря в php ветвление директории для save_path предусмотрено, цитирую:
There is an optional N argument to this directive that determines the number of directory levels your session files will be spread around in. For example, setting to '5;/tmp' may end up creating a session file and location like /tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If . In order to use N you must create all of these directories before use. A small shell script exists in ext/session to do this, it's called mod_files.sh, with a Windows version called mod_files.bat. Also note that if N is used and greater than 0 then automatic garbage collection will not be performed, see a copy of php.ini for further information. Also, if you use N, be sure to surround session.save_path in "quotes" because the separator (;) is also used for comments in php.ini.Вообщем общую статистику за 24 часа lighttpd показывал на уровне 23-25 миллионов запросов, более точное распределение я вам не скажу.
Так же, хранить аватары приходится все равно в сжатом виде, терпеть не могу сервисы, которые просят залить 100x100 аватары и не шагу вправо-влево. При «пережиме» аватара его сохранять все равно в jpg, ибо жатая картинка в gif или png весит значительно больше, а значит хранить тип файла ни к чему. Как и наличие или отсутствие аватара.
Мой способ самодостаточен. Он не требует изменений в БД и не зависит от неё, id или login у пользователей в таблице будет как не крути.
а то скоро на хабре появятся мануалы «как с помощью css задать размер шрифта и интерлиньяж» и «как с помощью проприентарного css-свойства zoom задать hasLayout».
зачем
div#main? у вас естьbody.зачем
position: relativeдля каждого блока?зачем
#rightbarи и#sidebar2в нём, одного блока хватит.что за глупость с
height: 0?Не забудьте, что с помощью псевдо класса :target ваш сайт будет также круто работать и с отключённым js
.piece:target{top:0} или что-то в этом духе
Сейчас, если задача решается просто с JavaScript, никто и никогда не будет делать HTML-версию. Пример с Хаброй — да, тут вроде без JavaScript можно ответить (судя по ссылкам ?reply_to=), НО вы представьте на что натолкнется поисковик? КУЧА ссылок на одной странице, которые ведут на ее же саму.
Мне оно надо? Чтобы индекс упал. Нет, я лучше вышвырну с сайта тех, кто не хочет включать JavaScript.
Другой пример. Форма заказа в интернет-магазине. Я руководил группой разработчиков, которые постоянно развивали один магазин. Работы было невпроволок. По 50+ записей в ToDo. и 40% из них касаемо удобства пользователей, всяких фишек и прочего. Так вот, возвращаясь к форме, которая автоматически подгружала, считала и все красиво делала. Клиент попросту не оплатит функционал без JavaScript, а на его реализацию уйдет чуть ли не столько же времени. Оно мне надо? Клиенту оно надо? Нет и нет.
Другое дело, что когда вся работа будет сделана, когда все будет отлажено, можно улучшать существующее. Но что-то по 7-милетнему опыту своему ни разу такого просвета не было.
PS: Рядом с формой оформления заказа была ссылка «Проблема с оформлением?». Никакого JavaScript, тупой POST. За год работы магазина НИ ОДНОГО тикета в техподдержку по этому поводу. Магазин был довольно посещаем, чтобы не было недоразумений.