— Да, их можно кэшировать, но какой ценой — кэш переполняется «тяжёлыми» ответами, кэширование для других запросов становиться неэффективным и общая скорость СУБД падает.
— Что за бред? Вы что, умеете отключать автоматическое кэширование файлов в ОС?
— То же самое можно сказать про кэширование средствами MySQL. Или каким-то чудесным способом кэшируемая информация меняет свой объём попадая в кэш MySQL?
— Миллионы? Ну-ну, у Вас богатая фантазия. Возьмём тот же Хабр — всего 140000 статей.
Потом, что мешает Вам разделить файлы по папкам.
И подозреваю, что Вы никогда не заливали на сервер dump в полгига — вот это вечность.
— Хотелось бы взглянуть на ваш чудо-поиск без Сфинкса.
— А о каком кэшировании? Через memcached будет медленнее.
— Это происходит автоматически и никогда дополнительное кэширование не помешает.
— Как зачем? Что бы весь проект с текущими статьями висел в памяти и брался от туда.
— А это не преимущество.
— То есть как ещё? Вы что поиск по текстовым данным организуете без Сфинкса?
По поводу кэширования:
— Строки с текстовыми полями в MySQL не кэшируются.
— Файлы автоматически кэшируются ОС.
— Файлы можно кэшировать при помощи опкэшера.
По поводу бекапа:
— Файлы тоже можно бекапить.
По поводу поиска:
— Сфинкс прекрасно ищет по файлам.
Здесь всё устроено по принципу «где тонко, там и рвётся».
4 декабря СР и КПРФ практически на всех участках по всей Волгоградской области разместили наблюдателей, не были охвачены только дальние сельские районы. И что в итоге?
По участкам, где были наблюдатели, Единая Россия набрала менее 35% при явке 65%, а в богом забытом Алексеевском районе, куда наблюдатели не успели добраться, явка неожиданно 98% и за ЕД 95%… По Волгоградской области ЕД в итоге набирает больше всех.
Достаточно, чтобы камеры были отключены/не работали на нескольких участках, что бы серьёзно потасовать итоги выборов.
Вы думаете, что так будет?
Могу с Вами даже поспорить, что на «нужных» участках, что-то случиться и видео будет незаписано/потерянно. Точно так же, как 4 декабря на «нужных» участках не оказалось наблюдателей не от Единой России.
Было потрачено 4,5 минуты. Использовался только PowerPoint и VirtualDub. Конечно не шедевр, над стилем я не работал. Но главное принцип показан — видео с «прыгающим текстом и картинками» можно делать без знания видеомонтажа.
Всё равно не вижу проблемы. Отображайте ваш индикатор сразу, ведь работать он должен сразу.
А то у Вас как-то не логично: «загружаем основную страницу->отображаем индикатор загрузки->продолжаем загрузку->прячем индикатор загрузки»
Проще: «загружаем основную страницы с видимым индикатором->продолжаем загрузку->прячем индикатор»
Я, конечно, понимаю, что нахожусь на Хабре и тут минусуют за любой взгляд, отличающийся от обычного, но хотелось бы немного адекватной критики от минусующих товарищей.
Рассмешили… Вы сами когда в последний раз использовали возможности CUDA?
На практике использование разрекламированных возможностей CUDA требует использование IRay, что не есть хорошо. К тому же производительность хромает — habrahabr.ru/blogs/hi/130378/
Лучше вложиться в процессор, чем в видеокарту.
Видеокарта, как ни странно, мало важна. Работа с графикой — это не в игры играть, где изображение требует постоянных пересчётов.
Огромная память (как 16 Гб) тоже не нужна, т.к. нечем её заполнять. Это только если Вы любите работать в 10 окон, то может пригодиться.
Жесткий SSD тоже не нужен. Практически вся работа ведётся в памяти. К жёсткому обращения идут только при сохранении. Тот же SATA на полтерабайта будет куда полезнее, т.к. материалов работы будет очень много и объёмы нужны.
По поводу процессоров соглашусь — самое тонкое место.
1. «global» — Что лучше 1 глобальная переменная или ненужное подключение к серверу? По мне лучше я потеряю несколько байт памяти, чем до 0.003 сек. на запрос.
2. «простой MySQL» — для простых задач, он идеально подходит. Или Вам нужны какие-то особенности других СУБД?
3. «нет prepared statment» — это хорошо на однотипных запросах. Но кто сказал, что у нас однотипные запросы?
4. «нон ООП подход» — А зачем здесь ООП? Чтобы ресурсов больше съесть? PHP — это не С, в нём эффективнее использовать функциональное программирование.
5. «ПРИ КАЖДОМ СКВЛ запросе вы вызываете лишьную функцию. (но это не существенно)» — Во-первых, на это ресурсов практически не тратиться. Во-вторых, это не все функции проверки данных.
6. «Записываете ошибки не в поле а в одну строку (но это не существенно)» — Здесь все ошибки пишутся в логи построчно. А строка при необходимости отсылается на клиент.
7. «function checkfield($request) {… $request = trim($request); if (isset($request))… = всегда правда» Вы забываете случай пустой строки.
8. «ЗАЧЕМ ВОТ ЭТО: «else { dbconnect(); return mysql_real_escape_string($request); }» О_о» — Числовые значения экранировать не надо. А для вызова функции mysql_real_escape_string нужно подключение к базе.
«Такое ощущение, что у вас всё время проподает связь с базой данных или вы её где-то переписываете»
— Вы плохо разобрались в коде. Код заточен на то, чтобы не создавать лишних телодвижений (подключение к СУБД, экранирование), если это не нужно.
Обычно, помещают на страницу скрытый iframe и форму с input type=file. Цель ставят на скрытый фрейм: <iframe id=hiddenframe name=hiddenframe style=\"width:0px; height:0px; border:0px\">
Затем по нажатию на что-нибудь инициируют событие загрузки: document.forms["loadavatar"].submit();
— Что за бред? Вы что, умеете отключать автоматическое кэширование файлов в ОС?
— То же самое можно сказать про кэширование средствами MySQL. Или каким-то чудесным способом кэшируемая информация меняет свой объём попадая в кэш MySQL?
— Миллионы? Ну-ну, у Вас богатая фантазия. Возьмём тот же Хабр — всего 140000 статей.
Потом, что мешает Вам разделить файлы по папкам.
И подозреваю, что Вы никогда не заливали на сервер dump в полгига — вот это вечность.
— Хотелось бы взглянуть на ваш чудо-поиск без Сфинкса.