- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
edogs советы с редиректами, хаками и прочими перенаправлениями - это очень плохие советы.
Это хорошие, практические советы не раз спасшие отнюдь не один реальный сайт:) При чем без покупки "крутого дорогого сервера" и без "тонкой дорогой работы по настройке ФС системным администратором".
Сами подумайте, что быстрее: отыскать файл в таблице и это на уровне ядра или распарсить регулярку, сопоставить и потом опять отыскать файл?
Регулярки выполняются настолько быстро по сравнению с дисковыми операциями, что даже странно поднимать об этом вопрос.
Плюс ТС все равно надо думать о физическом разнесении этой файлопомойки по разным местам (хотя бы из соображений нагрузки/быстродействия от простого считывания файлов и возможности более легких бакапов). "Регулярки/кэширование/редиректы" (3,4 вариант) как раз позволят это сделать с минимумом вмешательством в архитектуру (раз уж это важно, хотя самое мудрое это изменить архитектуру), позволяя разнести это не только по папкам, а вообще по разным серверам.
С точки зрения рядового пользователя, понимаю так:
чтение диска: 25кб * 10 картинок * 100 посетителей * 1 секунда = 25000 килобайт или 24,4 мегабайт в секунду
Нет, тут проблема ни в диске и не в чтении данных.
формула такая:
Чтобы прочитать хотя бы один файл из каталога надо сосканировать
100к inode чтобы найти нужную. Если все inode в кэше находятся, то процессор тупо перебирает каждый раз эти inode, чтобы найти нужную.
то есть к верхней формуле добавляется
10 (картинок)*100 посетителей = 1000 раз надо пройтись по 100к inode (в худшем случае). Диск при этом, в большинстве случаев, busy = 0% хоть SSD, хоть SATA 5400 rpm
Задача разнести такие данные по подкаталогам сильно зависит от скриптов проекта у ТС. Можно решить и за 5 минут написания дополнительного кода, а можно и на ext4 попробовать переползти - там сортировку усовершенствовали. Затратность оптимизации сложно подсчитать без дополнительных данных о проекте и на чём он работает.
kvp, давным-давно для поиска файлов используется btree/htree, которое работает на порядок быстрее прямого перебора. Но и htree не панацея для данного случая: ветка папки будет занимать почти половину всего дерева, а чтобы найти файл, ядру придется пройти все дерево, т.е. при частом рандомном обращении к файлам будет ощутимая потеря производительности на фоне повышенной загрузки процессора. Поэтому если есть необходимость хранить много мелких файлов, то лучше использовать ReiserFS, для этого заточенную, и не насиловать extfs.