WSTrading infrastructureWinservers.NET
TradeStation VPS · Commercial guide

When a TradeStation RadarScreen Workflow Needs a Dedicated Server

A practical way to decide whether your scanners, workspaces and EasyLanguage tools have outgrown a standard VPS.

Quick answer: choose a dedicated server when RadarScreen load is sustained, several data-intensive workspaces compete for CPU and memory, or a VPS remains constrained after you have measured and cleaned up the workload.

RadarScreen is useful precisely because it keeps many symbols and studies visible at once. That same breadth can make server sizing less obvious. A dedicated Windows server is not automatically better for every TradeStation user; it becomes relevant when predictable resources, additional headroom and control over the environment matter more than the lowest monthly cost.

Start with evidence: record CPU, RAM, disk activity and disconnections during the busiest scan and market-data periods.

What usually signals that a VPS is too small?

Look for a pattern rather than one brief spike. A move to dedicated infrastructure is worth investigating when several of these conditions occur together:

  • RadarScreen scans, workspaces and charts remain busy for long periods, not just during startup.
  • TradeStation becomes slow to switch workspaces or redraws after adding symbols, studies or custom columns.
  • CPU or memory stays near the server’s practical limit during normal use.
  • Other terminals, data tools, browsers or development utilities compete with TradeStation.
  • Updates, restarts or noisy-neighbour contention on a shared VPS disrupt a workflow that must stay available.

VPS or dedicated server: the decision in context

RequirementWindows VPS may fitDedicated server is worth considering
RadarScreen scopeSmall or moderate symbol lists and a few workspacesLarge lists, many studies or several active workspaces
Resource patternShort, measured peaks with spare capacitySustained CPU/RAM pressure during ordinary sessions
IsolationNormal shared virtual resources are acceptableConsistent dedicated CPU and no shared-host contention are priorities
Other workloadsTradeStation is the main applicationMultiple terminals, research tools or development workloads share the host
OperationsSimple RDP access and routine maintenance are enoughYou need more control over Windows, storage, backups and scheduling

Decision criteria before ordering dedicated hardware

Measure the real workload

Capture the busiest combination of RadarScreen rows, studies, charts, alerts and data connections. A single high reading does not prove that dedicated hardware is necessary.

Separate latency from capacity

A larger server cannot repair a poor data route or provider-side issue. Check network and reconnect behavior separately from CPU and RAM sizing.

Plan for headroom

Leave room for market-data growth, additional workspaces, Windows maintenance and logs. Stable operation with capacity left is the useful target.

Choose manageable access

Full RDP access, a suitable Windows Server image, NVMe storage and responsive support are practical requirements. Confirm software licensing and compatibility first.

Who a dedicated TradeStation server is for

This option is a sensible fit for traders or small teams who run broad RadarScreen workspaces, keep several tools online, need stable remote access or want resource isolation for a long-running workflow. It can also suit developers testing EasyLanguage indicators and strategies alongside the live workspace.

It is usually not the right first step for someone running one light workspace, a short daily session or a VPS that has not yet been measured. In those cases, reducing unnecessary studies, reviewing startup applications and selecting a correctly sized Windows VPS for trading may solve the problem more simply.

Common mistakes when sizing RadarScreen hosting

  • Buying by core count alone: CPU architecture, clock behavior, RAM, storage and the application mix all matter.
  • Confusing internet speed with application capacity: a fast uplink does not make a CPU-bound scan faster.
  • Ignoring maintenance windows: updates and restarts should be planned around the trading workflow.
  • Assuming dedicated means zero troubleshooting: data subscriptions, platform settings and custom code still need diagnosis.
  • Overloading one machine: keep unrelated heavy jobs away from the session that must remain responsive.

A practical migration checklist

  1. Document symbols, workspaces, studies, data feeds, scripts and startup order.
  2. Measure the current VPS during the busiest normal session and save the observations.
  3. Choose Windows Server resources with meaningful headroom and fast storage.
  4. Install TradeStation and dependencies, then validate data connections and workspace behavior.
  5. Run old and new environments in parallel long enough to compare reconnects, resource use and operational fit.
  6. Set a backup and update routine before relying on the new server.

Final recommendation

If RadarScreen is consistently constrained after basic optimization, and the workflow depends on several concurrent workspaces or applications, a dedicated Windows server is the more predictable choice. If evidence shows modest usage, start with a right-sized VPS and upgrade when measurements show that you need isolation and headroom. Winservers.NET also provides dedicated servers for MetaTrader workloads for wider multi-platform trading setups.

Need help sizing the environment?

Share your RadarScreen symbol count, workspaces, other applications and observed CPU/RAM usage.

