Comet利用HTTP规范中不常用的特殊性来工作。通过更智能的长连接管理和减少每个连接占用的服务端资源，Comet比传统Web服务更易于提供更多的同步连接，客户端与服务端之间的数据传输更快。
大规模的应用必须使用异步连接处理，因为传统的服务架构中每个连接都需要使用一个线程。对于高并发的应用，Comet服务器通常会根据操作系统来改进事件库，操作系统处理异步I/O的方式多种多样，传统的方式是选择（select）或轮询（poll）。应用程序可以通过这些结构来询问操作系统哪些套接字（Socket）已经可以写入和读取从而避免发生阻塞。

如果应用程序的规模并不大，但想通过Comet获益该怎么办呢？例如，一个每天访问量为50 000且连接时间通常是3分钟的站点，平均只打开92个连接。即使你可能依靠服务器来提升最大线程数，但92个线程对于追求高性能的小网站开说也并非一个好方法。

对基于Comet的高性能站点来说，每个连接使用一个线程是有问题的，所以大部分Comet服务器或明显地减少每个线程的资源开销，或者使用微线程和进程。例如，ErlyComet是用Erlan写的，这是一门运行于虚拟机且基于线程的函数式语言。因为一个连接由一个进程表示，且Erlang的事件驱动机制便于进程通过信息传递来建立彼此之间的联系，所以即使在不同的服务器上Erlang也非常容易扩展连接的数量。

相反，作为Comet服务端语言，PHP因其线程模型而成为非常差得选择，所以大多数使用Coment的PHP Web应用需要采用分离式。该方案通过PHP编写的Comet客户端与使用另一门语言编写的服务端通信，一般来讲，尽管Comet服务端的编程语言不重要，但像C、Erlang和Python这几门语言更适合创建Comet服务端，也有用Java写的许多大型的Comet服务端。我们使用术语“一体的”来描述Web服务端和Comet服务端相同的情况。

尽管一体的Comet使用简单，且通常运行在同一个域，但在大型网站中分离的Comet更常见，特别是那些主要开发语言不适合Comet性能要求的站点。例如，像Facebook这样的站点或许会使用分离方案来实现它的聊天应用，而像Meebo这样的站点会使用一体的方案，因为其整站的通信差不多都使用了Comet技术。

在客户端，常用技术包括轮询、长轮询、永久帧、XHR流和即将出现的WebSocket。除了这些实现Comet连接的技术，还有许多在客户端和服务端之间发送信息的协议。像Dojo Toolkit工具包后js.io库能为你自动处理很多这样的复杂性问题，但了解在没有工具包时这些技术如何工作及如何评估和优化Comet性能是至关重要的。