У нас такие ошибки часто связаны со всякого рода прокси (например, антивирус касперского, который по умолчанию контролирует 80 порт). Может быть в висте включен защитник windows (или как там он называется) и он прослушивает 80 порт?
Мы во избежание подобных ошибок пробуем загружать на нестандартный порт (точно не помню, 8800 или 8080), а при его недоступности откатываемся на 80 порт
Ваш способ плох тем, что количество запросов зависит от N: при N=1000 вам придется сделать 1000 запросов.
Поэтому, я всегда стараюсь избегать случайных выборок.
Не в любой момент, а либо при истечении заданного времени жизни ключа, либо при нехватке памяти — что наступит раньше.
Оба случая решаются выделением достаточного количества памяти процессу memcached.
Это ваша проблема, а не хрома.
Варианта два:
1. Не занимайтесь ерундой и используйте массивы, во всех языках именно они гарантируют порядок.
2. Наживайте себе геморрой путем расширения прототипа Object и введения в него функции добавления элемента (при этом добавляя например timestamp к каждому элементу) и взятия элементов в порядке добавления (сортируя по введенному вами timestamp).
В основном, браузеры понимают это и при изменении гет-параметров загружают файл заново и кешируют.
Но, насколько я слышал, есть некоторые прокси-сервера, которые при наличии гет-параметров не кешируют файл и _всегда_ запрашивают его с сервера — думаю это не то, что вы хотите, т.к. это увеличивает кол-во запросов и нагрузку на ваши сервера.
Также, я сталкивался с тем, что некоторые браузеры не всегда при изменении гет-параметров заново загружают файл с сервера.
По поводу кода моего загрузчика могу сказать, что критичных багов я не заметил, если вы их найдете — буду рад исправить.
В ближайшем будущем добавлю возможность получения статистики очереди загрузки: кол-во файлов в различных состояниях (добавлен, загружается, загружен успешно, ошибка загрузки) и их размер, что может быть полезно для ограничения количества загружаемых файлов за раз.
Также, более детально напишу раздел документации.
На сколько я понял silverlight, там можно грузить только небольшими кусочками, потому как сначала файл переносится в какой-то кеш, потом грузится
Да, это правда.
Из-за невозможности программно задать заголовок Content-Length сильверлайт целиком буферизует запрос, и только после этого начинает его отправлять.
Точно в опере работает Silverlight?
У меня на работе точно работает, дома пользуюсь в основном хромом, реже файрфоксом.
> если бы у меня были навыки C программиста
Имхо, здесь не нужны особые навыки.
В самом простейшем случае, когда у вас фиксированное число серверов, на которых хранятся картинки, вы можете в самой ссылке на картинку зашифровать сервер и путь, где она хранится, а также смещение и размер в файле. Написав простейший модуль к нгинксу, который будет расшифровывать эту информацию и добавлять заголовок Range к этому запросу, вы сможете читать отдельные картинки из комбо-файла.
Потому что в большинстве случаев (есть конечно библиотеки, позволяющие выполнять асинхронные запросы к базе, но это отдельная история) это будет запрос, который заблокирует весь воркер-процесс нгинкса. И как раз при нагрузках это будет более заметно.
А почему facebook перешел на хранение много картинок в одном файле?
Рискну предположить, что они для экономии дискового пространства используют файловые системы с достаточно большим размером блока. И именно из-за большого размера блока они склеивают несколько файлов в один дабы уменьшить потери (в расчете на один файл) в последнем блоке.
Мы во избежание подобных ошибок пробуем загружать на нестандартный порт (точно не помню, 8800 или 8080), а при его недоступности откатываемся на 80 порт