Изображение PHP изменяет размер на лету по сравнению с хранением измененных изображений
Этот UDF немного шаткий, но будет работать в зависимости от того, сколько у вас имен и разброс имен ...
Public Function GenerateId(ByVal strText As String) As Long
Dim i As Long
For i = 1 To Len(strText)
strChar = UCase(Mid(strText, i, 1))
GenerateId = GenerateId + Asc(strChar)
Next
End Function
... есть вероятность, что он удвоится, но это не так легко предсказать. Вы должны были бы пройти все имена и проверить все результаты.
Кроме того, я знаю, что это не подход с последовательным идентификатором, начиная с 1, но вы не указали это, поэтому я использовал креативную лицензию. : -)
Кроме того, это гарантирует, что имя сохранит свой идентификатор, если данные отсортированы по-разному, не уверен, является ли это требованием или нет, но это соображение.
Стоит потенциальный выстрел в любом случае.
4 ответа
Это звучит как преждевременная оптимизация. Знаете ли вы, сколько пользователей будет иметь ваш сайт / сколько вычислительных ресурсов будет иметь ваш сервер (ы)? Выберите самый простой (с точки зрения обслуживания) вариант, то есть измените размер на лету, пока производительность не станет проблемой, а затем выясните, что делать.
Это может быть идея реализовать какое-то кэширование на стороне сервера ваших перемасштабированных изображений, если они, вероятно, будут подвергаться неоднократному обращению, но я не думаю, что это должно распространяться до явного предварительного рендеринга.
Это абсолютно несопоставимые вопросы.
Изменение размера изображений на лету фактически похоже на выполнение DoS-атаки на ваш собственный сервер. Изменение размера одного обычного образа требует больше процессора и оперативной памяти, чем обслуживание одного обычного запроса к php-скрипту Это уже огромное влияние на производительность. Все же обычная миниатюра показывается не в одиночку, а в цифрах. Таким образом, показывая только одну страницу галереи, вы создаете десятки процессов с высокой нагрузкой, увеличивая нагрузку на сервер в десять и более раз.
Быстрый и грязный тест, чтобы доказать мои слова: попробуем изменить размер относительно небольшого 1,3-мегапиксельного изображения
$ /usr/bin/time --format="%MK mem %Es CPU time" /usr/bin/convert angry_birds_1280x800.jpg -resize 100x100 thumb.jpg
10324K mem 0:00.10s CPU time
Нам потребовалось 0,1 с, поэтому показ 10 предварительных изображений будет пожрать целую секунду вашего процессорного времени. В то время как правильно написанная страница галереи PHP займет около 0,01 с. Таким образом, изменяя размер на лету, вы увеличиваете нагрузку на сервер в 100 раз.
То же самое с памятью. Каждый процесс изменения размера потребляет не менее 10 МБ памяти (для изменения размера файла изображения 100 КБ!) С общей суммой 100 МБ. В то время как обычный предел памяти для сценария PHP составляет всего 8 МБ, он редко достигается.
Это реальные цифры.
Несколько забавная вещь, связанная с этой проблемой:
Точно тот же пользователь PHP , который легко выбрасывает 1000000 циклов ЦП в то же время, невероятно ревнив, чтобы сэкономить 1 или 2! Это не фигура речи, вот пример того, о чем я говорю:
аналогичный вопрос от кого-то, чья большая обеспокоенность в то же время в столь же незначительной вещи, как разница в скорости между константами, переменными или массивами переменных . И кто недавно столкнулся с проблемой исчерпанного объема памяти , как будто такой катастрофы было недостаточно.
Есть множество вопросов и ответов на этом сайте, обсуждающих разницу в скорости наносекундной скорости любых операций, отвечающих с неисчерпаемым достоинством, выполняющих тесты миллионов итераций, чтобы показать абсолютно ничтожную разницу между однократными операциями нескольких циклов ЦП каждый.
И в то же время есть такие вопросы - относительно огромной, несравненной разницы в показателях производительности между двумя подходами, которая выглядит просто равной автору.
Это проблема среднего пользователя PHP и этого сайта.
Первые просто не имеют никакой возможности отличить микроскопические вещи от реальных.
И все же у последних нет механизма проверки правильности ответов на вопросы - каждый ответил с одинаковым энтузиазмом, даже если два вопроса противоречат друг другу (и оба имеют здравый смысл).
Динамическое изменение размера может быть дорогостоящей процедурой (в зависимости от времени) в зависимости от начального размера изображений. Я делал это в производственных системах, но когда у меня есть выбор, я решительно предпочитаю кэширование на диск. В конце концов, дисковое пространство дешевое, а время загрузки - это все, что есть в Интернете. Даже если вы просто кэшируете миниатюры с определенным размером и динамически изменяете размеры повсюду, вы можете значительно сократить время загрузки списков изображений в стиле галереи.
Я настоятельно советую вам кэшировать свои изображения, а НЕ изменять размер на лету.
изменение размера изображений требует значительных ресурсов процессора и памяти вашего сервера.
Если у вас есть галерея изображений, которая будет масштабироваться на лету, страница будет загружать изображения медленно, скажем, около 3-10 секунд, в зависимости от исходного размера файла.
При изменении размера требуется около 3 байтов pr пикселя вашей памяти. Таким образом, если у вас есть размер изображения 1000x1000, это займет около 3 МБ памяти. Если на одной из ваших веб-страниц есть много таких изображений, изменяемых на лету, скажем, 20, это займет около 60 МБ ОЗУ вашего сервера. Возможно, нет, так как большинство клиентов запрашивают только 4 изображения за один раз, но 12 МБ все еще много для загрузки страницы. Я бы только масштабировал на лету, если исходное изображение меньше, чем 100x100 пикселей.
СОВЕТ. Отличная библиотека для масштабирования и сохранения больших пальцев - PhpThumb