Use of Trigger on table which can have 100 hits / second. Will it hamper performance? Currently in one of our projects we have the following situation. 

The server computer is Windows Server 2008 Standard SP2. Processor is Xeon (R) 2.13 Ghz. We are running SQL Server 2008 R2.

We need to implement a database trigger on a table which could have around 100 hits (for fetch and DML) per second. 

The trigger will work on INSERT, UPDATE and DELETE. 

I wanted to know if the system performance will suffer considerably due these triggers?

The trigger will perform addition of 2 numbers and store the result in a separate table.
Unless you've badly coded it, then no. It is probably less then 10 writes per second. Even very write heavy databases are over 90% reads and under 10% writes.

Consider though that such things can be replaced by, say, an indexed view on this table that looks like the separate table. Or the DML can be done in a stored procedure so it's all in one place for clarity.

If you do hit issues, consider snapshot isolation so that the writes do not block reads.

Summary: should be OK, but there are things to mitigate if not.

Edit, read:write ratio

SELECT  SUM(ddius.user_updates) AS user_writes,
        SUM(ddius.user_lookups + ddius.user_scans + ddius.user_seeks) AS user_reads,
        OBJECT_NAME(ddius.object_id),
        1.0*SUM(ddius.user_lookups + ddius.user_scans + ddius.user_seeks)/NULLIF(SUM(ddius.user_updates), 0)
FROM    sys.dm_db_index_usage_stats AS ddius
GROUP BY OBJECT_NAME(ddius.object_id)
ORDER BY
 1.0*SUM(ddius.user_lookups + ddius.user_scans + ddius.user_seeks)/NULLIF(SUM(ddius.user_updates), 0)


Of 227 objects with indexes in my main OLTP system


only 24 have more writes then reads and about half are log or history tables.
101 have zero writes (mostly lookup or metadata tables)
Of the remainder, some of our heaviest use table have x2 or x10 or x25 and higher more reads than writes