Комментарии 18
Совсем уж печальная реклама…
Автор и сам понимает, что это печально, но старается улыбаться 😀
Намек - у автора на аватарке Геральт.
Ну не знаю, когда компания у которой раньше были интересные посты скатывается до такого, тем более на хабре, для меня это повод отказаться от их услуг (пусть я и мелкий клиент). Имхо, Хабр не место для такого.
К слову.
Большинство творцов крайне неприятные лично и социально личности. Многие из них носители разнообразных девиантных проявлений.
Возможно это повод отказаться от их творчества, но скорее это причина разделять творца и творчество.
Возможно я погорячился, но всё равно статья больше похожа на то как боролись с болячками C#, но никак не занимались «серверной оптимизацией» и уж тем более «системным администрированием».
Можно было просто взять готовый простейший веб-сервер c++/boost из папки с примерами, немного допилить напильником и сократить объём текста в 5 раз.
автора на аватарке Геральт
Ну, так-то это Гарольд "скрывающий боль", а Геральт - он из Ривии.
Я еще планирую сделать статью по разбору разных VPN'ов. Там я сравню производительность разных протоколов на реальном примере.
Делать я это буду на виртуалках в компании, на которую я работаю. Уж простите, в другом месте брать не буду, ибо где работаю, там бесплатно.
В F#, Unsafe.As даёт возможность небезопасно кастить любую область памяти во что угодно и работать с ней как с любым типом. C# такие выкрутасы делать не даёт.
Я бы настойчиво не рекомендовал такое делать для чего угодно кроме как струтур/примитивов без полей reference типа (и то, даже в структурах можно наступить на грабли unaligned read). Это вам кажется что вы ловко что-то скастили, а по факту могли создать GC Hole который взорвет ваш код отложенной раз в 100 запусков, поэтому Unsafe не зря называется Unsafe, и если F# (по вашим словам) позволяет это делать более свободно то это не звучит как реклама
Интересно протестировать Ваш файловый сервер в следующих ситуациях:
1. Если файл находится в папке в окружении 100 000 других файлов.
2. Если файл находится на съёмном диске (флешке)
3. Если файл изменяется по мере копирования (кто-то в него параллельно дописывает информацию)
Если бы я хотел сделать самый быстрый файловый серввер, то уж точно не стал бы использовать .net
Согласен. Раз уж речь идет про Windows, то можно было бы написать сервер на базе API для драйвера поддержки протокола HTTP в ядре - http.sys. В этом API есть возможность указать, что надо передавать в качестве тела ответа содержимое не буфера из памяти, а данные из файла-источника , указанного через его описатель (handle), в указанном диапазоне байт из него (можно - веесь файл). После этого данные передаются внутри ядра, без переключения в режим пользователя.
Только вот писать такое надо не на ASP.NET Core, хотя он с http.sys работать умеет: в нем слишком много накладных расходов на обработку запроса, причем - хуже оптимизированных, чем для Kestrel: к примеру, если для Kestrel получение контекста обработки (это - внутренняя структура) идет по специальному оптимизированому пути, то для http.sys - нет.
Если бы я хотел сделать самый быстрый файловый сервер, я бы его не делал, а пошел искать готовое решение на рынке ))
Я не зря оставил такой громкий заголовок, так как просто не нашел решений, которые были бы быстрее, чем голый Kestrel + магия выше.
Если подскажете готовое решение, которое настолько же быстрое - я буду только рад.
Подскажу, так как в основном вы здесь занимались попыткой кеширования и веселый хаки с мидлв, то самым быстрым (и бесполезным) способом было бы просто raw tcp сервер (зачем вам целый http фреймворк!? Кто их вообще придумал!) , с тем же словарем но в нем сразу хранить подготовленные байты (заголовки + байнари) и в ответ просто стримить их.
Как я сделал самый быстрый в мире файловый сервер