[Разработка веб-сайтов, Серверная оптимизация, Сетевые технологии, Серверное администрирование] Где поместить свой сервер, чтобы обеспечить максимальную скорость? Насколько это важно? (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
26-Мар-2021 21:31

Цитировать

Где поместить свой сервер, чтобы обеспечить максимальную скорость? Помимо времени, необходимого серверам для ответа на запросы, требуется время просто для доставки пакета из пункта А в пункт Б.Чтобы теоретически определить лучшее физическое место для размещения своего сервера, я объединил общедоступные данные о задержках с собственными журналами доступа к веб-серверу. Я стремлюсь получить грубый, количественный, ответ, основанный на реальном наборе данных.

По мере роста сетевых задержек могут происходить странные вещи: «толстые» сайты могут стать более быстрыми (особенно если они полностью обслуживаются из CDN), а «тонкие» сайты, использующие API-интерфейсы, могут стать более медленными. Для пользователя настольного ПК/ноутбука типичная задержка достигает 200 мс, а для мобильного пользователя 4G составляет 300–400 мс. В этой статье предполагается, чтопропускная способность равна 40 Мбит/с, поддерживается TLS, задержка CDN равна 40 мс и нет существующих соединений. «Исходная точка» здесь означает основной веб-сервер (в отличие от «пограничных» кэшей CDN).

Почему местоположение имеет значениеВремя пересечения Интернета добавляется ко времени, затраченному на ответ на запрос. Даже если ваш API-интерфейс способен ответить на запрос за 1 мс, когда пользователь находится в Лондоне, а API-сервер — в Калифорнии, пользователю всё равно придется ждать ответа около 130 мс.Весь процесс занимает немного больше 130 мс. В зависимости от того, что делают пользователи, в конечном счёте они могут совершить несколько таких операций передачи и подтверждения. Для загрузки веб-страницы обычно требуется пять полных операций передачи и подтверждения: одна — для разрешения доменного имени с помощью DNS, одна — для установления TCP-соединения, ещё две — для настройки зашифрованного сеанса с TLS, и, наконец, одна — для страницы, которую вы хотели получить в первую очередь.В последующих запросах можно (но не всегда) повторно использовать настройки DNS, TCP и TLS, но при каждом обращении к серверу, например при вызове API-интерфейса или при создании новой страницы, по-прежнему требуется новая операция передачи и подтверждения.Сначала кажется, что 130 мс — это быстро, но вся эта долгая и муторная процедура с простым получением страницы и последующим выполнением пары API-вызовов может легко занять большую часть секунды только с точки зрения времени ожидания сетевого сигнала. Всё остальное необходимое время — время выбора сервером ответа на запрос, время загрузки нужных данных, а затем время визуализации содержимого в браузере — всё это дополнительное время.Два вида понятия «быстрый» для сетейПри обсуждении сетей сбивает с толку то, что люди говорят о получении «более быстрых» сетей: «более быстрая» домашняя широкополосная связь, например, или«быстрый ethernet» (скорость «100 мегабит в секунду» уже не впечатляет).Понятие «быстрее» этого вида на самом деле не свидетельствует о скорости. Более высокая скорость привела бы к сокращению задержки и, соответственно, к ускорению операций передачи и подтверждения. Вместо этого понятие «более быстрых» сетей фактически означает более высокую пропускную способность, т. е. передаётся больше байт в секунду.API-интерфейсы, или сети CDNСуществует сеть, в которой операции выполняются быстрее, — это сеть дистрибуции содержимого (Content Distribution Network, CDN). Вместо того чтобы пройти весь путь до Калифорнии, возможно, вы сможете получить часть веб-страницы из кэша в Центральном Лондоне. Такой подход экономит время. Операция может занять всего 50 мс. Экономия достигает 60 %. Кэш отлично работает для CSS-файлов, изображений и JavaScript, т. е. для ресурсов, которые не меняются для всех пользователей. Он не так хорошо работает для ответов на API-вызовы, так как ответы различны для каждого пользователя, а порой и всегда.Количественный подходНемногие счастливчики все запросы могут обрабатывать с помощью CDN. Новостные сайты, например, показывают всем одно и то же. Другие менее удачливы и могут применять кэширование лишь в ограниченном объёме или вообще не использовать его. Эти несчастные люди должны выбрать такое место для своего основного сервера, чтобы максимально быстро доставлять свои данные пользователям, которые в них нуждаются. Если этот выбор направлен лишь на уменьшение задержки, какое место они должны выбрать?Вот что я сделал:

Я взял собственные журналы доступа за две недели в сентябре сразу после того, как опубликовал что-то новое. За этот период я получил около миллиона запросов от 143 тыс. уникальных IP-адресов. Я исключил очевидных роботов (на которые пришлись около 10 % запросов).
Я использовал базу данных GeoIP компании Maxmind для привязки каждого IP-адреса в этих журналах доступа к соответствующим географическим координатам.
Затем я использовалопубликованные на сайте WonderNetwork данные о задержках в интернет-соединениях между примерно 240 городами мира.
Я сопоставил (полуавтоматически, что было довольно мучительно) названия этих городов с идентификаторамиGeonames, что позволило получить координаты городов.
Затем я загрузили всё вышеперечисленное в базу данных Postgres с установленным расширениемPostGIS для выполнения географических запросов.
Я запросил оценку длительности (в процентах) выполнения запросов в ситуациях, когда мой сервер находился бы в каждом из 200 городов.

РезультатыВ таблице ниже я записал результат: количество времени, требуемое пользователям для выполнения одной операция передачи и подтверждения с моим сервером, если бы он размещался в каждом городе. Результаты указаны в процентилях:

среднее («P50»);
для трёх четвертей запросов («P75»);
для 99 % запросов («P99»).

Все числа выражены в миллисекундах.Все результаты см. в таблицеCityp50p75p99Manhattan7497238Detroit89115245Secaucus7196246Piscataway7598251Washington82105253Chicago90121253Kansas City98130254Indianapolis96125254St Louis96127256Cincinnati92121257Houston104134257Syracuse77102257Scranton78103258Quebec City83113259South Bend92118259Montreal83104259Charlotte91110259Salem7498259Buffalo80111259Albany75100260Monticello94123260Baltimore80105260Asheville95118260New York77103261Berkeley Springs84112261Minneapolis102133261Barcelona102148261Dallas112140262Des Moines104131262San Jose139165263Brunswick77101264Atlanta88113264San Francisco136168264Halifax80102265Philadelphia77100266Basel97146267Green Bay103131267Pittsburgh88117267Bern99147267Denver112141267Miami103129267Raleigh88111268Knoxville114135268Boston77105268Valencia108148268Jackson105132268Memphis101131268Jacksonville95122268Madrid95138268London76130268San Diego138162269San Antonio112138269Salt Lake City120151269Toronto87111269Cleveland97122269Austin113141270Colorado Springs110136270Orlando103126270Antwerp93137271Oklahoma City114147271Saskatoon115140272Lansing98127272Seattle141164272Columbus92120273Bristol76129274Tampa104130274Lausanne95139274Ottawa85111274Falkenstein91137275Maidstone76129275Paris80129275Toledo102129275Savannah117146276The Hague82138276Liege87136277Lincoln100124277New Orleans115142278Amsterdam82140278Las Vegas136163279Vienna102149279Coventry80132279Cromwell80106280Arezzo109160280Cheltenham79131280Sacramento137167280Alblasserdam82137281Vancouver142165281Fremont131157283Gosport76137284Frankfurt93136284Carlow88136285Phoenix128153285Portland132159285Cardiff78131285Luxembourg87137285Bruges83135285Eindhoven85133285Groningen87139286Manchester80137286Brussels90139287Brno106148287Edinburgh84136287Nuremberg89136288Albuquerque125159289Los Angeles141164289Ljubljana110152289Lugano97147290Zurich103146290Dronten84133290Newcastle87147290Rome96147291Dusseldorf90140291Munich98144291Venice106156292Edmonton139165292Copenhagen96145292St Petersburg113163293Dublin85143293Redding142178293Vilnius110162293Belfast79125294Nis113158294Douglas87143294Rotterdam82139295Bergen107157295Strasbourg89141295Roseburg148172296Graz104147296San Juan117141298Warsaw108161299Frosinone105153299Riyadh159206300Prague103152301Ktis102158302Mexico139164302Belgrade113160302Guadalajara128155303Milan96146305Bratislava102154306Osaka181240307Zagreb103150308Tallinn108162308Helsinki105156308Hamburg127166309Oslo98153311Bucharest120162311Riga113159312Panama150177313Tokyo188238313Kiev119168313Stockholm102153314Budapest110162314Kharkiv128169315Gothenburg115167316Pristina122167316Tirana128184316Geneva96142316Siauliai113163317Cairo133182318Sapporo196255318Bogota170188319Palermo119183320Gdansk107152320Caracas149176320Sofia114161321Westpoort79134321Honolulu173196321Roubaix102157321Kazan138190322Winnipeg169190322Varna120173322Tel Aviv138194322Lisbon115166324Jerusalem145198324Ankara139195327Heredia164188327Athens128183329Reykjavik127180329Paramaribo166194330Algiers120173332Chisinau127180333Bursa135188334Thessaloniki134187336Limassol141186337Lyon95145340Mumbai204248340Medellin163186344Valletta120176345Baku160205346Melbourne227269346Fez149198348Tunis124180348Koto217254348Dubai192243350Tbilisi153208351Malaysia195235352Hyderabad214260354Bangalore212252355Izmir137187357Adelaide241272359Chennai221248359Moscow127172359Lahore217270361Novosibirsk163206362Sydney237272363Karaganda180231363Vladivostok223264364Taipei265293364Lima169199364Istanbul135182366Hong Kong199223366Auckland244291367Jakarta207245368Seoul231277371Beirut136195372Accra168216373Singapore190246374Sao Paulo193213375Joao Pessoa182220378Perth243267379Ho Chi Minh City253287380Wellington251295383Brasilia226249384Manila251281385Pune202251386Dhaka231268386Phnom Penh243267386Santiago202230390Lagos191233391Quito162188392New Delhi230264395Johannesburg237283398Bangkok222254401Canberra262295402Dar es Salaam214267407Dagupan239268408Christchurch257309409Hanoi235264415Cape Town216262417Buenos Aires232253417Guatemala217249418Brisbane261288422Indore304352457Zhangjiakou236264457Nairobi233277468Kampala244287480Hangzhou239267517Shenzhen242275523Shanghai300367551Montevideo738775902Вы также можетезагрузить все результаты как csv-файл, если так проще.Результат: восточное побережье Северной Америки — хорошо, прямо в Атлантике — лучшеВсе лучшие места находятся в Северной Америке. Это, вероятно, не стало полным сюрпризом, учитывая, что это довольно плотный кластер носителей английского языка, от которого не так далеко (с точки зрения задержки), в Великобритании/Ирландской Республике, находится другой кластер. Кроме того, в Европе много тех, для кого английский — второй язык. Лучше всего находиться прямо в Атлантике: в штатах Нью-Джерси и Нью-Йорк есть много отличных мест для P99, и показатели в верхней части, между P50 и P99, варьируются не слишком сильно.Если вам интересно, почему небольшие города в Нью-Джерси, такие как Секокус и Пискатауэй, так хорошо связаны, — в них есть большие центры обработки данных, используемые финансовым сектором Америки.В настоящее время мой сервер находится в Хельсинки. Это был самый дешёвый вариант, что необычно для Финляндии. За этот сервер я плачу около трёх фунтов в месяц, всего лишь. Если бы я переместил его куда-нибудь в Нью-Джерси и потратил больше денег, в целом пользователи определённо сэкономили бы время: половина операций передачи и подтверждения была бы завершена за 75, а не за 105 мс, что позволило бы сэкономить 30 %. За несколько операций передачи и подтверждения время, вероятно, увеличилось бы примерно на шестую долю секунды по сравнению со средним показателем загрузки первой страницы, что не так уж плохо. Если вы не можете сказать, что этот веб-сайт очень обременителен для веб-браузеров с точки зрения визуализации, сокращение времени ожидания в сети сделает его значительно быстрее.Поскольку на этом сайте ничего не генерируется динамически, в действительности мне лучше всего использовать CDN. Это действительно сэкономило бы много времени для всех: обслуживание из CDN почти в два раза лучше (~40 мс) установки сервера в самом быстром месте (71 мс).Как это может меняться со временемЗадержки не фиксированы, и со временем они могут уменьшиться. Здесь предлагается таблиц задержек операций передачи и подтверждения при передаче данных из Лондона в другие города мира с населением более 5 млн. человек. Значения сравниваются с теоретической максимальной скоростью — скоростью света:ГородРасстояние (км)Реальная задержкаТеоретический максимумФактор замедленияНью-Йорк5 58571371,9Лима10 160162682,4Джакарта11 719194782,5Каир3 51360232,6Санкт-Петербург2 10538142,7Бангалор8 041144542,7Богота8 500160572,8Буэнос-Айрес11 103220743,0Лагос5 00699333,0Москва2 50851173,0Сан-Паулу9 473193633,1Бангкок9 543213643,3Гонконг9 644221643,4Стамбул2 50460173,6Лахор6 298151423,6Токио9 582239643,7Ханчжоу9 237232623,8Шанхай9 217241613,9Mumbai7 200190484,0Тайбэй9 800268654,1Дакка8 017229534,3Сеул8 880269594,5Обратите внимание на исправление: в приведённой выше таблице реальные операции передачи и подтверждения сравнивались с теоретическими перемещениями по прямой, теперь этот момент исправлен. Обсуждение и дополнительные сведения, например о том, на что повлияют характер волоконно-оптических кабелей и кривизна подводного кабеля, см. в этихдвухкомментариях.Как видно из таблицы, задержка в Нью-Йорке находится в пределах коэффициента 2 от значения для скорости света, но маршруты в другие места, такие как Дакка и Сеул, намного медленнее: они в 4 раза превышают значения для скорости света. Вероятно, маршрут между Лондоном и Нью-Йорком так хорошо оптимизирован по вполне понятным причинам. Я сомневаюсь, что то, что между этими городами в основном лежит океан, представляет большую проблему, так какподводные кабели можно прокладывать напрямую. Добираться до Сеула или Дакки придётся более окольным путём.Вероятно, следует упомянуть, что новые протоколы обещают уменьшить количество операций передачи и подтверждения. Версия TLS 1.3 позволяет создать зашифрованный сеанс с одной операцией передачи и подтверждения, а HTTP3 может объединить операции передачи и подтверждения протоколов HTTP и TLS. Это означает, что теперь нужны лишь три такие операции: одна — для DNS, одна-единственная операция передачи и подтверждения — для соединения и зашифрованного сеанса, и, наконец, третья — для темы запроса.Некоторые люди ложно надеются, что новые протоколы, такие как HTTP3, устранят необходимость в объединении (bundling) JavaScript/CSS. Это основано на недоразумении: в то время как HTTP/3 удаляет некоторые исходные операции передачи и подтверждения, эта версия не удаляет последующие операции передачи и подтверждения для дополнительных данных JavaScript или CSS. Так что объединение, к сожалению, никуда не делось.Слабые стороны данныхХотя, как мне кажется, это и интересное упражнение — и, надеюсь, показательное, — я должен честно признать, что качество используемых мной данных целиком относится к категории «от среднего до низкого».Во-первых, база данных GeoIP неоднозначно показывает местоположение IP-адресов. Заявленная (т. е., вероятно, оптимистичная) точность колеблется до 1000 км в некоторых случаях, хотя для моего набора данных утверждается, что средняя точность составляет 132 км со стандартным отклонением 276 км. Это не так уж точно, но я думаю, всё ещё полезно.Мой источник данных о задержке, WonderNetwork, действительно сообщает данные о задержке на момент их получения (30 ноября 2020 года) в отличие от долгосрочных данных. Иногда в определённых местах Интернет «барахлит».У WonderNetwork много станций, но их охват не идеален. На Западе всё отлично — в Великобритании представлены даже второстепенные города (вроде Ковентри). Их охват во всём мире по-прежнему хорош, но более неоднозначен. У них не так много мест в Африке или Южной Америке, а некоторые задержки в Юго-Восточной Азии кажутся странными: задержка между Гонконгом и Шэньчжэнем составляет 140 мс, тогда как эти города находятся всего в 50 км друг от друга. Этот фактор замедления более чем в тысячу раз превышает значение для скорости света. Для других городов континентального Китая проверка связи также показывает плохие результаты (что странно), хотя и не в таком масштабе. Может быть, эти коммунисты проверяют каждый ICMP-пакет вручную?Другая проблема с данными о задержке заключается в отсутствии истинных координат центров обработки данных, в которых находятся серверы. Мне пришлось самому геокодировать данные с помощью некоторых сценариев и большого количества ручного ввода данных в Excel (я опубликовал эту таблицу Excel в github, чтобы никому не пришлось делать эту работу заново). Я очень старательно проверял данные, но ошибки всё ещё могут быть.Однако, по моему мнению, самая большая слабость заключается в том, что все начинают отсчёт прямо от центра своего ближайшего города. На практике это не так и добавляемое из-за этого смещение может варьироваться. Здесь, в Великобритании, домашний доступ к Интернету — это сложный процесс, основанный на отправке высокочастотных сигналов по медным телефонным линиям. Моя собственная задержка для других хостов в Лондоне достигает 9 мс, что плохо для такого короткого расстояния, но всё ещёна 31 мс лучше среднего значения. Многие маршрутизаторы потребительского уровня не очень хороши и добавляют значительную задержку. Печально известнаяпроблема излишней сетевой буферизации — ещё один распространённый источник задержки. Особенно это влияет на процессы, для хорошей работы которых требуется последовательный уровень задержки. В качестве примера можно привести видеоконференц-связь и многопользовательские компьютерные игры. Использование сети мобильных телефонов тоже не помогает. Сети 4G в хороших условиях добавляют около 100 мс задержки, но, конечно, всё гораздо хуже, когда уровень сигнала низок и есть много ретрансляций на уровне канала.Я пытался предположить глобальную среднюю задержку на километр (около 0,03 мс), чтобы компенсировать расстояние до ближайшего города, но обнаружил, что это просто добавило кучу шума к моим результатам, так как для многих IP-адресов в моём наборе данных окольный путь был нереалистичным: ближайший город, который я им приписал, совсем не так близок.УниверсальностьВозникает справедливый вопрос: в какой степени мои результаты изменились бы для другого места? Трудно сказать, но я подозреваю, что результаты будут примерно такими же для других англоязычных мест без какой-либо особой географической составляющей. Это потому, что я думаю, что люди, читающие этот блог, вероятно, довольно равномерно распределены по англоязычной популяции мира.Если бы я писал по-русски или по-итальянски, географическая база читателей была бы совсем другой, и поэтому относительные достоинства разных городов с точки зрения задержки изменились бы.Мне было не так уж трудно выполнить этот тест, и я опубликовал все написанные мною маленькие кусочки кода (в основном они относятся к загрузке данных и запросам фрагментов), так что вы без особых усилий можете повторить этот тест для собственных журналов доступа. Бесплатные операции передачи и подтвержденияВыбор хорошего места для вашего сервера заходит так далеко. Даже в хороших случаях у вас всё ещё будет почти 100 мс задержки за каждую операцию передачи и подтверждения. Как я писал выше, при посещении страницы может быть до пяти операций передачи и подтверждения.Наличие ненужных операция передачи и подтверждения действительно замедлит процесс. Одна дополнительная операция передачи и подтверждения сводит на нет изрядную долю выигрыша от размещения сервера в быстром месте.Операции передачи и подтверждения легко добавить случайно. Особенно удивительным источником операций передачи и подтверждения служат предварительные запросы общего доступа к ресурсам независимо от источника (CORS). По соображениям безопасности, связанным с предотвращением атак на основе межсайтового скриптинга, браузеры должны«проверять» определённые HTTP-запросы, созданные кодом JavaScript. Для этого на тот же URL-адрес предварительно отправляется запрос с помощью специальной команды OPTIONS. На основе полученного ответа принимается решение о допустимости исходного запроса. Правила, определяющие точный момент отправки предварительных запросов, сложны, но в сети появляется удивительное количество запросов: в частности, включая POST-запросы JSON к поддоменам (например, к поддомену api.foo.com от домена foo.com) и сторонние веб-шрифты. В предварительных проверках на основе CORS-запросов используется другой набор заголовков кэширования по сравнению с остальным HTTP-кэшированием, которые редко задаются правильно и в любом случае применимы только к последующим запросам.В наши дни многие сайты написаны как «одностраничные приложения», где вы загружаете некоторый статический пакет JavaScript (надеюсь, из CDN), а затем создаёте (надеюсь, небольшое) количество API-запросов внутри своего браузера, чтобы решить, что показывать на странице. Есть надежда, что этот процесс станет быстрее после первого запроса, так как не придётся перерисовывать весь экран, когда пользователь попросит загрузить вторую страницу. Как правило, это не помогает, потому что одна HTML-страница обычно заменяется несколькими последовательными API-вызовами. Пара последовательных API-вызовов к исходному серверу почти всегда обрабатывается медленнее перерисовки всего экрана, особенно в сети мобильной связи.Я всегда считаю немного вздорной ситуацию, когда я получаю загружающуюся панель на веб-странице — вы уже отправили мне страницу, но почему сразу не отправили нужную мне страницу?! Один из величайших парадоксов Интернета заключается в том, что, хотя Google не очень хорошо справляется с обходом таких одностраничных приложений, эта компания, безусловно, создаёт большое их количество. Особенно дьявольской является «консоль поиска» (веб-сайт, ранее известный как «средства веб-мастера»). Я полагаю, Google не нужно слишком беспокоиться об оптимизации поисковых систем (SEO).Пропускная способность быстро увеличивается, но задержка уменьшается медленноПропускная способность Интернета становится всё лучше и лучше. Сейчас можно передавать гораздо больше байт в секунду, чем даже несколько лет назад. Однако улучшения задержки довольно редки, и по мере приближения к значению для скорости света они совсем сойдут на нет.100 мегаватт в секунду менее убедительны, когда вам по-прежнему приходится ждать всё те же полсекунды для загрузки каждой страницы.Смотрите такжеВ прошлом годув центре APNIC проанализировали производительность CDN по всему миру и пришли к выводу, что задержка 40 мс типична. Мне бы хотелось, чтобы в эту публикацию были включены процентильные данные, но у меня сохраняется смутное впечатление, что сети CDN лучше всего работают на Западе и менее хорошо в Южной Америке, Китае и Африке, что является проблемой, учитывая, что большинство серверов находится на Западе.Пока я писал эту статью, произошла вспышка «клубов», основанных на весе страницы, таких какКлуб 1МБ и, предположительно, более элитныйКлуб 512К. Пожалуй, я одобряю это чувство (и всё это во имя веселья, я уверен). Я думаю, что они слишком подчёркивают размер передаваемых данных. Если вы в Лондоне запрашиваете динамически генерируемую страницу из Калифорнии, весь процесс всё равно займёт большую часть секунды (130 мс умножить на 5 операций передачи и подтверждения), независимо от того, насколько велик размер этой страницы.Накарту подводных кабелей всегда приятно смотреть. Если вы хотите увидеть признак разной важности разных мест: Нормандские острова (население 170 тыс. человек) имеют 8 подводных кабелей, в том числе два, которые просто соединяют Гернси и Джерси. У Мадагаскара (население 26 млн. человек) их всего четыре. Я также считаю забавным то, что, хотя Аляска и Россия довольно близки, между ними нет ни одного кабеля.На случай, если вы захотите воспроизвести мои результаты, яопубликовал свой код и данные в Github. Боюсь, что сюда не входят мои журналы доступа, которые я не могу обнародовать по соображениям конфиденциальности. Пожалуйста, не ждите, что я создам для вас повторяемый процесс сборки: это требует гораздо больше времени и усилий, и поэтому он предоставляется по принципу «требуется некоторая сборка».

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

Другие профессии и курсыПРОФЕССИИ

КУРСЫ

===========
Источник:
habr.com
===========
===========
Автор оригинала: Cal Paterson
===========Похожие новости:

Теги для поиска: #_razrabotka_vebsajtov (Разработка веб-сайтов), #_servernaja_optimizatsija (Серверная оптимизация), #_setevye_tehnologii (Сетевые технологии), #_servernoe_administrirovanie (Серверное администрирование), #_skillfactory, #_razrabotka_sajtov (разработка сайтов), #_razrabotka_prilozhenij (разработка приложений), #_razrabotka (разработка), #_servernaja_optimizatsija (серверная оптимизация), #_setevoe_administrirovanie (сетевое администрирование), #_administrirovanie (администрирование), #_servernoe_administrirovanie (серверное администрирование), #_blog_kompanii_skillfactory (
Блог компании SkillFactory
), #_razrabotka_vebsajtov (
Разработка веб-сайтов
), #_servernaja_optimizatsija (
Серверная оптимизация
), #_setevye_tehnologii (
Сетевые технологии
), #_servernoe_administrirovanie (
Серверное администрирование
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 11:06
Часовой пояс: UTC + 5