ps axf

if (file_exist($img . $widh . - . $heght) { 
	вывели 
} else {
	ресайз
	вывели
}

пхп с file_exist можно лишний раз и не дергать, это лишнее.

в апаче есть RewriteCond %{REQUEST_FILENAME} -f

в nginx есть try_files

если используется vds или сервер, то лучше настроить собственный кеш nginx-а для хранения картинок.

у меня режутся картинки на лету и сохраняются в кеше nginx-a на 365 дней. если нужно, то можно дернуть любую картинку/тумбу с "волшебным" параметром и она принудительно пересоздастся из исходника.

данное решение хорошо масштабируется, можно резать на нескольких бекендах одновременно. я запускал на трех - работает быстро и красиво.

Основной вопрос, который требует ответа: а нужно ли "множество превьюшек разных размеров" ?

Если пропорции более-менее не нарушаются, то намного проще css-ом подогнать размер, чем плодить лишние сущности.

Обычно достаточно: small / medium / full или даже что-то одно small_или_medium и full

По нарезке: забыли еще про крон. Удобно резать неспеша и в фоновом режиме.

На лету тоже отлично режется: отрезал - сохранил на диск, в следующий раз отдал сразу с диска.

странно, что не нашлось быстрых "импортеров".

насколько я помню, давно с ними работал, в формате dbf3-dbf4 фиксированная длинна одной записи(в пределах одного файла). возможно засада будет на полях memo - не помню и вспоминать не хочу. :)

но в простейшем случае можно:

1. прочитать заголовок и вычислить длинну записи

2. установить указатель чтения на первую занись и дальше обычное потоковое чтение файла порциями "длинна записи" * "кол-во записей" (т.е. к примеру читать по 1-5тыс записей в память и затем одним инсертом забрасывать эти 1-5тыс записей в sql сервер)

это должно отработать очень быстро.

заинтересовало... ктати, выборку можно сделать на чистом sql, без пхп и т.д.

исходную табличку дополнил полем WeightSum:

name	| perc	| WeightSum
------------------------------------------------------
1.jpg	| 20	| 0
2.jpg	| 50	| 20
3.jpg	| 30	| 70

SELECT *
FROM `img_rand`
where WeightSum <= rand()*100
order by WeightSum DESC
limit 1

вроде работает :)

И зачем такие сложности? разбор хтмл-а, телепорт, фантом...

Там все замечательно забирается джейсоном. Отдаются уже структурированные данные, не нужно выковыривать их как в случае с хтмл.

первый запрос:
http://www.cikrf.ru/services/lk_tree/?first=1&id=%23
потом из джейсона достаем id-шки и сохраняем в базу
дергаем каждую id-шку, например:
http://www.cikrf.ru/services/lk_tree/?id=6434118731
сохраняем новые id-шки и повторяем пока не вытащим все.

даже сейчас на статье: 235 queries.

даже боюсь предположить, сколько запросов было до переделки. 😂

оффтоп: 1000 за все(с наполнением) - вроде нормально, малость поклацал по сайту, контент - битый граб, да и половина картинок недоступна. такое чудо уже не реанимировать. намного проще будет делать с нуля и на другом домене.

А что мешает WordPress-у или любому другому движку делать тоже самое?

Хозяин сайта - барин, ТЗ - и все будет как хочется.

В случае "Кеш Nginx на SSD" может использоваться файловый кеш, т.е. данные могут быть закешированы в раме, а не читаться каждый раз с SSD.

Поэтому не стоит особо расчитывать на ускорение при "Кеш Nginx на tmpfs".

Лучше в tmpfs засунуть временные файлы mysql (если это еще не сделано).

что общего между "не приклепляют к какому-то сервису" и свифт платежами, которыми выплачивает адсенс? я бы не стал это обобщать.

foreach ( $a as $b ) { 

    $o .= '<div>'.$o.'</div>'; 

} 

echo $o;

тогда уж

$o = "";

foreach ( $a as $b ) { 

    $o .= "<div>$b</div>";

} 

echo $o;

Частный случай, именно для этого примера:

    echo "<div>".join("</div><div>", $a)."</div>";