Ask about server sizing

Frequently asked questions

Does every TradeStation RadarScreen user need a dedicated server?

No. A correctly sized Windows VPS can be enough for a light or moderate workflow. Dedicated capacity becomes relevant when measured, sustained resource pressure or isolation requirements justify it.

What should I measure before upgrading?

Measure CPU and memory over the busiest normal session, along with disk activity, workspace responsiveness, reconnects and concurrent applications.

Can a dedicated server fix TradeStation data-feed problems?

Not necessarily. A dedicated server can provide more predictable local resources, but provider outages, subscriptions and network or data-feed problems must be diagnosed separately.

Is a dedicated server useful for EasyLanguage development too?

It can be useful when development tools, tests and several TradeStation workspaces run together and need more predictable CPU, memory and storage headroom.

## Meta Pixel / CAPI tracking (WS_BILLING_ATTRIBUTION_V7 — since 2026-08-10) **Superseded the old per-page inline block.** All tracking logic (Pixel init, attribution handoff, click tracking, the CAPI beacon) now lives in one stable file: `/var/www/fastpanel-sites/winservers.net/assets/ws-tracking.js`, loaded via a single `` tag. Do **not** re-inline the old Meta Pixel block into new pages — this was the root cause of the old setup silently losing tracking: static pages get regenerated (by Joomla previously, or by whatever generates a page now) and any inline-injected script is wiped, while a stable referenced file survives. ### Why this changed `winservers.net` is pure static HTML — the nginx vhost has no PHP handler at all (`index index.html;`, no `fastcgi_pass`). An audit on 2026-08-10 found the old inline-JS approach had decayed: the attribution marker was present on only 14 of 215+ pages with the Pixel, and several primary ad-landing pages (`/vps/`, `/order/`, some FAQ pages) had **no tracking code at all**. The billing-side ad reconciliation data (`ADS.md`, "Source data and measurement limits") independently confirmed the symptom: only 1 of 3 known advertising-driven orders had a matching Meta `Purchase` event. ### Architecture ``` Visitor clicks a Meta ad -> fbclid/utm_* in the URL on winservers.net -> nginx captures them into first-party cookies on EVERY request (fastpanel-migration.conf, WS_BILLING_ATTRIBUTION_NGINX map blocks — server-layer, independent of page content, survives any regeneration) -> ws-tracking.js reads those cookies: - fires PageView both via the browser Pixel (sets _fbp) and via a server-side beacon, deduplicated with a shared eventID - on click to billing.winservers.net: appends the cookie values to the outgoing URL as query params, and beacons CheckoutIntent_Click / GoToBilling_Click -> POST https://billing.winservers.net/api/site-events/track (public, unauthenticated, rate-limited 30/min/IP, closed event_name allowlist) forwards to MetaConversionsApiService — the same queued-delivery/retry/logging pipeline used for every billing-side event -> billing.winservers.net: CaptureMetaAttribution middleware reads the fbclid/utm_* query params on arrival, stores them, and later CompleteRegistration / InitiateCheckout / Purchase events use them ``` ### Rules (unchanged from before) - `InitiateCheckout` and `Purchase` must **not** be sent by browser JS. They are server-side-only events on `billing.winservers.net`, fired after a real order/bill exists (see `META_CONVERSIONS.md` on the billing server). - `CheckoutIntent_Click`: a link to `billing.winservers.net` whose URL contains `/cabinet/new-order` or `do=tarifs`, or whose visible text contains `order`, `choose`, `select`, `tariff`, `plan`, or `checkout`. Order-intent, not a created order. - `GoToBilling_Click`: every other link to `billing.winservers.net` (SIGN-IN, My account, etc.). Do not mix with order-intent clicks. - To tag a non-link element explicitly (e.g. the AI chat CTA), add `data-ws-event="Lead"` — no separate handler needed, `ws-tracking.js` already listens for `[data-ws-event]` via its delegated click listener. ### New pages Just add the one `` tag before ``. Nothing else is required — attribution capture (nginx) and the click handler (delegated on `document`) both apply automatically, site-wide. `/root/winserversnet/scripts/ws_tracking_migrate.py` did the one-time bulk migration from the old inline block (idempotent — safe to re-run on any file; prints `ALREADY` if a page already references `ws-tracking.js`). --- ## Бургер-меню на мобайле — обязательно на каждой новой странице На всех статических лендингах навигация должна сворачиваться в бургер на мобайле. Реализовано на: `/vps/`, `/vps-for-ea/`, `/mt5-optimization-server/`, `/dedicated-server-metatrader/`, `/mt5-backtest-farm/`. ### CSS — добавить один раз в `