A good doc to start with (besides the ASE Performance & Tuning manuals) is http://scn.sap.com/docs/DOC-35088 ....there is a section in there that discusses caches/named caches and how IO happens and where spinlocks come into play.
However, you may also want to get the SAP note for best practices (1680803) which defines some specific recommended SAP application (particularly for ERP) starting tuning suggestions in addition to the SAP supplied configuration that SAPINST creates.
The most common cause of low cache hit ration in SAP systems is that quite often large tables don't have the appropriate indexes to cover the queries the way the users are using the system (as compared to the way SAP thought users would use the system). For example, SAP may have thought that users might look up customers via lastname, firstname and created an index on those columns. However, the users may be using the phone number.....without an index, the result is a table scan - which while ASE will try to avoid flushing data out of cache in doing so, sometimes it still happens.
The way to find these culprits is to simply look in DBACockpit at the performance tab --> Statements --> and then sort by either TotalElapsedTime or TotalPhysicalReads. Once you have the specific statement, you can look at the indexes in the catalog and compare to the where clause to see which ones are missing. The harder/manual way to do this (hence DBACockpit) is to query master..monCachedStatement, but you will need to know some SQL functions to extract the query text, etc. - DBACockpit is much easier.