напрасно, у вас артефакты появились вокруг слов "интернет-магазин", смотрится очень непрофессионально.
либо подберите картинку так, чтобы не было артефактов (напр. вообще убрать эти слова) и поставьте сжатие 70% у jpg или меньше, либо в оригинальном png уменьшите количество цветов.
Зарегистрировано запросов: 308
4 секунды на генерацию страницы.. неужели для открытия главной страницы нужно сделать 308 запросов к базе?
тогда только мемкеш какой-нибудь поможет, все остальное это микрооптимизация.
'[umka: ;10755936']Угу... ведь во-первых, дерево директорий — это то же бинарное дерево, если речь идёт о поиске файла. Но если мне не изменяет память, то даже в древней ФС FAT, в этой самой FAT сразу хранился адрес файла на диске. Не думаю, что в современных файловых системах нужно последовательно открывать все директории, чтобы открыть файл :)
да, посмотрел, в ext3 добавили дерево как фичу, в ext4 уже по умолчанию используется.
в ФАТ надо последовательно открывать все директории.
'[umka: ;10754790']😮 Это откуда такая информация? Файл открывается fopen()-ом за один вызов.
я неправильно выразился, прошу прощения.
суть моего сообщения была в том, что в файловых системах чтобы достучаться до файла нужно последовательно открыть все директории, которые по сути обыкновенные файлы (directory files)
'[umka: ;10754790'] А представьте, какое количество fseek()-ов делает база для поиска нужных данных в файле-таблице с использованием бинарного индекса.
как бэ давно показано что поиск по дереву существенно быстрее последовательного поиска.
'[umka: ;10754790'] База делает fopen() как минимум каждый раз, когда возникает временная таблица. Это я всё об MySQL.
ну вообще-то я уже два раза говорил что постановка вопроса некорректна, нужно смотреть на конкретную реализацию СУБД и на конкретную реализацию ФС (ext3 вот научился строить индексные файлы, правда в пределах одной директории).
netwind: iopiop, пользователю совсем не обязательно верить всему тому, что ms утверждает о своих продуктах. Думать тоже нужно.
думать полезно всегда конечно.
навскидку могу назвать две причины почему файлы в базе лучше чем в ФС:
1) количество системных вызовов типа fopen в ФС зависит от глубины вложенности каталогов, если, скажем, глубина 5, то для открытия файла придется сделать fopen 6 раз. База же, вообще делает fopen один раз при старте.
2) если файлов много - база находит нужный файл фактически мгновенно за счет использования индексов, ФС, в большинстве своем, индексы не строит, значит поиск нужного файла существенно медленнее.
Qest: Тоесть в таком случае самый безопасный вариант: при каждом входе на страницу 1 генерировать уникальный ключ, и брать к примеру ip пользователя, записывать ip и ключ в базу, после передавать ключ файлу 2, в котором опять брать ip пользователя и проверять соответсвует ли полученный ключ тому ключу который записан в базе и для которого такой ip.
?
зачем в этой схеме IP ?
недостатки ip -
а) все пользователи за NATом имеют один и тот же IP - актуально для мобильного и-нета.
б) при обрыве связи может сменится IP, т.е. "авторизация" слетит - актуально для мобильного и-нета.
Qest: Вы не поверите, но я знаю что такое сессии. Ваш способ будет работать если каждый раз при открытии страницы генерировать новую сессию, делать запрос к базе, плюс во втором файлу так же делать запрос к базе (что не есть быстро), к тому же в сессии ограничение на 20 минут, и если пользователь потусуется на первой странице больше 20 минут то сессия удалиться, и что сравнивать во втором файле в таком случае? И вообще при чем тут сессии. Можно уж тогда просто генерировать уникальную строку и записывать ее в куку и базу при входе на первую страницу.
про сессии рекомендовано почитать т.к. они работают так, как я описал - через куки.
Qest:
Можно сделать вариант с ключем, если придумать алгоритм по которому он генерируется и сравнивается в втором файле. Тоесть например в первом файле генерируется ключ как сегодняшнее число + 12345 и передается во второй файл, где так же по такому же алгоритму создается ключ и сравнивается с переданным.
дата для этих целей не подойдет.
---------- Добавлено 01.05.2012 в 23:31 ----------
Qest: UPD: Можно прописать htaccess таким образом: --- SetEnvIf Referer "http://mysite.com/1.php" site
как вам уже сказали - реферер снифится и подделывается на ура.
Не понял, и что с этим ключом делать. Если он генерируется в первом файле и отправляется во второй то с чем его сравнивать во втором файле?
Или вы имеете введу сделать постоянный ключ, отправлять постом и проверять его во втором файле? Впринципе в таком случае можно будет взломать только если знаешь этот ключ
почитайте про сессии.
коротко - при открытии первой страницы генерится достаточно большое случайное число которое
а) сохраняется в куку на клиенте (в броузере)
б) сохраняется на сервере в базе/файле
при вызове второй страницы ваш скрипт берет переданную броузером куку и ищет ее в базе/файле. если находит - предполагается что запрос пришел с первой страницы.
netwind: iopiop, работа то нехитрая, а эффект довольно серьезный : как минимум резкое снижение числа соединений, которые обрабатывает nginx и нагрузки на сервере. С синкуками приложение вообще не видит эти ненастоящие подключения.
Дело не только в небольшой экономии памяти ядра.
nginx в любом случае не увидит соединение, что с куками, что без, т.к. оно установлено не будет еще на уровне ТСП.
все что делают син-куки - экономят память но немного больше нагружают проц по сравнению с стандартным поведением. экономия памяти существенная набегает т.к. "100 старушек - 100 рублей".
Уже 560, шапку с png сделал jpeg
напрасно, у вас артефакты появились вокруг слов "интернет-магазин", смотрится очень непрофессионально.
либо подберите картинку так, чтобы не было артефактов (напр. вообще убрать эти слова) и поставьте сжатие 70% у jpg или меньше, либо в оригинальном png уменьшите количество цветов.
Зарегистрировано запросов: 308
4 секунды на генерацию страницы.. неужели для открытия главной страницы нужно сделать 308 запросов к базе?
тогда только мемкеш какой-нибудь поможет, все остальное это микрооптимизация.
;10755936']Угу... ведь во-первых, дерево директорий — это то же бинарное дерево, если речь идёт о поиске файла. Но если мне не изменяет память, то даже в древней ФС FAT, в этой самой FAT сразу хранился адрес файла на диске. Не думаю, что в современных файловых системах нужно последовательно открывать все директории, чтобы открыть файл :)
да, посмотрел, в ext3 добавили дерево как фичу, в ext4 уже по умолчанию используется.
в ФАТ надо последовательно открывать все директории.
;10754790']😮 Это откуда такая информация?
Файл открывается fopen()-ом за один вызов.
я неправильно выразился, прошу прощения.
суть моего сообщения была в том, что в файловых системах чтобы достучаться до файла нужно последовательно открыть все директории, которые по сути обыкновенные файлы (directory files)
;10754790']
А представьте, какое количество fseek()-ов делает база для поиска нужных данных в файле-таблице с использованием бинарного индекса.
как бэ давно показано что поиск по дереву существенно быстрее последовательного поиска.
;10754790']
База делает fopen() как минимум каждый раз, когда возникает временная таблица.
Это я всё об MySQL.
ну вообще-то я уже два раза говорил что постановка вопроса некорректна, нужно смотреть на конкретную реализацию СУБД и на конкретную реализацию ФС (ext3 вот научился строить индексные файлы, правда в пределах одной директории).
iopiop, пользователю совсем не обязательно верить всему тому, что ms утверждает о своих продуктах. Думать тоже нужно.
думать полезно всегда конечно.
навскидку могу назвать две причины почему файлы в базе лучше чем в ФС:
1) количество системных вызовов типа fopen в ФС зависит от глубины вложенности каталогов, если, скажем, глубина 5, то для открытия файла придется сделать fopen 6 раз. База же, вообще делает fopen один раз при старте.
2) если файлов много - база находит нужный файл фактически мгновенно за счет использования индексов, ФС, в большинстве своем, индексы не строит, значит поиск нужного файла существенно медленнее.
я знаю одну такую СМС, имя ей SharePoint, у нее вообще все файлы в базе лежат.
MS утверждает что как раз в базе (MS SQL) и нужно хранить файлы.
так что от БД зависит, не все БД одинаково заточены под работу с двоичными данными, тот же MS SQL 6.5 с ними плохо работал, сейчас допилили.
Тоесть в таком случае самый безопасный вариант: при каждом входе на страницу 1 генерировать уникальный ключ, и брать к примеру ip пользователя, записывать ip и ключ в базу, после передавать ключ файлу 2, в котором опять брать ip пользователя и проверять соответсвует ли полученный ключ тому ключу который записан в базе и для которого такой ip.
?
зачем в этой схеме IP ?
недостатки ip -
а) все пользователи за NATом имеют один и тот же IP - актуально для мобильного и-нета.
б) при обрыве связи может сменится IP, т.е. "авторизация" слетит - актуально для мобильного и-нета.
Вы не поверите, но я знаю что такое сессии. Ваш способ будет работать если каждый раз при открытии страницы генерировать новую сессию, делать запрос к базе, плюс во втором файлу так же делать запрос к базе (что не есть быстро), к тому же в сессии ограничение на 20 минут, и если пользователь потусуется на первой странице больше 20 минут то сессия удалиться, и что сравнивать во втором файле в таком случае? И вообще при чем тут сессии. Можно уж тогда просто генерировать уникальную строку и записывать ее в куку и базу при входе на первую страницу.
про сессии рекомендовано почитать т.к. они работают так, как я описал - через куки.
Можно сделать вариант с ключем, если придумать алгоритм по которому он генерируется и сравнивается в втором файле. Тоесть например в первом файле генерируется ключ как сегодняшнее число + 12345 и передается во второй файл, где так же по такому же алгоритму создается ключ и сравнивается с переданным.
дата для этих целей не подойдет.
---------- Добавлено 01.05.2012 в 23:31 ----------
UPD: Можно прописать htaccess таким образом:
---
SetEnvIf Referer "http://mysite.com/1.php" site
как вам уже сказали - реферер снифится и подделывается на ура.
Не понял, и что с этим ключом делать. Если он генерируется в первом файле и отправляется во второй то с чем его сравнивать во втором файле?
Или вы имеете введу сделать постоянный ключ, отправлять постом и проверять его во втором файле? Впринципе в таком случае можно будет взломать только если знаешь этот ключ
почитайте про сессии.
коротко - при открытии первой страницы генерится достаточно большое случайное число которое
а) сохраняется в куку на клиенте (в броузере)
б) сохраняется на сервере в базе/файле
при вызове второй страницы ваш скрипт берет переданную броузером куку и ищет ее в базе/файле. если находит - предполагается что запрос пришел с первой страницы.
iopiop, работа то нехитрая, а эффект довольно серьезный : как минимум резкое снижение числа соединений, которые обрабатывает nginx и нагрузки на сервере. С синкуками приложение вообще не видит эти ненастоящие подключения.
Дело не только в небольшой экономии памяти ядра.
nginx в любом случае не увидит соединение, что с куками, что без, т.к. оно установлено не будет еще на уровне ТСП.
все что делают син-куки - экономят память но немного больше нагружают проц по сравнению с стандартным поведением. экономия памяти существенная набегает т.к. "100 старушек - 100 рублей".
приветствую. требуется специалист для переноса тройки сайтов на vds и оптимизация их работы
centos 5.4 hyper-v 1Gb. желательно знать специфику vds и панель 1gb. предложения в личку или в тему. спасибо.
пыш... работа срочная!
с уважением
для специалистов - берите деньги только вперед т.к. jaguarcat - известный кидала.